full-disclosure - Re: Remote log injection on DenyHosts, Fail2ban and BlockHosts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 7 Jun 2007 10:31:41 +0100
From: Tavis Ormandy <taviso@...too.org>
To: Daniel Cid <daniel.cid@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Remote log injection on DenyHosts,
	Fail2ban and BlockHosts

On Wed, Jun 06, 2007 at 05:13:54PM -0300, Daniel Cid wrote:
> DenyHosts, Fail2ban and BlockHosts are vulnerable to remote log injection
> that can lead to arbitrarily injection of IP addresses in /etc/hosts.deny. To
> make it more "interesting", not only IP addresses can be added, but
> also the wild card "all", causing it to block the whole Internet out of the
> box (bypassing white lists) -- see DenyHosts exploit example.

These aren't exactly "0-day", I discussed several of these attacks last
year, such as CVE-2006-6301, and informed the authors that there were
undoubtedly more attacks against these tools. This topic is a favourite
rant of mine, as the software itself is simply fundamentally flawed.

Even unprivileged local users are usually permitted to create arbitrary
log entries (eg, using logger), which will match any regex you can
create. Even if that wasnt the case, obtaining data from untrusted
sources, where remote unauthenticated attackers can manipulate the
content with few restrictions, is clearly not a great idea.

There are better options, such as just ignoring the log noise
from these weak password scans. If you're concerned your users may
select passwords that can be easily guessed, use cracklib, jtr,
passwordqc, etc. This is a far superior solution.

* No additional privileged code is exposed to remote attackers.
* No risk of false positive banning legitimate users.
* No number of bad logins need to be permitted before action.

If you really do insist on parsing log entries created by remote
unauthenticated users as root, and realise how dangerous that is, the
only sane solution is to parse btmp (documented in utmp(5)).

Thanks, Tavis.

-- 
-------------------------------------
taviso@....lonestar.org | finger me for my pgp key.
-------------------------------------------------------

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/