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]
Message-ID: <20070607093141.GD9415@sdf.lonestar.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ