Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 157163 - app-admin/denyhosts: denial of service (CVE-2006-6301)
Summary: app-admin/denyhosts: denial of service (CVE-2006-6301)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B3? [glsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-04 16:27 UTC by Tavis Ormandy (RETIRED)
Modified: 2008-05-21 00:45 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tavis Ormandy (RETIRED) gentoo-dev 2006-12-04 16:27:32 UTC
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.
Comment 1 Tavis Ormandy (RETIRED) gentoo-dev 2006-12-04 16:31:48 UTC
strerror, do you have an opinion on this problem?

Do you know any upstream developers we can discuss possible solutions with?
Comment 2 Tavis Ormandy (RETIRED) gentoo-dev 2006-12-04 17:10:52 UTC
see also bug 157166
Comment 3 Benjamin Smee (strerror) (RETIRED) gentoo-dev 2006-12-05 02:42:39 UTC
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.
Comment 4 Benjamin Smee (strerror) (RETIRED) gentoo-dev 2006-12-05 02:43:37 UTC
ack sorry this bug wasn't assigned to me, reopenning for security to do what they want with it.
Comment 5 Benjamin Smee (strerror) (RETIRED) gentoo-dev 2006-12-05 02:48:00 UTC
in terms of contacting the dev's check:
http://www.phil-schwartz.com/contact.spy

for the lead dev for denyhosts.
Comment 6 Tavis Ormandy (RETIRED) gentoo-dev 2006-12-05 03:34:59 UTC
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.
Comment 7 Benjamin Smee (strerror) (RETIRED) gentoo-dev 2006-12-05 03:59:30 UTC
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".
Comment 8 Benjamin Smee (strerror) (RETIRED) gentoo-dev 2006-12-05 04:16:11 UTC
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.
Comment 9 Gokdeniz Karadag 2006-12-09 05:24:05 UTC
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
Comment 10 Tavis Ormandy (RETIRED) gentoo-dev 2006-12-09 06:55:26 UTC
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!
Comment 11 Benjamin Smee (strerror) (RETIRED) gentoo-dev 2006-12-09 07:50:58 UTC
new version in cvs ...
Comment 12 Tavis Ormandy (RETIRED) gentoo-dev 2006-12-09 14:09:14 UTC
arches, please test and mark stable denyhosts-2.6
Comment 13 Malcolm Lashley (RETIRED) gentoo-dev 2006-12-10 16:21:58 UTC
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
Comment 14 Tavis Ormandy (RETIRED) gentoo-dev 2006-12-10 18:06:10 UTC
it seems to work for me malc, I think it might cache entries in /var/lib/denyhosts, maybe try clearing this directory?
Comment 15 Dustin J. Mitchell 2006-12-10 18:26:29 UTC
With those log entries, I get the same result (123.123.123.123 blocked).  It doesn't look like this is fixed yet.
Comment 16 Dustin J. Mitchell 2006-12-10 18:41:37 UTC
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.
Comment 17 Gustavo Zacarias (RETIRED) gentoo-dev 2006-12-11 05:30:21 UTC
sparc stable.
Comment 18 Malcolm Lashley (RETIRED) gentoo-dev 2006-12-11 06:54:55 UTC
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
Comment 19 Sune Kloppenborg Jeppesen gentoo-dev 2006-12-11 08:10:44 UTC
Back to upstream? status and removing arches from CC until this gets resolved.
Comment 20 Dustin J. Mitchell 2006-12-11 08:42:52 UTC
In reply to comment #18, agreed (adding myself to CC).
Comment 21 Tavis Ormandy (RETIRED) gentoo-dev 2006-12-11 12:42:39 UTC
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).
--------------------
Comment 22 Tavis Ormandy (RETIRED) gentoo-dev 2006-12-12 07:56:13 UTC
Malc: how did you get sshd to resolve hostnames? I cannot reproduce this behaviour.
Comment 23 Tavis Ormandy (RETIRED) gentoo-dev 2006-12-18 14:23:38 UTC
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
Comment 24 Dustin J. Mitchell 2006-12-18 18:32:52 UTC
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

Comment 25 Malcolm Lashley (RETIRED) gentoo-dev 2006-12-19 15:33:04 UTC
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?


Comment 26 Bryan Østergaard (RETIRED) gentoo-dev 2006-12-21 06:38:45 UTC
Stable on Alpha.
Comment 27 Jeroen Roovers gentoo-dev 2006-12-25 03:54:30 UTC
Stable for HPPA.
Comment 28 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-12-28 08:55:46 UTC
mmm amd64 team, something does not work as expected?
Comment 29 Peter Weller (RETIRED) gentoo-dev 2006-12-29 07:34:19 UTC
'eh what? I didn't do nuttin! :o
AMD64 gone... :P
Comment 30 Peter Weller (RETIRED) gentoo-dev 2006-12-29 07:34:55 UTC
/me reminds himself to remove amd64...
Comment 31 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-12-29 08:49:58 UTC
Thanks  Peter

Security team: i don't know what to vote since super-Tavis has already prepared the GLSA.
Comment 32 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-01-03 10:21:50 UTC
Tavis told me he would vote yes, I vote yes, that's two votes. -> GLSA
Comment 33 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-01-03 10:27:34 UTC
First GLSA of the year 2007 (GLSA 200701-01), congrats Tavis :)
Comment 34 Tres 'RiverRat' Melton 2008-05-21 00:45:18 UTC
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