defcon-russia talk about OpenSSL fork-safe vulns.

1. OpenSSL rands
(fork-safe)
By @ONsec_Lab
Sep 15, 2013

2. @ONsec_lab
● Security auditors
● Since 2009 year
● Web, sex and rock’
n’roll
http://lab.onsec.ru
/whoami

3. premise
http://emboss.github.
io/blog/2013/08/21/openssl-
prng-is-not-really-fork-safe/
OpenSSL PRNG Is Not (Really)
Fork-safe
Aug 21st, 2013
Martin Boblet used Eric
Wong’s issues

4. premise
● About Ruby OpenSSL wrapper (OpenSSL::
Random)
● OpenSSL PRNG must be initialized in the
parent before we fork the child processes
● Every child starts out with exactly the same
PRNG
● PID is the only thing process-specific that is
fed to the PRNG algorithm when requesting
random bytes

5. premise

6. Debian!

7. But...
● Debian guys commented MD_Update call
with UNINITIALISED variable
● We believe that they did the right thing ;)

8. non-Debian systems
● Vulnerability exists in all system (Debian and
non-Debian also)
● Exploitation possibility depends only from
end-point code (application, not OpenSSL)
● There are two different places for buf:
○ Stack
○ Heap
● Let’s try to hack it!

9. stack-based PoC (all OS)
https://github.com/ONsec-Lab/Rand-
attacks/blob/master/openssl-1.c
from different
calls to the same
==
from different
stack states to
the same!

10. heap-based PoC (all OS)
https://github.com/ONsec-Lab/Rand-
attacks/blob/master/openssl-2.c
malloc
allocates
nulled
memory
page

11. other attacks
● i.e. PHP initialize RAND after fork
● But classic attacks way still available
○ Keep-Alive -> rands on same PID
○ Brute seed by rands
○ Predict rand by seed + offset
● What about entropy of OpenSSL RAND?
○ 128 bytes * 20 (GID*UID) * 32k (PID)
○ Not so little :(

12. just recommend!
http://lwn.net/Articles/281918/ [2008]
http://research.swtch.com/openssl [2008]
http://mjos.fi/doc/secadv_prng.txt [2001]
Do not be afraid names and brands, such as
OpenSSL

13. OpenSSL rands (fork-safe)
The end.
follow us:
http://lab.onsec.ru
@ONsec_lab twitter