libssh and stunnel PRNG flaws

2014.03.05
Risk: Low
Local: No
Remote: Yes
CWE: N/A

Hi All, Aris Adamantiadis reported the following to us: I have found a vulnerability in stunnel (fork mode) and libssh server (if implemented with fork) that is similar to problems found in postgresql [1]. When accepting a new connection, the server forks and the child process handles the request. The RAND_bytes() function of openssl doesn't reset its state after the fork, but simply adds the current process id (getpid) to the PRNG state, which is not guaranteed to be unique. stunnel uses libssl, which also seeds the PRNG with the output of time(NULL), which means that vulnerability has to be exploited under a second. I have exploit code that can reproduce the issue on OpenBSD 5.4 (thanks to random PIDs) but I think it may be exploitable on other unix systems as well. The following CVEs have been assigned: CVE-2014-0016 stunnel PRNG vulnerability CVE-2014-0017 libssh PRNG vulnerability Mitigations implemented into openssl-0.9.8j (2009) makes the vulnerability not exploitable in stock openssl. The signing code for ECDSA and DSA explicitly seeds the pool with the digest to sign. References: libssh: https://bugzilla.redhat.com/show_bug.cgi?id=1072191 http://www.libssh.org/2014/03/04/libssh-0-6-3-security-release/ http://git.libssh.org/projects/libssh.git/commit/?id=e99246246b4061f7e71463f8806b9dcad65affa0 stunnel: https://bugzilla.redhat.com/show_bug.cgi?id=1072180 There is no upstream patch yet Regards, -- Huzaifa Sidhpurwala / Red Hat Security Response Team

References:

https://bugzilla.redhat.com/show_bug.cgi?id=1072191
http://www.libssh.org/2014/03/04/libssh-0-6-3-security-release/
http://git.libssh.org/projects/libssh.git/commit/?id=e99246246b4061f7e71463f8806b9dcad65affa0
https://bugzilla.redhat.com/show_bug.cgi?id=1072180


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top