157163 2006-12-04 16:27 0000 app-admin/denyhosts: denial of service (CVE-2006-6301) 2008-05-21 00:45:18 0000 1 1 1 Unclassified Gentoo Security Vulnerabilities unspecified All Linux RESOLVED FIXED B3? [glsa] P2 minor --- 1 taviso@gentoo.org security@gentoo.org dustin@v.igoro.us gokdenizk@gmail.com strerror@gentoo.org taviso@gentoo.org 2006-12-04 16:27:32 0000 denyhosts uses a regex to parse logs from sshd, however it's very easy to bypass it. $ ssh "foo from 123.123.123.123"@localhost $ ssh "foo from 123.123.123.123"@localhost $ ssh "foo from 123.123.123.123"@localhost $ cat /etc/hosts.deny sshd: 123.123.123.123 Remote attackers can add arbitrary hosts to /etc/hosts.deny. Ideally, denyhosts should be parsing btmp, rather than using regex to parse messages, as this is very difficult to do securely. Even if they do find a better regex, local users can still block other users from logging in, for example: $ logger -t "sshd[123]" "Invalid user foo from 1.1.1.1" $ cat /etc/hosts.deny sshd: 1.1.1.1 This is very bad design, I can live with it if they switch to parsing btmp, otherwise I suggest we mask. taviso@gentoo.org 2006-12-04 16:31:48 0000 strerror, do you have an opinion on this problem? Do you know any upstream developers we can discuss possible solutions with? taviso@gentoo.org 2006-12-04 17:10:52 0000 see also bug 157166 strerror@gentoo.org 2006-12-05 02:42:39 0000 I have an opinion, whether it's what you want to hear is a different story ;) I agree with you completely that the design of these type of "preventative" apps is fairly bad (I include all apps that parse easily inserted logs and takes actions on them) but I think you're missing the point of why they were written. There was for some time (still is really) a big problem with automated remote ssh brute forcing attacks. You'll note I use the term remote. fail2ban, denyhosts and others were written as a direct response to this problem. They are not meant to solve all ssh related attack problems, nor really do anything beyond offer a simple, easy to implement solution for stopping a remote brute force attack. That they can be bypassed, or even used maliciously by a local user is bad, but not really relevant to the majority of installations I'd guess. So by all means go and hassle upstream, every step towards a secure environment is better, but this is certainly not a bug that I'm going to address at it is at the very core of the app design itself. strerror@gentoo.org 2006-12-05 02:43:37 0000 ack sorry this bug wasn't assigned to me, reopenning for security to do what they want with it. strerror@gentoo.org 2006-12-05 02:48:00 0000 in terms of contacting the dev's check: http://www.phil-schwartz.com/contact.spy for the lead dev for denyhosts. taviso@gentoo.org 2006-12-05 03:34:59 0000 Benajmin: so it solves a non-issue (log noise), by opening a remote security issue? I would certainly vote for a mask if there is no solution to this problem. strerror@gentoo.org 2006-12-05 03:59:30 0000 Tavis: We seem to have a miscommunication. There is no remote issue that I can see here, all the "attacks" against these applications are done by LOCAL users, and the extent of the attack is to potentially deny access to someone else to the machine. Depending on how you configure the application, most people will have such bans time out after a couple of minutes for example, this might only be an inconvenience, hardly a critical remote vulnerability. This of course is on the assumption that you don't trust your local users, which I would suggest is increasingly unusual outside of large isp type environments, ie not the majority of our userbase. As for fixing a non issue, the only reason I added denyhosts to the tree was because there was a significant portion of our userbase that was asking for it to be added as they saw a problem with continued remote ssh brute force attacks. Whether there is or isn't a security hole that it is fixing is really up to the end user and their password policy, but I'd hardly just dismiss it as "log noise". strerror@gentoo.org 2006-12-05 04:16:11 0000 just a quick follow up to mention that I didn't realise that the bug was remote as well (i'd hoped that the parsing wasn't that atrocious). In light of that, if there is a quality control issue then I have no objections to the app being masked. gokdenizk@gmail.com 2006-12-09 05:24:05 0000 There seems to be a new version, dated Dec 7, 2006 that solves this issue. It gives reference to http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-6301 which gives reference to this bug. Changelog is at; http://denyhosts.sourceforge.net/changelog.html taviso@gentoo.org 2006-12-09 06:55:26 0000 Thanks Gokdeniz, the developer also emailed me to inform me that he has fixed this issue. strerror, please provide an updated ebuild (version 2.6?) thanks! strerror@gentoo.org 2006-12-09 07:50:58 0000 new version in cvs ... taviso@gentoo.org 2006-12-09 14:09:14 0000 arches, please test and mark stable denyhosts-2.6 malc@gentoo.org 2006-12-10 16:21:58 0000 Erm - doesn't seem to fix the problem reported... or I'm somehow being retarded... duality lib # cat /etc/hosts.deny duality lib # grep sshd.*123 /root/current Dec 11 00:11:48 [sshd] Invalid user foo from 123.123.123.123 from 127.0.0.1 Dec 11 00:11:52 [sshd] error: PAM: Authentication failure for illegal user foo from 123.123.123.123 from localhost Dec 11 00:11:52 [sshd] Failed keyboard-interactive/pam for invalid user foo from 123.123.123.123 from 127.0.0.1 port 50282 ssh2 Dec 11 00:11:59 [sshd] error: PAM: Authentication failure for illegal user foo from 123.123.123.123 from localhost Dec 11 00:11:59 [sshd] Failed keyboard-interactive/pam for invalid user foo from 123.123.123.123 from 127.0.0.1 port 50282 ssh2 Dec 11 00:12:01 [sshd] error: PAM: Authentication failure for illegal user foo from 123.123.123.123 from localhost Dec 11 00:12:01 [sshd] Failed keyboard-interactive/pam for invalid user foo from 123.123.123.123 from 127.0.0.1 port 50282 ssh2 Dec 11 00:12:03 [sshd] Invalid user foo from 123.123.123.123 from 127.0.0.1 Dec 11 00:12:06 [sshd] error: PAM: Authentication failure for illegal user foo from 123.123.123.123 from localhost Dec 11 00:12:06 [sshd] Failed keyboard-interactive/pam for invalid user foo from 123.123.123.123 from 127.0.0.1 port 50284 ssh2 Dec 11 00:12:09 [sshd] error: PAM: Authentication failure for illegal user foo from 123.123.123.123 from localhost Dec 11 00:12:09 [sshd] Failed keyboard-interactive/pam for invalid user foo from 123.123.123.123 from 127.0.0.1 port 50284 ssh2 Dec 11 00:12:12 [sshd] error: PAM: Authentication failure for illegal user foo from 123.123.123.123 from localhost Dec 11 00:12:12 [sshd] Failed keyboard-interactive/pam for invalid user foo from 123.123.123.123 from 127.0.0.1 port 50284 ssh2 duality lib # python /usr/bin/denyhosts -c /etc/denyhosts.conf --file /root/current duality lib # cat /etc/hosts.deny sshd: 123.123.123.123 duality lib # python /usr/bin/denyhosts --version DenyHosts version: 2.6 taviso@gentoo.org 2006-12-10 18:06:10 0000 it seems to work for me malc, I think it might cache entries in /var/lib/denyhosts, maybe try clearing this directory? dustin@v.igoro.us 2006-12-10 18:26:29 0000 With those log entries, I get the same result (123.123.123.123 blocked). It doesn't look like this is fixed yet. dustin@v.igoro.us 2006-12-10 18:41:37 0000 Ah: the problem with the above failure is the lines of this form: Dec 11 00:11:52 [sshd] error: PAM: Authentication failure for illegal user foo from 123.123.123.123 from localhost where 'localhost' doesn't get parsed as a hostname. As discussed above, such errors are only possible locally, so this converts a potential remote DoS to a local DoS that is a much smaller security issue. I would suggest stabling this version, and communicating with upstream that the regexes could be improved even further to recognize (and ignore) 'localhost' as an alternative hostname. gustavoz@gentoo.org 2006-12-11 05:30:21 0000 sparc stable. malc@gentoo.org 2006-12-11 06:54:55 0000 Really - it's still exploitable remotely from what I can see. Those PAM lines (if they're being parsed also) are still printed the same for local or remote login failures. I removed the whole /var/lib/denyhosts to prevent any caching issues from affecting the results. duality / # rm /etc/hosts.deny duality / # echo >/etc/hosts.deny duality / # rm -rf /var/lib/denyhosts/ duality / # grep 129 /root/current Dec 11 14:46:07 [sshd] Invalid user foo from 123.123.123.129 from 192.168.2.1 Dec 11 14:46:11 [sshd] error: PAM: Authentication failure for illegal user foo from 123.123.123.129 from gateway.clarkconnect.lan Dec 11 14:46:11 [sshd] Failed keyboard-interactive/pam for invalid user foo from 123.123.123.129 from 192.168.2.1 port 35165 ssh2 Dec 11 14:46:14 [sshd] error: PAM: Authentication failure for illegal user foo from 123.123.123.129 from gateway.clarkconnect.lan Dec 11 14:46:14 [sshd] Failed keyboard-interactive/pam for invalid user foo from 123.123.123.129 from 192.168.2.1 port 35165 ssh2 Dec 11 14:46:17 [sshd] error: PAM: Authentication failure for illegal user foo from 123.123.123.129 from gateway.clarkconnect.lan Dec 11 14:46:17 [sshd] Failed keyboard-interactive/pam for invalid user foo from 123.123.123.129 from 192.168.2.1 port 35165 ssh2 Dec 11 14:47:06 [sshd] Invalid user foo from 123.123.123.129 from 192.168.2.1 Dec 11 14:47:09 [sshd] error: PAM: Authentication failure for illegal user foo from 123.123.123.129 from gateway.clarkconnect.lan Dec 11 14:47:09 [sshd] Failed keyboard-interactive/pam for invalid user foo from 123.123.123.129 from 192.168.2.1 port 35166 ssh2 Dec 11 14:47:11 [sshd] error: PAM: Authentication failure for illegal user foo from 123.123.123.129 from gateway.clarkconnect.lan Dec 11 14:47:11 [sshd] Failed keyboard-interactive/pam for invalid user foo from 123.123.123.129 from 192.168.2.1 port 35166 ssh2 Dec 11 14:47:14 [sshd] error: PAM: Authentication failure for illegal user foo from 123.123.123.129 from gateway.clarkconnect.lan Dec 11 14:47:14 [sshd] Failed keyboard-interactive/pam for invalid user foo from 123.123.123.129 from 192.168.2.1 port 35166 ssh2 duality / # denyhosts -c /etc/denyhosts.conf --file /root/current duality / # cat /etc/hosts.deny sshd: 192.168.2.1 sshd: 123.123.123.129 jaervosz@gentoo.org 2006-12-11 08:10:44 0000 Back to upstream? status and removing arches from CC until this gets resolved. dustin@v.igoro.us 2006-12-11 08:42:52 0000 In reply to comment #18, agreed (adding myself to CC). taviso@gentoo.org 2006-12-11 12:42:39 0000 I asked the author for his opinion, extract from his response below: ----------------------- Hi Tavis, I'm not a gentoo user so perhaps it's a Gentoo-specific issue. Does the ssh installation (ssh itself, PAM, tcp_wrappers, syslog or similar logger, etc) by default resolve ip addresses to hostnames? On FC and the RedHat systems that I use hostnames never appear in the secure log. Typically, unless specifically enabled ip addresses are logged as-is. In your example "gateway.clarkconnect.lan" was used rather than the ip address which caused the problem. The default regex that parsed it was looking for the last ip address (and the one that it found was 123.123.123.129). Many of the default DH regexes look for IP addresses specifically when parsing the logfile. All of them can be easily overridden in the config file. If the hostname resolution is typical of Gentoo rather than something that someone has enabled then I could probably create a denyhosts-cfg-gentoo file and ship it w/ each version. In this way, gentoo users could use that as their base config file (which will replace the regexes w/ that look for anything: ip address, hostname, or anything else). -------------------- taviso@gentoo.org 2006-12-12 07:56:13 0000 Malc: how did you get sshd to resolve hostnames? I cannot reproduce this behaviour. taviso@gentoo.org 2006-12-18 14:23:38 0000 No response from Malc, asked several developers to check their logs, tried every possible configuration I can find to reproduce this, but I'm unable to do so. The upstream developer has never seen this before, but has offered to create a gentoo specific configuration if we can explain how to reproduce it, but I cant. Moving back to stable status. Arches, please test and mark stable denyhosts-2.6 dustin@v.igoro.us 2006-12-18 18:32:52 0000 Works for me on amd64, as described above. Gentoo Base System version 1.12.5 Portage 2.1.1-r1 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.4-r3, 2.6.15-gentoo-r72006040301 x86_64) ================================================================= System uname: 2.6.15-gentoo-r72006040301 x86_64 AMD Athlon(tm) 64 Processor 3700+ Last Sync: Mon, 11 Dec 2006 21:50:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig collision-protect confcache digest distlocks metadata-transfer multilib-strict sandbox sfperms strict test" GENTOO_MIRRORS="http://gentoo.chem.wisc.edu/gentoo/" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://209.59.138.21/gentoo-portage" USE="amd64 berkdb bitmap-fonts cli cracklib crypt cups dlloader dri elibc_glibc fortran gdbm gpm iconv input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 isdnlog kernel_linux libg++ ncurses nls nptl nptlonly pam pcre perl ppds pppd python readline reflection session spl ssl tcpd truetype-fonts type1-fonts udev unicode userland_GNU video_cards_apm video_cards_ark video_cards_ati video_cards_chips video_cards_cirrus video_cards_cyrix video_cards_dummy video_cards_fbdev video_cards_glint video_cards_i128 video_cards_i810 video_cards_mga video_cards_neomagic video_cards_nv video_cards_rendition video_cards_s3 video_cards_s3virge video_cards_savage video_cards_siliconmotion video_cards_sis video_cards_sisusb video_cards_tdfx video_cards_tga video_cards_trident video_cards_tseng video_cards_v4l video_cards_vesa video_cards_vga video_cards_via video_cards_vmware video_cards_voodoo xorg zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS malc@gentoo.org 2006-12-19 15:33:04 0000 Tavis - I'm using bog-standard sshd/PAM config as far as I am aware. I'm no guru on PAM - but I'm wondering if ssh is just logging some PAM error string. I tried the same on my (extremely out of date) x86 box - still logs hostnames in the PAM: Auth* line. Relevant package versions. [x86] [ebuild U ] net-misc/openssh-4.4_p1-r3 [4.3_p1] USE="X% pam tcpd -X509 -chroot -hpn -kerberos -ldap -libedit -skey -smartcard -static" 0 kB [ebuild U ] sys-libs/pam-0.78-r5 [0.78-r4] USE="berkdb -nis -pam_chroot -pam_console -pam_timestamp -pwdb" 85 kB [amd64][ebuild R ] net-misc/openssh-4.5_p1 USE="X pam tcpd -X509 -chroot -hpn -kerberos -ldap -libedit (-selinux) -skey -smartcard -static" 0 kB [ebuild R ] sys-libs/pam-0.99.6.3-r2 USE="nls (-selinux) -vim-syntax" 0 kB Maybe someone who has more of a clue about PAM can comment? kloeri@gentoo.org 2006-12-21 06:38:45 0000 Stable on Alpha. jer@gentoo.org 2006-12-25 03:54:30 0000 Stable for HPPA. falco@gentoo.org 2006-12-28 08:55:46 0000 mmm amd64 team, something does not work as expected? welp@gentoo.org 2006-12-29 07:34:19 0000 'eh what? I didn't do nuttin! :o AMD64 gone... :P welp@gentoo.org 2006-12-29 07:34:55 0000 /me reminds himself to remove amd64... falco@gentoo.org 2006-12-29 08:49:58 0000 Thanks Peter Security team: i don't know what to vote since super-Tavis has already prepared the GLSA. falco@gentoo.org 2007-01-03 10:21:50 0000 Tavis told me he would vote yes, I vote yes, that's two votes. -> GLSA falco@gentoo.org 2007-01-03 10:27:34 0000 First GLSA of the year 2007 (GLSA 200701-01), congrats Tavis :) RiverRat@GreenDragonTavern.com 2008-05-21 00:45:18 0000 In reply to comment #22: I think that is caused by the USE="audit" flag for sys-libs/pam I still have it enabled from trying to resolve bug #218292