Fixed and pushed in Cauldron.


Suggested Advisory:
========================

A flaw discovered in denyhosts, a tool preventing SSH brute-force attacks, could be used to perform remote denial of service against the SSH daemon. Incorrectly specified regular expressions used to detect brute force attacks in authentication logs could be exploited by a malicious user to forge crafted login names in order to make denyhosts ban arbitrary IP addresses.

References:
http://openwall.com/lists/oss-security/2013/12/22/4
http://www.debian.org/security/2013/dsa-2826
========================

Updated mageia 3 packages in core/updates_testing:
denyhosts-2.6-4.2.mga3

Source RPM:
denyhosts-2.6-4.2.mga3.src.rpm

Status: NEW => ASSIGNED
URL: (none) => http://openwall.com/lists/oss-security/2013/12/22/4
CC: (none) => cooker
Assignee: cooker => qa-bugs

Thanks Johnny!

Just some minor formatting changes to the advisory.

Advisory:
========================

Updated denyhosts package fixes security vulnerability:

Helmut Grohne discovered that denyhosts, a tool preventing SSH brute-force
attacks, could be used to perform remote denial of service against the SSH
daemon. Incorrectly specified regular expressions used to detect brute force
attacks in authentication logs could be exploited by a malicious user to forge
crafted login names in order to make denyhosts ban arbitrary IP addresses
(CVE-2013-6890).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6890
http://www.debian.org/security/2013/dsa-2826

Version: Cauldron => 3
Whiteboard: MGA3TOO => (none)

Testing mga3 64 

tl;dr - it doesn't seem to close the CVE.

PoC: http://openwall.com/lists/oss-security/2013/12/22/4

Edited /etc/denyhosts.conf and changed DENY_THRESHOLD_INVALID to equal 1 to save time.

Started denyhosts service and then..

Before
------
$ ssh -l 'Invalid user root from 123.123.123.123' localhost
Password: 

Interrupt with ctrl-c and repeat.

then..

# cat /etc/hosts.deny 

#
# hosts.deny    This file describes the names of the hosts which are
#               *not* allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!

# DenyHosts: Wed Jan 22 16:55:16 2014 | sshd: 123.123.123.123
sshd: 123.123.123.123

showing it has added the faked IP address to /etc/hosts.deny
removed it manually, not sure if there is a proper way.

After
-----
Restarted the service and checked /etc/hosts.deny

Repeated the PoC but checking /etc/hosts.deny it has added it again.

# cat /etc/hosts.deny 

#
# hosts.deny    This file describes the names of the hosts which are
#               *not* allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!
# DenyHosts: Wed Jan 22 17:02:46 2014 | sshd: 123.123.123.123
sshd: 123.123.123.123

# rpm -q denyhosts
denyhosts-2.6-4.2.mga3

Also it leaves it there when the package is removed.

Whiteboard: advisory => advisory feedback

rpmdiff shows nothing changed in the rpm Johnny, might be worth checking cauldron too.

Indeed, the patch was added to the package, but not actually applied in the %prep section.  Assigning back to Johnny.

CC: (none) => qa-bugs
Version: 3 => Cauldron
Assignee: qa-bugs => cooker
Whiteboard: advisory feedback => MGA3TOO

(In reply to David Walser from comment #5)
> Indeed, the patch was added to the package, but not actually applied in the
> %prep section.  Assigning back to Johnny.

Gaah.
The patch had to be rediffed, as one of our patches (P10) made it incompatible with P12 from Debian.

Have uploaded a new release in mga3 core/updates_testing:
denyhosts-2.6-4.3.mga3

Source RPM:
denyhosts-2.6-4.3.mga3.src.rpm

Please someone look over the changed patch, to make sure I didn't screw it up by adding a new security hole.
I have renamed P12 slightly (renamed "deb" to "deb-mga") to reflect that the Debian patch is modified my us.

If the patch looks ok, I'll commit and ask for a freeze push to Cauldron also.

(In reply to Johnny A. Solbu from comment #6)
> The patch had to be rediffed, as one of our patches (P10) made it
> incompatible with P12 from Debian.

Specifically it's the "FAILED_ENTRY_REGEX7" line in the patch that I had to modify to make the patch work. I /think/ I understand the change good enouch to make the required changes to our version of the file. But I'm not a python developer, do I could be wrong. :-)

Did you check cauldron package too Johnny?

(In reply to claire robinson from comment #8)
> Did you check cauldron package too Johnny?

Yes, and it have the same issue. Which is why I'm waiting a little to see if the rediffed patch looks ok before commiting and asking for a freeze push.

Testing complete Mga3 64

Set all the thresholds to 1 occurrence.

$ ssh -l 'Invalid user root from 123.123.123.123' localhost

No longer triggers a false set so the potential DoS is fixed.

Tested logins from another computer with false user (ie. ssh xyz@host) which did trigger it and prevents further logins from that host which IINM should test invalid user still works ok. Also tried with root@ which triggered it too.

Seems to do the trick Johnny but we can't push this until it has been pushed in cauldron first.

Testing complete mga3 32

Actually, using the PoC from a remote computer does trigger the blocking but it blocks the correct IP rather than the faked IP, so proves the regex is good.


Advisory already uploaded, now updated.

Validating


Could sysadmin please push to updates only after cauldron freeze push to fix the patching.

Thanks

Keywords: (none) => validated_update
Version: Cauldron => 3
Whiteboard: MGA3TOO has_procedure mga3-64-ok => has_procedure advisory mga3-64-ok mga3-32-ok
CC: (none) => sysadmin-bugs

The fix has been submitted in Cauldron.

Debian has corrected a regression caused by the fix for this on January 23:
https://lists.debian.org/debian-security-announce/2014/msg00018.html

Johnny, you might want to update this again...

(In reply to David Walser from comment #14)
> Debian has corrected a regression caused by the fix for this on January 23:
> https://lists.debian.org/debian-security-announce/2014/msg00018.html
> 
> Johnny, you might want to update this again...

I have uploaded a new release in mga3 core/updates_testing with the new fix:
denyhosts-2.6-4.4.mga3

Source RPM:
denyhosts-2.6-4.4.mga3.src.rpm

Have just asked for a freeze push in Cauldron, too.

Thanks Johnny!  denyhosts-2.6-10.mga4 uploaded for Cauldron.

This will need to be revalidated for Mageia 3.

Keywords: validated_update => (none)
Whiteboard: has_procedure advisory mga3-64-ok mga3-32-ok => has_procedure

I just tested denyhosts-2.6-4.4.mga3 on mga3-64. As per Claires previous tests, all seems to behave properly (albeit aggressively blocking the machine I was testing from, but then that's kinda the point :p).

CC: (none) => mageia
Whiteboard: has_procedure => has_procedure mga3-64-ok

Testing mga3-i586.

CC: (none) => pierre-malo.denielou

I noticed that denyhosts would fail to start properly if sshd is not running. The error message is ugly and not helpful.

Feb 16 14:04:34 localhost denyhosts[13078]: Starting denyhosts: Can't read: /var/log/auth.log
Feb 16 14:04:34 localhost denyhosts[13078]: [Errno 2] No such file or directory: '/var/log/auth.log'
Feb 16 14:04:34 localhost denyhosts[13078]: Error deleting DenyHosts lock file: /var/lock/subsys/denyhosts
Feb 16 14:04:34 localhost denyhosts[13078]: [Errno 2] No such file or directory: '/var/lock/subsys/denyhosts'

Shouldn't there be a service dependency from denyhosts to sshd? As it is, at install, if sshd is running, then denyhosts will run fine. If sshd is not running, then denyhosts will not start automagically when sshd is activated.

On the proper testing, the fix works.

Whiteboard: has_procedure mga3-64-ok => has_procedure mga3-64-ok mga3-32-ok

Validating update for the security fix. Another bug report can be used if some fixing is required as per Malo's comment 19.

Advisory has been updated for the latest SRPM (and a mention added regarding the fixed regression). Please push to 3 core/updates.

Keywords: (none) => validated_update
CC: (none) => remi
Whiteboard: has_procedure mga3-64-ok mga3-32-ok => has_procedure mga3-64-ok mga3-32-ok advisory

Update pushed:
http://advisories.mageia.org/MGASA-2014-0080.html

Status: ASSIGNED => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED