Summary: | <net-analyzer/net-snmp-5.4.2.1-r1 tcp-wrappers vulnerability allowing 3rd parties to access snmpd (CVE-2008-6123) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Marcel Meckel <gentoo.org> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | gentoo.org, netmon, ole+gentoo |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | B3 [glsa] | ||
Package list: | Runtime testing required: | --- |
Description
Marcel Meckel
2008-12-09 20:14:53 UTC
Netmon, please advise here. A patch for this issue has been committed upstream: http://net-snmp.svn.sourceforge.net/viewvc/net-snmp?view=rev&revision=17367 It seems no new 5.4.2 release with this is out yet, so we could go with a revbump. CVE-2008-6123 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-6123): The netsnmp_udp_fmtaddr function (snmplib/snmpUDPDomain.c) in net-snmp 5.0.9 through 5.4.2, when using TCP wrappers for client authorization, does not properly parse hosts.allow rules, which allows remote attackers to bypass intended access restrictions and execute SNMP queries, related to "source/destination IP address confusion." ping,netmon? Seeing a bit more traffic on gentoo-announce lately i still miss an update for this issue... (In reply to comment #4) > ping,netmon? > pong, added net-snmp-5.4.2.1-r1 with the upstream patch for V5-4 from comment #2. Arches, please test and mark stable: =net-analyzer/net-snmp-5.4.2.1-r1 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86" Running Mkbootstrap for NetSNMP::TrapReceiver () chmod 644 TrapReceiver.bs rm -f ../blib/arch/auto/NetSNMP/TrapReceiver/TrapReceiver.so alpha-unknown-linux-gnu-gcc -shared -L/usr/local/lib -Wl,-O1 TrapReceiver.o -o ../blib/arch/auto/NetSNMP/TrapReceiver/TrapReceiver.so \ -L/var/tmp/portage/net-analyzer/net-snmp-5.4.2.1-r1/work/net-snmp-5.4.2.1/perl/TrapReceiver/../../apps/.libs -L/var/tmp/portage/net-analyzer/net-snmp-5.4.2.1-r1/work/net-snmp-5.4.2.1/perl/TrapReceiver/../../apps -L/var/tmp/portage/net-analyzer/net-snmp-5.4.2.1-r1/work/net-snmp-5.4.2.1/perl/TrapReceiver/../../agent/.libs -L/var/tmp/portage/net-analyzer/net-snmp-5.4.2.1-r1/work/net-snmp-5.4.2.1/perl/TrapReceiver/../../agent -L/var/tmp/portage/net-analyzer/net-snmp-5.4.2.1-r1/work/net-snmp-5.4.2.1/perl/TrapReceiver/../../agent/helpers/.libs -L/var/tmp/portage/net-analyzer/net-snmp-5.4.2.1-r1/work/net-snmp-5.4.2.1/perl/TrapReceiver/../../agent/helpers -L/var/tmp/portage/net-analyzer/net-snmp-5.4.2.1-r1/work/net-snmp-5.4.2.1/perl/TrapReceiver/../../snmplib/.libs -L/var/tmp/portage/net-analyzer/net-snmp-5.4.2.1-r1/work/net-snmp-5.4.2.1/perl/TrapReceiver/../../snmplib -lnetsnmptrapd -lnetsnmpagent -lnetsnmp \ chmod 755 ../blib/arch/auto/NetSNMP/TrapReceiver/TrapReceiver.so cp TrapReceiver.bs ../blib/arch/auto/NetSNMP/TrapReceiver/TrapReceiver.bs chmod 644 ../blib/arch/auto/NetSNMP/TrapReceiver/TrapReceiver.bs Manifying ../blib/man3/NetSNMP::TrapReceiver.3pm make[2]: Leaving directory `/var/tmp/portage/net-analyzer/net-snmp-5.4.2.1-r1/work/net-snmp-5.4.2.1/perl/TrapReceiver' make[1]: Leaving directory `/var/tmp/portage/net-analyzer/net-snmp-5.4.2.1-r1/work/net-snmp-5.4.2.1/perl' Traceback (most recent call last): File "setup.py", line 2, in <module> from setuptools import setup, Extension, find_packages ImportError: No module named setuptools make: *** [pythonmodules] Error 1 dev-python/setuptools-0.6_rc9 is installed # emerge --info Portage 2.1.6.13 (default/linux/alpha/2008.0, gcc-4.3.3, glibc-2.9_p20081201-r2, 2.6.31-rc1 alpha) ================================================================= System uname: Linux-2.6.31-rc1-alpha-EV68AL-with-gentoo-2.0.1 Timestamp of tree: Sun, 12 Jul 2009 10:15:01 +0000 distcc 3.1 alpha-unknown-linux-gnu [enabled] app-shells/bash: 4.0_p24 dev-lang/python: 2.6.2-r1 dev-util/cmake: 2.6.3-r1 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.4.3-r3 sys-apps/sandbox: 2.0 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.5, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.19.1-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.29 ACCEPT_KEYWORDS="alpha ~alpha" CBUILD="alpha-unknown-linux-gnu" CFLAGS="-mieee -pipe -O2 -mcpu=ev67" CHOST="alpha-unknown-linux-gnu" CONFIG_PROTECT="/etc /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-mieee -pipe -O2 -mcpu=ev67" DISTDIR="/usr/portage/distfiles" FEATURES="distcc distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans usepkg userfetch userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.tiscali.nl/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync5.de.gentoo.org/gentoo-portage" USE="X acl alpha alsa apache2 audiofile bash-completion berkdb bzip2 calendar cdparanoia cdr cli cracklib crypt dio dri encode ethereal exif ffmpeg fftw firefox flac fortran ftp gdbm gpm iconv imlib2 isdnlog jpeg kdeenablefinal libcaca lua mad matroska midi mmap mng moznocompose moznoirc moznomail mozsvg mpeg mudflap ncurses network-cron nls nptl nptlonly offensive ogg openmp pam pcre pdflib perl png pnm ppds pppd python rar readline recode reflection session sharedmem sockets sox spl ssl svg sysfs szip tcpd tetex theora truetype unicode usb v4l v4l2 vcd vidix vim vim-pager vlm vorbis xcb xorg xosd xpm xvid zlib" ALSA_CARDS="ali5451 als4000 bt87x ca0106 cmipci emu10k1 ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 maestro3 trident usb-audio via82xx ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="vga glint mga nvidia vesa r128 " Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS Nevermind. setuptools was still installed for Python 2.5 (2.6 is my default). Stab;e on alpha. x86 stable arm/ia64/s390/sh/sparc stable Stable for HPPA. ppc stable ppc64 done amd64 stable, all arches done. glsa decision: i vote YES I vote NO as I don't think (and hope *g) anyone still uses tcp-wrappers as only client authorization and not the nowadays usual layer3 firewalling approach. Besides that, the snmp data will contain traffic counters etc. and is not that secret. (In reply to comment #18) > I vote NO as I don't think (and hope *g) anyone still uses tcp-wrappers as only > client authorization and not the nowadays usual layer3 firewalling approach. > Besides that, the snmp data will contain traffic counters etc. and is not that > secret. That would be true if snmp could be only used to read traffic counters. Obviously this statement is wrong as it is very often used to change/set various things and to receive traps. Well ok, but I think no sane admin does that with SNMP v1 and v2 as they nearly have no security functionality - I'd consider it an insecure design; and with SNMP v3 your traffic would be secure. I stick to my "NO", but might be overvoted. ping, can we please have a third opinion on this? (In reply to comment #21) > ping, can we please have a third opinion on this? > Note sure if my opinion counts, but i tend to think YES. There's lots of snmp v1 around and if it's configured to allow to set things .. well ... YES therefore. I still think no sane person would use SNMP v1/v2 in that way (sorry if I offended anyone); nevertheless your opinion is good enough for me, so: request filed. GLSA 201001-05, thanks everyone. |