Are we better off using decoder rings and snail mail at this point?
Don't forget to drink your Ovaltine!
Null pointer dereference – new security bug for OpenSSL
11–20 of 38 posts
Re: Null pointer dereference – new security bug for OpenSSL
#12Like I said in the other thread on 5.5, make sure you update for the patches. http://www.openbsd.org/errata55.html
This one is listed on that page (bottom 005: SECURITY FIX: May 1, 2014).
Re: Null pointer dereference – new security bug for OpenSSL
#13Good to note that this was found with KLEE[1]. KLEE is a good for symbolic execution of code and is very cool[2].
This only triggers a crash if you use RELEASE_BUFFERS (not the default) and a warning alert is written when the socket buffer is full. About the only case where a warning alert is generated is when a client attempts a renegotiation without the renegotiation extension (unless insecure renegotiation is allowed by the app). I've not been able to trigger the bug in a test because code generally stops reading once the socket buffer is full so you need the application to exactly fill the socket buffer (so that it doesn't get EAGAIN), then a warning alert can just exceed it.
[1] http://marc.info/?l=openssl-dev&m=139809493725682&w=2 [2] http://klee.github.io/klee/
Re: Null pointer dereference – new security bug for OpenSSL
#14Like I said in the other thread on 5.5, make sure you update for the patches. http://www.openbsd.org/errata55.html This one is listed on that page (bottom 005: SECURITY FIX: May 1, 2014).
I think they are sending out e-mails about new patches.
Re: Null pointer dereference – new security bug for OpenSSL
#15Is it me or should code that has to be secure be written in more manage languages to prevent these mistake ? (But managed languages probably have other security issues I don't know about ?)
Re: Null pointer dereference – new security bug for OpenSSL
#16[deleted]
Re: Null pointer dereference – new security bug for OpenSSL
#17Is it me or should code that has to be secure be written in more manage languages to prevent these mistake ? (But managed languages probably have other security issues I don't know about ?)
Managed languages is one way to go, but they are not really appropriate for performance critical libraries like OpenSSL in my book. You can get safety without being managed in modern languages if the compiler does the safety proving for you (e.g. rustlang).
Re: Null pointer dereference – new security bug for OpenSSL
#18Are there any write ups for this yet? I can't find a CVE or anything on this one. No word from OpenSSL yet either.
This shouldn't be exploitable on modern linux machines due to https://wiki.debian.org/mmap_min_addr
Who knows for embedded devices.
Re: Null pointer dereference – new security bug for OpenSSL
#19Is it me or should code that has to be secure be written in more manage languages to prevent these mistake ? (But managed languages probably have other security issues I don't know about ?)
Managed languages are very susceptible to timing attacks.
Re: Null pointer dereference – new security bug for OpenSSL
#20Is it me or should code that has to be secure be written in more manage languages to prevent these mistake ? (But managed languages probably have other security issues I don't know about ?)
If OpenSSL was written in a managed language, someone would need it in an environment a managed language wasn't suitable for, and end up porting it to C.