HN Explorer

37 comments

[ 194 ms ] story [ 2486 ms ] thread
openbsddesktop
You can thank the people that found the bug here:

http://www.openbsdfoundation.org/donations.html

http://www.openbsd.org/donations.html

http://www.openbsd.org/want.html

dang
It's a worthy cause, but please don't repeatedly post these comments. Neither fundraising campaigns nor single-purpose accounts are appropriate in HN threads.
eyeareque
Are there any write ups for this yet? I can't find a CVE or anything on this one. No word from OpenSSL yet either.
Moral_
This shouldn't be exploitable on modern linux machines due to https://wiki.debian.org/mmap_min_addr

Who knows for embedded devices.

lawnchair_larry
It wouldn't be exploitable even without that, due to it being a userland dereference. The mmap 0 trick really only applies to kernel exploits. If you're in a position to mmap anything, you can already execute code.
agl
Good 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/

Qantourisc
Is 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 ?)
dcsommer
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).
[dead] l0ngpoke
> Managed languages [...] are not really appropriate for performance critical libraries like OpenSSL

This is complete bullshit. Please cite where you found these results. Even if this was true, since the servers also run openssl, you'd be able to at least run a client at 10x/100x/1000x the speed of the server (because the client doesn't have to have concurrent connections), which would make the "slow managed code" fine for a client.

akjj
Managed languages are very susceptible to timing attacks.
[dead] longpoke
Fuck off. So is C, and C has no semantics whatsoever that prevent them, i.e, if one output from the compiler has no side channel vulns, the very next output may indeed have them.
[dead] l0ngpoke
No they aren't fuck you.
pslam
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.
[dead] longpoke
That doesn't even make sense. Also avoid using vague Microsoft-slang. Memory-safe is a much better term.
[dead] longpoke
No, it's not just you. I've been saying this for 5 years (Since about a year after I learned to program), and nobody gives a fuck / is competent enough to rewrite the stuff on solid foundations.
Qantourisc
For all clarity I meant like C++, ObjC, or others; any language that allows you to create things that enforce consistency during compile or runtime. (Like shared pointer and array containers.) Probably used the wrong terminology here.
[deleted]
(comment deleted)
ams6110
That patch is set up for a later bug to be introduced: no brackets on the if statements.

Instead of:

  +		if (wb->buf == NULL)
  +			if (!ssl3_setup_write_buffer(s))
  +				return -1;
Why not:

  +		if (wb->buf == NULL) {
  +			if (!ssl3_setup_write_buffer(s)) {
  +				return -1;
  +			}
  +		}
codezero
or

  if ((wb->buf == NULL) && !ssl3_setup_write_buffer(s)) {
     return -1;
  }
insaneirish
This is OpenBSD Kernel Normal Form (http://www.openbsd.org/cgi-bin/man.cgi?query=style&sektion=9).

Disagree you may, but it's consistent with their self-imposed guidelines.

codezero
Sort of. They say only if it's a single line that it's not allowed. If there are multiple lines it's "permitted."

So technically, this is still OK, but they are allowed to use braces when there are multiple lines. (the if and the return) They have an example in that link that covers this as a permitted case, but as you say, it's OK and consistent, but that doesn't make it good :)

ibotty
this is getting boring. ever time a patch using no parentheses shows up there is that comment. if all your code uses that style you get used to it. feel free to show evidence of openbsd making that mistake once! (there might have been those, but i am sure it's going to be very hard to find).
nextw33k
Perhaps you need to consider the bigger picture. The biggest part of being a programmer is not in how many characters we write but in how we are able to know and understand abstract concepts.

If writing defensively by always putting braces around if statements means we no longer have to consider the possibility of a fall through error, then that saves mental processing for you and more importantly for lesser programmers.