Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSL Audit

cryptoservices.github.io

Post reply on HN
Print view View original

51–60 of 82 posts

Re: OpenSSL Audit

#51

Post by coldpie »

hackuser wrote: post #23
technofiend wrote: post #12

Surprised no one has yet mentioned LibreSSL, OpenBSD's fork which happened after the last major bug. http://www.libressl.org/

Is there any coordination between OpenBSD and the Linux Foundation? For example, did the Linux Foundation consider adopting OpenBSD's fork rather than auditing and fixing the original? EDIT: What is the status of LibreSSL?

I have to say, LibreSSL's snarky PR stance when it was first launched really turned me off. This stuff is hard and the code is old; being an asshole about the code quality is really inappropriate. Has their behavior matured since then?

Re: OpenSSL Audit

#52

Post by weland »

Dewie wrote: post #50
weland wrote: post #47

Earlier quoted context omitted.

That comment sort of illustrates my point: > You should note that Rust does not allow unintialized value by design and thus it does prevent heartbleed from happening. But indeed no programming language will ever prevent logic bugs from happening. Under OpenBSD, that values would not have been uninitialized, were it not for OpenSSL's silly malloc wrapper -- a contraption of the sort that, if they really wanted, they c…

> Under OpenBSD, that values would not have been uninitialized, were it not for OpenSSL's silly malloc wrapper -- a contraption of the sort that, if they really wanted, they could probably implement on top of Rust as well. What is arguably a logic mistake compromised the protection of a runtime that, just like Rust, claimed that it would not allow uninitialized values, "by design". I really disagree. Rust does not al…

> I really disagree. Rust does not allow uninitialized values by design - end of story. If a piece of Rust code let's uninitialized values bleed through, then it is broken. The semantics of Rust demands this. (OpenSSL on the other hand only broke/Overrode OpenBSD's malloc - they didn't break C.)

I'm not familiar enough with Rust (mostly on account of being more partial to Go...), so I will gladly stand corrected if I'm missing anything here.

If the OpenSSL did the same thing they did in C -- implement their own, custom allocator over a pre-allocated memory region, would anything in Rust prevent them from the same sequence of events? That is:

1. Program receives a packet and wants 100 bytes of memory for it. 2. It asks custom_allocator to give it a 100 byte chunk. custom_allocator gives it a fresh 100 byte chunk, which is correctly initialized because this is Rust. 3. Program is done with that chunk... 4. ...but custom_allocator is not. It marks the 100 byte chunk as free for it to use them again, but continues to retain ownership and does not clear its contents. 5. Program receives a packet that claims it has 100 bytes of payload, so it asks custom_allocator to give it a chunk of 100 bytes. custom_allocator gives it the same chunk as before, without asking the Rust runtime for another (initialized!) chunk. Program is free to roam around those 100 bytes, too.

I.e. the semantics of Rust do not allow for data to be uninitialized, but custom_allocator sidesteps that.

Re: OpenSSL Audit

#53

Post by steveklabnik »

weland wrote: post #52
Dewie wrote: post #50

Earlier quoted context omitted.

> Under OpenBSD, that values would not have been uninitialized, were it not for OpenSSL's silly malloc wrapper -- a contraption of the sort that, if they really wanted, they could probably implement on top of Rust as well. What is arguably a logic mistake compromised the protection of a runtime that, just like Rust, claimed that it would not allow uninitialized values, "by design". I really disagree. Rust does not al…

> I really disagree. Rust does not allow uninitialized values by design - end of story. If a piece of Rust code let's uninitialized values bleed through, then it is broken. The semantics of Rust demands this. (OpenSSL on the other hand only broke/Overrode OpenBSD's malloc - they didn't break C.) I'm not familiar enough with Rust (mostly on account of being more partial to Go...), so I will gladly stand corrected if I…

Rust doesn't have custom allocator support yet, so no, it's not currently possible to make this error ;)

Re: OpenSSL Audit

#54

Post by pakled_engineer »

coldpie wrote: post #51
hackuser wrote: post #23

Earlier quoted context omitted.

Is there any coordination between OpenBSD and the Linux Foundation? For example, did the Linux Foundation consider adopting OpenBSD's fork rather than auditing and fixing the original? EDIT: What is the status of LibreSSL?

I have to say, LibreSSL's snarky PR stance when it was first launched really turned me off. This stuff is hard and the code is old; being an asshole about the code quality is really inappropriate. Has their behavior matured since then?

No reason you can't look at the recent commits yourself and determine if they are 'mature' enough for you.

Re: OpenSSL Audit

#55

Post by some_furry »

mintplant wrote: post #15
some_furry wrote: post #4

Earlier quoted context omitted.

If they're waiting until the summer to publish the preliminary results, this means they probably found some exploitable bugs. This is an exciting development.

I don't think so. It sounds like the audit hasn't begun yet, and they don't expect to have anything to publish until the summer.

Oh, you might be right. I must have misread it then.

Re: OpenSSL Audit

#56

Post by weland »

steveklabnik wrote: post #53
weland wrote: post #52

Earlier quoted context omitted.

> I really disagree. Rust does not allow uninitialized values by design - end of story. If a piece of Rust code let's uninitialized values bleed through, then it is broken. The semantics of Rust demands this. (OpenSSL on the other hand only broke/Overrode OpenBSD's malloc - they didn't break C.) I'm not familiar enough with Rust (mostly on account of being more partial to Go...), so I will gladly stand corrected if I…

Rust doesn't have custom allocator support yet, so no, it's not currently possible to make this error ;)

It doesn't have custom allocator support as in "you can't have one function allocate memory and pass it for another function to use it", or as in "you can't replace the runtime's own malloc"? OpenSSL were doing the former, not the latter.

(Edit: I'm really really curious, not necessarily trying to prove a point. I deal with low-level code in safety-critical (think medical) stuff every day, and only lack of time is what makes me procrastinate that week when I'm finally going to learn Rust)

Re: OpenSSL Audit

#57

Post by arca_vorago »

I have been using Hiawatha webserver which uses PolarSSL, and have avoided almost all of the recent bugs (on the servers that weren't running other things). I really like PolarSSL, but they just got bought up by ARM, so I'm a bit scared for the project.

Regarding SSL, I just generally consider it borked and try not to trust it if possible. SSH/VPN are just about the only thing I do trust (and even then with trepidation).

Once again, I think the many eyes theory only works when the code is sufficiently simple/terse. I bet if you did a study on lines of code in proportion to security vulnerabilities you would find a correlation (obviously not necessarily a causation).

Re: OpenSSL Audit

#58

Post by Ded7xSEoPKYNsDd »

AnthonyMouse wrote: post #33
Ded7xSEoPKYNsDd wrote: post #29

Earlier quoted context omitted.

> We only have to look at all the patches for java to see that it hasn't been secure. All those big security issues aren't in the Java language, they are in the JVM running untrusted Java byte code. Not to say that situation isn't bad, but you can't compare it to C++ because nobody ever thought running untrusted C++ code without some other sandboxing was a good idea. That aside, memory safety is great for security. O…

> Not to say that situation isn't bad, but you can't compare it to C++ because nobody ever thought running untrusted C++ code without some other sandboxing was a good idea. This is actually kind of a point for the other side. You can sandbox code regardless of what language it's written in. Maybe what we need is not better languages but better sandboxes. Even when code is "trusted", if the developer knows it doesn't…

> This is actually kind of a point for the other side.

I wanted to move the goalpost from "Java is insecure" to "the Java sandbox is insecure". I completely agree with the second statement, so I don't think I made a point for any other side.

Re: OpenSSL Audit

#59

Post by Alupis »

nailer wrote: post #48
tedunangst wrote: post #32

Earlier quoted context omitted.

Auditing and fixing the original still improves LibreSSL, although one of the main goals of LibreSSL was to clean things up to make that easier. Last LibreSSL release was 2.1.4 last week, although a minor update should be coming soon. http://marc.info/?l=openbsd-announce&m=142543818707898&w=2 LibreSSL is going to track OpenBSD versions, so now that OpenBSD 5.7 is done, the LibreSSL 2.1.x series is done (except to rec…

libressl's binary is already half the size of openssl. I wonder if the audit is re-doing existing work to some extent.

> libressl's binary is already half the size of openssl

What does binary size have to do with quality?

OpenSSL has been around for a long time, and still is the standard for most deployments. It will take a long time before LibreSSL has been proven enough to become the standard for anything outside the BSD community.

For as nasty as the OpenSSL code appears to be, it sure did work (and worked well) for a long time.

Remember, OpenSSL really only had 1 developer and only received around $2,000 a year in donations prior to Heartbleed[1] (which is grossly pathetic for such a critical piece of software).

If those numbers had been tenfold or more, perhaps the bugs that led to Heartbleed may have been found and fixed long before they were an issue.

Thankfully the Linux Foundation and the Core Infrastructure Initiative are aiming to remedy this.

[1] http://arstechnica.com/information-technology/2014/04/tech-g...

Re: OpenSSL Audit

#60

Post by Alupis »

pakled_engineer wrote: post #54
coldpie wrote: post #51

Earlier quoted context omitted.

I have to say, LibreSSL's snarky PR stance when it was first launched really turned me off. This stuff is hard and the code is old; being an asshole about the code quality is really inappropriate. Has their behavior matured since then?

No reason you can't look at the recent commits yourself and determine if they are 'mature' enough for you.

They did really try to seize the moment and imho did act a bit disingenuous towards OpenSSL. They even played on the point that OpenSSL's coding style wasn't "modern" and adequate and therefore made it near impossible for people to work on[1]. Since when does having curly brackets on different lines make something impossible to read?

They also gutted more than 90,000 lines in the first month (something that would be naive to claim had absolutely no unintended side effects), and claimed the OpenSSL project would not accept a single change (sort of alluding to the OpenSSL project having some delusional desire to stay "broken"), mandating the fork[1][2].

OpenSSL was largely written by cryptographers. LibreSSL is being hacked on by OpenBSD developers.

OpenSSL's code may not be pretty, but I sure think it would have been a better use of time and efforts to have the OpenBSD developers work alongside the OpenSSL cryptographers.

[1] http://www.infoq.com/news/2014/05/libre-ssl-first-30-days

[2] http://arstechnica.com/information-technology/2014/04/openss...

Post reply on HN