Bugzilla Bug 157163

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.

strerror, do you have an opinion on this problem?

Do you know any upstream developers we can discuss possible solutions with?

see also bug 157166

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.

ack sorry this bug wasn't assigned to me, reopenning for security to do what
they want with it.

in terms of contacting the dev's check:
http://www.phil-schwartz.com/contact.spy

for the lead dev for denyhosts.

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.

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".

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.

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

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!

new version in cvs ...

arches, please test and mark stable denyhosts-2.6

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

it seems to work for me malc, I think it might cache entries in
/var/lib/denyhosts, maybe try clearing this directory?

With those log entries, I get the same result (123.123.123.123 blocked).  It
doesn't look like this is fixed yet.

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.

sparc stable.

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

Back to upstream? status and removing arches from CC until this gets resolved.

In reply to comment #18, agreed (adding myself to CC).

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).
--------------------

Malc: how did you get sshd to resolve hostnames? I cannot reproduce this
behaviour.

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

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

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?

Stable on Alpha.

Stable for HPPA.

mmm amd64 team, something does not work as expected?

'eh what? I didn't do nuttin! :o
AMD64 gone... :P

/me reminds himself to remove amd64...

Thanks  Peter

Security team: i don't know what to vote since super-Tavis has already prepared
the GLSA.

Tavis told me he would vote yes, I vote yes, that's two votes. -> GLSA

First GLSA of the year 2007 (GLSA 200701-01), congrats Tavis :)

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