snmpd from net-snmp-5.4.2.1 seems to be vulnerable to unauthorized access when relying on tcp-wrappers as the only client authorization instance. It's a bit hard to describe so i've put things in 3 scenarios. prerequisites ============= server (gentoo box running snmpd and being monitored by nagios/cacti on "client") o net-analyzer/net-snmp-5.4.2.1 o sys-apps/tcp-wrappers-7.6-r8 o IP: 10.0.0.41 client (gentoo box running nagios/cacti and monitoring "server") o net-analyzer/net-snmp-5.2.1.2-r1 o sys-apps/tcp-wrappers-7.6-r8 o IP: 10.0.0.59 attacker o net-analyzer/net-snmp-5.2.1.2-r1 o sys-apps/tcp-wrappers-7.6-r8 o IP: 10.0.0.120 scenario 1 ========== servers tcp-wrapper files # cat /etc/hosts.deny snmpd: ALL # cat /etc/hosts.allow snmpd: 10.0.0.59 10.0.0.41 client # snmpget -On -v1 -c XyqeXJnVOmK7U8hYjDoXw4euf7VvrQ 10.0.0.41 .1.3.6.1.4.1.2021.100.4.0 .1.3.6.1.4.1.2021.100.4.0 = STRING: Tue Dec 9 20:38:33 2008 This is expected. Logfile on server says: Connection from UDP: [10.0.0.41]->[10.0.0.59]:-8309 Received SNMP packet(s) from UDP: [10.0.0.41]->[10.0.0.59]:-8309 attacker # snmpget -On -v1 -c XyqeXJnVOmK7U8hYjDoXw4euf7VvrQ 10.0.0.41 .1.3.6.1.4.1.2021.100.4.0 .1.3.6.1.4.1.2021.100.4.0 = STRING: Tue Dec 9 20:40:33 2008 This is a SERIOUS ISSUE since attackers IP (10.0.0.120) is not listed in /etc/hosts.allow. Logfile on server says: Connection from UDP: [10.0.0.41]->[10.0.0.120]:-7157 Received SNMP packet(s) from UDP: [10.0.0.41]->[10.0.0.120]:-7157 You may ask why the servers IP itself is listed in the servers hosts.allow file. This is because some versions ago snmpd wouldn't accept connections unless it's own IP is also listed in the hosts.allow file - which is somehow fucked up. scenario 2 ========== servers tcp-wrapper files # cat /etc/hosts.deny snmpd: ALL # cat /etc/hosts.allow snmpd: 10.0.0.59 ^^^^^^^^^ This time _only_ the clients IP This is the way it should be _and_ work client # snmpget -On -v1 -c XyqeXJnVOmK7U8hYjDoXw4euf7VvrQ 10.0.0.41 .1.3.6.1.4.1.2021.100.4.0 Timeout: No Response from 10.0.0.41. This is NOT expected. This should work (and it did in earlier versions of net-snmp). Logfile on server says: Connection from UDP: [10.0.0.41]->[10.0.0.59]:-6060 REFUSED Connection from UDP: [10.0.0.41]->[10.0.0.59]:-6060 REFUSED Connection from UDP: [10.0.0.41]->[10.0.0.59]:-6060 REFUSED Connection from UDP: [10.0.0.41]->[10.0.0.59]:-6060 REFUSED Connection from UDP: [10.0.0.41]->[10.0.0.59]:-6060 REFUSED Connection from UDP: [10.0.0.41]->[10.0.0.59]:-6060 REFUSED attacker # snmpget -On -v1 -c XyqeXJnVOmK7U8hYjDoXw4euf7VvrQ 10.0.0.41 .1.3.6.1.4.1.2021.100.4.0 Timeout: No Response from 10.0.0.41. No surprise here - attackers IP is not in servers hosts.allow file. Logfile on server says: Connection from UDP: [10.0.0.41]->[10.0.0.120]:-6060 REFUSED Connection from UDP: [10.0.0.41]->[10.0.0.120]:-6060 REFUSED Connection from UDP: [10.0.0.41]->[10.0.0.120]:-6060 REFUSED Connection from UDP: [10.0.0.41]->[10.0.0.120]:-6060 REFUSED Connection from UDP: [10.0.0.41]->[10.0.0.120]:-6060 REFUSED Connection from UDP: [10.0.0.41]->[10.0.0.120]:-6060 REFUSED scenario 3 ========== servers tcp-wrapper files # cat /etc/hosts.deny snmpd: ALL # cat /etc/hosts.allow snmpd: 10.0.0.41 ^^^^^^^^^ This time _only_ the ___servers___ IP (which makes absolutely no sense) client # snmpget -On -v1 -c XyqeXJnVOmK7U8hYjDoXw4euf7VvrQ 10.0.0.41 .1.3.6.1.4.1.2021.100.4.0 .1.3.6.1.4.1.2021.100.4.0 = STRING: Tue Dec 9 20:50:51 2008 Big fat surpsise - clients IP is NOT allowed to connect but can somehow receive data... Logfile on server says: Connection from UDP: [10.0.0.41]->[10.0.0.59]:-5200 Received SNMP packet(s) from UDP: [10.0.0.41]->[10.0.0.59]:-5200 attacker # snmpget -On -v1 -c XyqeXJnVOmK7U8hYjDoXw4euf7VvrQ 10.0.0.41 .1.3.6.1.4.1.2021.100.4.0 .1.3.6.1.4.1.2021.100.4.0 = STRING: Tue Dec 9 20:53:25 2008 Big fat surpsise, too - attackers IP is NOT allowed to connect but ... Logfile on server says: Connection from UDP: [10.0.0.41]->[10.0.0.120]:-7157 Received SNMP packet(s) from UDP: [10.0.0.41]->[10.0.0.120]:-7157 I'm a bit confused with the logfiles indicating an incoming connection from the server itself to the client. Maybe this has something to do with this issue. server: Portage 2.1.4.4 (default-linux/x86/vserver, gcc-4.1.2, glibc-2.6.1-r0, 2.6.17-vs2.0.2.1-gentoo i686) ================================================================= System uname: 2.6.17-vs2.0.2.1-gentoo i686 Intel(R) Xeon(TM) CPU 3.00GHz Timestamp of tree: Tue, 09 Dec 2008 09:16:01 +0000 app-shells/bash: 3.2_p33 dev-lang/python: 2.4.4-r13 dev-python/pycrypto: 2.0.1-r6 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo" LANG="de_DE.UTF-8" LC_ALL="de_DE.UTF-8" LINGUAS="de" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" 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" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="apache2 bash-completion cli cracklib crypt dri gd glibc-omitfp hardened iconv isdnlog jpeg md5sum midi mpm-prefork mudflap ncurses nls nptl nptlonly openmp pam pcre png posix pppd readline reflection session spl ssl tcpd tiff unicode x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem 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="alias auth_basic authn_file authz_groupfile authz_host authz_user autoindex dir env expires headers log_config mime rewrite setenvif" APACHE2_MPMS="prefork" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt intel mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
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.
