Previously discussed: <a href="https://news.ycombinator.com/item?id=7682537" rel="nofollow">https://news.ycombinator.com/item?id=7682537</a><p>My comment from last time:<p>Good to note that this was found with KLEE[1]. KLEE is a good for symbolic execution of code and is very cool[2].<p>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.<p>[1] <a href="http://marc.info/?l=openssl-dev&m=139809493725682&w=2" rel="nofollow">http://marc.info/?l=openssl-dev&m=139809493725682&w=2</a> [2] <a href="http://klee.github.io/klee/" rel="nofollow">http://klee.github.io/klee/</a>
I can't see why the headline says this is exclusive to Debian stable - it applies to any distribution that shipped with OpenSSL 1.0 or greater. The RH bugtracker only mentions that RHEL5 is immune because they didn't ship OpenSSL 1.0. It seems that several packages enable SSL_MODE_RELEASE_BUFFERS including ruby and node:<p><a href="https://bugzilla.redhat.com/show_bug.cgi?id=1093837#c1" rel="nofollow">https://bugzilla.redhat.com/show_bug.cgi?id=1093837#c1</a>
Good thing this only affects %29.8 of Linux distros out there (<a href="http://w3techs.com/technologies/details/os-linux/all/all" rel="nofollow">http://w3techs.com/technologies/details/os-linux/all/all</a>) :P