OpenBSD Team Cleaning Up OpenSSL

First time accepted submitter Iarwain Ben-adar (2393286) writes "The OpenBSD has started a cleanup of their in-tree OpenSSL library. Improvements include removing "exploit mitigation countermeasures", fixing bugs, removal of questionable entropy additions, and many more. If you support the effort of these guys who are responsible for the venerable OpenSSH library, consider a donation to the OpenBSD Foundation. Maybe someday we'll see a 'portable' version of this new OpenSSL fork. Or not."

Comments

de Raadt

[Anonymous Coward]

Yes, Theo has a bad temper and is not filtering carefully enough what he says, but his heart is in the right place, and he's a fucking great leader. I don't mind one bit his bad temper, because it usually hits those that really deserve it. And on the other hand, he's one of the most effective open source leaders.

Re:de Raadt

[bluefoxlucid]

He is technically incapable of evaluating what's actually happening, and likes to go off-list when he's angry and wrong.

The freelist is not an "exploit mitigation countermeasure", but rather standard allocation caching behavior that many high-rate allocation applications and algorithms implement--for example, ring buffers are common as all hell. The comment even says that it's done because performance on allocators is slow.

Further, the only bug in Heartbleed was a READ OVERFLOW BUG caused by lack of input validation. It would actually read that a user said "This heartbeat is 65 thousand bytes long", allocate 65 thousand bytes plus room for instrumentation data, put instrumentation data in place, and then copy 65 thousand bytes from a request that was 1 byte long. While there are mitigation techniques, most allocators--anything that uses brk() to allocate the heap for allocations smaller than say 128KB (glibc's pmalloc and freebsd's kmalloc both use brk() until you ask for something bigger than 128KB, then use mmap())--don't do that. That's how this flaw worked: It would just read 64KB, most likely from the brk() area, and send it back to you.

Read overflows don't kill canaries, so you wouldn't detect it except for with an unmapped page--a phenomena that doesn't happen with individual allocations smaller than 128KB in an allocator that uses brk(), like the default allocator on Linux and FreeBSD. Write overflows would kill canaries, but they actually allocated enough space to copy the too-large read into. And the code is, of course, correct for invalid input.

Theo made a lot of noise about how all these other broken things were responsible for heartbleed, when the reality is one failed validation carries 100% of the weight for Heartbleed. If you perfectly cleaned up OpenSSL except for that single bug, slapped it on Linux with the default allocator, and ran it, it would still have the vulnerability. And it only behaves strange when being exploited--and any test would have sent back a big packet, raising questions.

There was never really any hope that this was going to be caught before it was in the wild and "possibly had leaked your SSL keys'. It may have happened sooner, maybe, maybe not; but it still would have been a post-apocalyptic shit storm. And all those technical mitigations Theo is prattling on about would have helped if OpenSSL were cleaned up... AND if those technical mitigations were in Linux, not just OpenBSD.

Re:de Raadt

[EvanED]

The freelist is not an "exploit mitigation countermeasure",...

He was being somewhat sarcastic, because OpenBSD's allocator is in contrast to

Read overflows don't kill canaries, so you wouldn't detect it except for with an unmapped page--a phenomena that doesn't happen with individual allocations smaller than 128KB in an allocator that uses brk(), like the default allocator on Linux and FreeBSD

and does try to separate allocations specifically to mitigate Heartbleed-style vulnerabilities.

In other words, the OpenBSD allocatior does have exploit mitigation, and the OpenSSL freelist acts as a countermeasure to those mitigation capabilities whether it was intended or not.

The comment even says that it's done because performance on allocators is slow.

It says it's slow on "some platforms", yet they disabled it on all and then didn't test the alternative.

But of course everyone knows it's way better to quickly implement a dramatically awful security vulnerability than to do things slowly and correctly.

Re:de Raadt

[bmajik]

Actually, it is you who are wrong.

Theo's point from the beginning is that a custom allocator was used here, which removed any beneficial effects of both good platform allocators AND "evil" allocator tools.

His response was a specific circumstance of the poor software engineering practices behind openSSL.

Furthermore, at some point, openSSL became behaviorally dependant on its own allocator -- that is, when you tried to use a system allocator, it broke -- because it wasn't handing you back unmodified memory contents you had just freed.

This dependency was known and documented. And not fixed.

IMO, using a custom allocator is a bit like doing your own crypto. "Normal people" shouldn't do it.

If you look at what open SSL is

1) crypto software
2) that is on by default
3) that listens to the public internet
4) that accepts data under the control of attackers ... you should already be squarely in the land of "doing every possible software engineering best practice possible". This is software that needs to be written differently than "normal" software; held to a higher standard, and correct for correctness sake.

I would say that, "taking a hard dependence on my own custom allocator" and not investigating _why_ the platform allocator can no longer be used to give correct behavior is a _worst practice_. And its especially damning given how critical and predisposed to exploitability something like openSSL is.

Yet that is what the openSSL team did. And they knew it. And they didn't care. And it caught up with them.

The point of Theo's remarks is not to say "using a system allocator would have prevented bad code from being exploitable". The point is "having an engineering culture that ran tests using a system allocator and a debugging allocator would have prevented this bad code from staying around as long as it did"

Let people swap the "fast" allocator back in at runtime, if you must. But make damn sure the code is correct enough to pass on "correctness checking" allocators.

Re:de Raadt

[radarskiy]

"not an "exploit mitigation countermeasure", but rather standard allocation caching behavior"

There is a bug where memory is used after being freed which is hidden by the custom nonclearing LIFO freelist, i.e. you could realloc and get your record back. If you tried to use a normal malloc it would fail. Clearing memory exposes others bugs so no one was willing to clear memory.

"The comment even says that it's done because performance on allocators is slow. "

It was slow on some architectures, at the time, so they worked around it on all architectures permanently. Thus the subverted the OSS benefit on 'many eyeballs" and did so ON SECURITY SOFTWARE.

Re:de Raadt

[bluefoxlucid]

Yes yes of course but you're missing the point. We'll ignore that sarcasm doesn't carry and that the exploit mitigation stuff in OpenSSL has been repeated again and again without a hint of irony and so one may be lead to believe such a thing exists in OpenSSL.

First off,

And all those technical mitigations Theo is prattling on about would have helped if OpenSSL were cleaned up... AND if those technical mitigations were in Linux, not just OpenBSD.

Here's the thing: OpenBSD is a hobby OS. It's like Linux with grsecurity: yes they've mitigated all this shit ages ago, yes people run grsecurity in production, yes anything that grsecurity "would have prevented" is effectively unprotected because damn near no one runs grsecurity. If someone asked me to bet on whether there was more OpenBSD or more grsecurity in production on machines installed by system administrators starting from bare metal (i.e. not appliances that are mystery boxes that nobody reads the logs on nor updates nor understands anyway), I would avoid the bet.

OpenBSD's allocator is what we call "Proof of Concept". OpenBSD is what we call "Proof of Concept". It exists somewhere in real life, you can leverage it (I've leveraged proof-of-concept exploit code from Bugtraq in actual exploit kits), but it's not this ubiquitous thing that's out there enough to have an impact on the real world. BSDs are estimated to be about 1.0% of all servers on the Internet (as of February 2014, sorry don't have current numbers), OpenBSD a portion of that, FreeBSD a bigger portion. That means most of everyone interesting--Suntrust, Bank of America, slashdot, the NSA, Verisign, Microsoft, Google--is running a non-OpenBSD operating system with no such protections.

And again, the concept of allocation caching is common. Freelists are used when allocations are all the same size; that gripe is essentially that a valid data object is not valid because they dislike it. Plenty of software uses freelists, and freelists are a generalization of the object pool software design pattern used for database connection caching in ORMs, token caching in security systems, and network buffers (ring buffer...). I would be surprised if OpenBSD's libc and kernel didn't make use of freelists or object pools somewhere.

Also it's funny that you ignored the whole "this vulnerability would have happened basically everywhere anyway and the impact would have been the same even if all other code besides what's in this one function was perfect" thing. Mickens warned me about people like you:

Security people are like smarmy teenagers who listen to goth music: they are full of morbid and detailed monologues about the pervasive catastrophes that surround us, but they are much less interested in the practical topic of what people should do before we’re inevitably killed by ravens or a shortage of black mascara.

The “threat model” section of a security paper resembles the script for a telenovela that was written by a paranoid schizophrenic: there are elaborate narratives and grand conspiracy theories, and there are heroes and villains with fantastic (yet oddly constrained) powers that necessitate a grinding battle of emotional and technical attrition. In the real world, threat models are much simpler (see Figure 1). Basically, you’re either dealing with Mossad or not-Mossad. If your adversary is not-Mossad, then you’ll probably be fine if you pick a good password and don’t respond to emails from ChEaPestPAiNPi11s@virus-basket.biz.ru. If your adversary is the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING THAT YOU CAN DO ABOUT IT. The Mossad is not intimidated by the fact that you employ https://./ If the Mossad wants your data, they’re going to use a drone to replace your cellphone with a piece of uranium that

Re:de Raadt

[PhrostyMcByte]

If Theo had a more constructive outlook, this would go a lot different and we'd all benefit.

Instead of screaming vitriol at someone's app architecture inadvertently defeating his platform-specific feature, he should be asking why they felt the need to go with that architecture (hint: it was a perfectly reasonable need), and perhaps if he can do something to make integrating his security feature easier for that type of architecture.

Like you say, freelists are an extremely common design choice when performance is critical. This security feature could be hugely beneficial to many apps that use them (like, say, Apache HTTPd). Instead you've got the too-common case of an unbending programmer mad at someone for having needs other than his own.

Re:de Raadt

[Anonymous Coward]

Indeed.

So many people operate under the idea that leaders should be popular and kind. Ummm, no... A leader's job is to lead and be effective, not be popular. If he's both, great! If he comes across as harsh but leads well, consider yourself blessed. I know a thing or two about leadership, having been in and around the military for over 20 years. The best leaders care not for popularity. They care about results. If a leader even thinks about popularity, they are not the right person for the job. Full stop.

I've been following Theo and other open source leaders for many years, reading the mailing lists, attend seminars, you name it. Theo is a good leader who has a ton of crap to deal with. He's competent, cares about who and what matters, dismisses what doesn't and moves on and takes care of business. I doubt there are more than a handful of people on earth who could do what Theo and Linus do and do it any better. Even RMS. Each man has a leadership style all their own. Personally, if I had to work for any of them, I'd pick Theo. Why? Because he expects you to know what you're doing and just do it. No fanfare. No BS. It's the work environment I like best. Just shut up and hack!

Re:de Raadt

[bluefoxlucid]

OpenSSL is broken in many ways. I dispute that the specific citations are technically correct: that unbreaking use of the system allocator would have made Heartbleed not happen; and that heartbleed was an allocation bug (this was alleged as a use-after-free early in this whole theater, but it's not; it's a validation bug, it reads too much, and it allocates an appropriate buffer of appropriate size to write to).

Look up freelists and object pooling. These design patterns are common and considered important. OpenSSL has MANY defects; use of a freelist isn't one of them, but inability to run on the allocator (for MANY reasons) is.

Let people swap the "fast" allocator back in at runtime, if you must. But make damn sure the code is correct enough to pass on "correctness checking" allocators.

If 100% of OpenSSL except those few lines in that one function were correct, OpenSSL would work on OpenBSD's allocator UNLESS being exploited, and even then it would be possible to extract some memory without tripping the protection. But, yes, the protection would catch an exploit. Normal operation? Nope.

The other side of that: most OS allocators don't have that protection, so in practice the vulnerability wouldn't get caught. And of course if it's in the wild, we have the situation we have today--this is not less-severe because it's shorter duration; you don't know if you were hacked, so you must assume your keys are compromised.

Bitch about this instead. A fucking static checker found heartbleed.

Re:de Raadt

[Xylantiel]

I disagree that there was no way to catch this. From code I saw, at its core, it was a simple case of using memcpy with the size of the destination buffer rather than the source buffer. Any automated bounds checker would have caught this. But, in addition, there should have been a compliance test that a packet with a specified size bigger than its payload went unanswered since anything else is noncompliant with the RFC. Clearly the person who wrote the RFC understood that answering a heartbeat request with a size different than its payload was a potential problem since the behavior was specified. To me, both of these mean that OpenSSL is enough lacking in validation testing to make me pretty nervous. No wonder everybody has been sticking to 0.9 versions for years if the path forward is this fraught with uncertainty.

Re:de Raadt

[bluefoxlucid]

There is a bug where memory is used after being freed which is hidden by the custom nonclearing LIFO freelist, i.e. you could realloc and get your record back.

Yeah, and that bug is unrelated to Heartbleed: heartbleed reads beyond the end of an allocation, and allocates a big enough allocation to store all that, and then sends it and frees the allocation. In its own little atom of horrible mishandling of program execution, it's fully consistent except for reading off the end of an allocation. There are no double-frees or use-after-frees causing heartbleed; the entire bug is a memcpy() that's too long.

Thus the subverted the OSS benefit on 'many eyeballs" and did so ON SECURITY SOFTWARE.

You can read the code. Hell, a static checker found Heartbleed. That's the many eyeballs. And the whole argument about OpenBSD's fancy crap finding Heartbleed is fallacious: it would only catch Heartbleed on OpenSSL 1.0.1 on OpenBSD compiled with the freelist off and ONLY WHEN BEING ACTIVELY EXPLOITED. OpenBSD isn't exactly the most popular OS on production servers, and the protections in OpenBSD aren't widely implemented in allocators.

Re:de Raadt

[bluefoxlucid]

I don't think there's something broken about OpenBSD's allocator. Performance trade-off, yeah. Broken, no.

I think the target of all this ire is a lot of technically incorrect bullshit, like calling freelists irresponsible programming or claiming that something in the allocator broke OpenSSL (it didn't; the bug was wholly self-contained), or trying to claim that OpenBSD would have caught the bug for some odd reason or another when it can only be caught in that way (with secure allocators) when actively exploited--and most targets are not OpenBSD and do not use an OpenBSD-style allocator.

Theo is making up theoretical situations and giving blatantly incorrect technical analysis of things that, while broken, are either not broken in that way or would not have mitigated that bug if fixed, either in theory or in practice.

Re:de Raadt

[bluefoxlucid]

Yeah. I don't agree with the conjectures about how fixing X problem would have caught this because it would have to be tested/exploited to be caught even in the absolute most strict case (100% of all code except that one function correct). If somebody would have thought to do a test for a bad payload length, they would have thought to fix it.. or got a huge packet back and gone wtf? And if you tested it otherwise, you wouldn't trigger any invalid behavior.

A static checker did specifically identify heartbleed. Nobody really ran a static checker either.

Re:de Raadt

[Dahan]

Bitch about this instead. A fucking static checker found heartbleed.

No, it says, "Coverity did not find the heartbleed bug itself", which very clearly means that Coverity did not find Heartbleed. And Coverity themselves confim that Coverity does not detect the problem (though in response, they've added a new heuristic that does detect it, but no word on how the new heuristic affects the false positive rate).

Re:de Raadt

[shallot]

[...]

OpenBSD is what we call "Proof of Concept".

[...]

Bitch about that instead.

/me grabs popcorn :D

Re:de Raadt

[bmajik]

Who has claimed that using the system allocator, all else being equal, would have prevented heartbleed?

Who has claimed that heartbleed was an allocation bug?

I understand what freelists are and do.

The point here is that rigorous software engineering practices -- including the use of evil allocators or static analyzers that could actually understand they were looking at heap routines -- would have pointed out that the code implicated in heartbleed was unreliable and incorrect.

If you read the link you pointed at, after making a modification to OpenSSL such that coverity could understand that the custom allocator was really just doing memory allocation, Coverity reported 173 additional "use after free" bugs.

There are bugs from years ago showing that openSSL fails with a system allocator.

Don't you suppose that in the process of fixing such bugs, it is likely that correctness issues like this one would have been caught?

Re:de Raadt

[Anonymous Coward]

There is a bug where memory is used after being freed which is hidden by the custom nonclearing LIFO freelist, i.e. you could realloc and get your record back.

Yeah, and that bug is unrelated to Heartbleed: heartbleed reads beyond the end of an allocation, and allocates a big enough allocation to store all that, and then sends it and frees the allocation. In its own little atom of horrible mishandling of program execution, it's fully consistent except for reading off the end of an allocation. There are no double-frees or use-after-frees causing heartbleed; the entire bug is a memcpy() that's too long.

Although "bug is a memcpy() that's too long" is technically correct (in a way), it's incomplete. Your lack of understanding of the implication of the "let's reuse that memory we just freed" in the whole heartbleed mess is appaling.

Thus the subverted the OSS benefit on 'many eyeballs" and did so ON SECURITY SOFTWARE.

You can read the code. Hell, a static checker found Heartbleed. That's the many eyeballs.

From that link you keep posting all around: "Coverity did not find the heartbleed bug itself" ... mind commenting ?

Re:de Raadt

[bluefoxlucid]

The Frama-C value analyzer tracks an integer variable using an interval: a representation of the smallest and largest value that the integer could contain at some program point. Upon reaching the problematic memcpy() call in t1_lib.c, the value of payload is in the interval [0..65535]. This interval comes from the n2s() macro which turns two arbitrary-valued bytes from the client into an unsigned int

The dest argument of this memcpy() turns out to be large enough. However, the source buffer is way too small. Frama-C would gripe about this and it would not shut up until the bug was really fixed.

How much effort would be required to push OpenSSL through Frama-C? I don’t know, but wouldn’t plan on getting this done in a week or three.

Thank you for playing.

Re:de Raadt

[bluefoxlucid]

Rigorous practices and robust design concepts universally reduce the likelihood of bad things. Trust me, I'm a risk management guy, I know how this shit works.

So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys.

The above quote by Theo spawned a whole lot of chatter about how Heartbleed was caused by double-free or use-after-free. The above says that memory would be handed to munmap(), which people have interpreted as to say, "Oh, OpenSSL was copying a buffer that it had already freed, that's heartbleed". No, not really. There are all kinds of tangential arguments here--for example: if it worked as above, the allocator could have also put an unmapped block between allocations, making whether or not another allocation was freed irrelevant. But really, the bug is this: a memcpy() from a validly-allocated buffer that hasn't been freed, but it copies a lot more than the buffer (hence the prior statement: if your allocator catches this, it's of a design where use-after-free doesn't matter in this context, or your design is lacking).

Coverity reported 173 additional "use after free" bugs.

None of which caused heartbleed. Heartbleed gets a TLS heartbeat request that says "65000 HELLO", allocates 65,000 bytes, goes to the "H" in "HELLO" and copies 65,000 bytes into the new buffer. The problem is the correctly-allocated source buffer isn't that long, and it reads off the end. This isn't a "use after free" bug; a "use after free" bug is when you free(p) and then dereference (p) without first assigning it the value of a valid area of allocated memory. Reading off the end of a buffer--whether you read into freed, allocated, or whatever memory--is not use-after-free, but rather a wholly other class of bugs that could happen to read released memory as a side effect in some conditions, primarily because it executes a read overflow which has undefined behavior which could do ANYTHING.

In technical terms, the memory being read by heartbleed is never read after free(); rather it's invalid, because the memory address is reached without the use of any information that would indicate if there is anything at that address (mapped, unmapped, allocated, unallocated). From the point of the C standard and any sane way of evaluating this behavior, that memory doesn't exist, trying to read that memory is bad, you're bad for trying to read that memory, and whatever happens after this is nobody's fault but your own and could be nothing of import or the summoning of Cthulu.

Don't you suppose that in the process of fixing such bugs, it is likely that correctness issues like this one would have been caught?

I actually do suppose that it's more likely; however, to say that these technical factors are to blame for Heartbleed is wholly wrong. Heartbleed is its own bug, not a memory allocator bug or a double-free bug or a use-after-free bug. Heartbleed would have been found if more rigorous testing were employed IF AND ONLY IF said testing included the validation of this user-supplied input, in which case someone would have said, "We should test if we can send it a payload length that's bigger than the actual payload," and someone else would have said, "Uh... the... code just reads the payload length. We should test that in like, ten minutes, after I fix this." All non-human technical factors are a farce in this particular theater.

For what it's worth, multiple people actually did review this body of code, looked directly at these lines, evaluated them, and saw that it was good. THEY WERE WRONG.

Re:de Raadt

[pjt33]

Clearly the person who wrote the RFC understood that answering a heartbeat request with a size different than its payload was a potential problem since the behavior was specified.

The person who wrote the RFC also wrote the buggy code, so it may not be quite so clear.

Re:de Raadt

[bmajik]

Ok, I actually think you, me, and Theo all agree :)

1) We don't think a specific technical change would have _prevented_ the issue.

2) We all agree that better software engineering practices would have found this bug sooner. Maybe even prevented it from ever getting checked in (e.g. suppose the codebase was using malloc primitives that that static analysis tools could "see across", and that the code was analysis clean. Could this bug have existed?)

Re:de Raadt

[rev0lt]

OpenBSD is a hobby OS

*every* community-driven operating system is a hobby OS. Is that relevant?

It's like Linux with grsecurity

Maybe for you. Not for me. And it is actually easier to audit and it has a smaller kernel. And a kernel debugger. Something that is quite handy to find and troubleshoot problems.

(...) I would avoid the bet.

There are also more Windows machines than *nix machines with an internet connection. Some little-known RTOS are way more popular than Linux and BSD combined. Your point is?

OpenBSD's allocator is what we call "Proof of Concept".

Monolythic kernels are a proof of concept of monolythic designs. Every existing implementation of something is a proof of concept of the given concept. Again, what is the point?

It exists somewhere in real life, you can leverage it (I've leveraged proof-of-concept exploit code from Bugtraq in actual exploit kits), but it's not this ubiquitous thing that's out there enough to have an impact on the real world.

While OpenBSD itself is a niche product, its team is very well known for producing hugely popular products, including OpenSSH and PF. BSD server usage is low, but there are no real stats on middleware - routers, storage units, set-top boxes, closed devices, etc. FreeBSD is reportedly used in Playstation - that's more users than most Linux distros has. Is popularity usage relevant to the discussion? Not really.

Suntrust, Bank of America, slashdot, the NSA, Verisign, Microsoft, Google--is running a non-OpenBSD operating system with no such protections

I'd actually be very surprised if none of these companies use OpenBSD goodies - Either OpenBSD by itself, or middleware BSD products. And then you can add to this OpenSSH, OpenBGPD and a couple more interesting products. Microsoft used OpenBSD as a basis for the Microsoft Services for Unix. But again - is it relevant to the discussion? Not really.

And again, the concept of allocation caching is common. Freelists are used when allocations are all the same size; that gripe is essentially that a valid data object is not valid because they dislike it. Plenty of software uses freelists, and freelists are a generalization of the object pool software design pattern used for database connection caching in ORMs, token caching in security systems, and network buffers (ring buffer...). I would be surprised if OpenBSD's libc and kernel didn't make use of freelists or object pools somewhere.

So, you're saying that optimizing memory allocation in privileged space is the same as optimizing memory allocation on a userland library? That managing fixed-sized, out-of-the-userspace-address-pool structures is the same as trying to be smarter than the local malloc implementation? No system is perfect, but it generally sounds like a very bad idea.

In short: there's a lot of whanging on that OpenSSL made OpenBSD's security allocator feature go away, and that (implication) if OpenSSL had not done that, then an exploit attempt would have come across one of the 0.01% of interesting servers running OpenBSD, and a child Apache process would have crashed, and some alarms would have gone off, and someone would have looked into the logs despite the server humming along just fine as if nothing had happened, and they would have seen the crash, and investigated it with a debugger, and then reproduced the crash by somehow magically divining what just happened, and done so BEFORE THE WHOLE WORLD HAD DEPLOYED OPENSSL 1.0.1.

So, you're assuming there aren't compromised OpenBSD servers because of this. And that no one actually tried to exploit it in OpenBSD. The fact is that no one kows exactly the extent of the damage of this vulnerability, or if it could have been detected way earlier by using OpenBSD or Linux with grsecurity or whatnot. And

Re:de Raadt

[Anonymous Coward]

> Yes yes of course but you're missing the point.

No. You are missing the point of the whole debate from the get-go.

> Here's the thing: OpenBSD is a hobby OS.

Here's the thing: You're an idiot and a moron.

> And again, the concept of allocation caching is common.

Uhm, no. Implementing your own malloc() is everything *but* common. If you do that, please turn in your software engineering license at the door and never write code again. If you're running under a modern os, you don't need a custom memory allocator. libc will cache for you. libc will brk() for you. libc will mmap() for you. Again, you're an idiot if you think people regularly implement their own memory allocators.

> Also it's funny that you ignored the whole "this vulnerability would have happened basically everywhere anyway and the impact would have been the same even if all other code besides what's in this one function was perfect" thing. Mickens warned me [microsoft.com] about people like you:

Mickens is an even bigger moron and that was the most pointless rant I've ever read. He basically suggests we throw all security research and security thinking out the window, because apparently passwords are secure now and layer-based security is useless. Well, here's news for you: he's an idiot and people like him are a threat to secure coders everywhere.

> In reality, OpenBSD is running OpenSSL 0.9.8 without TLS heartbeats, and is exempt.[..] Most likely they won't notice. And really, mots of the interesting targets are EVERYONE ELSE IN THE WORLD, WHO DOESN'T HAVE THIS EXPLOIT MITIGATION TECHNOLOGY ANYWAY.

The thing is glibc also has similar expoitation countermeasures if they are compiled in. They can be done so. Running openssl through valgrind, assuming the idiots hadn't implemented their own custom malloc(), would have caught this immediately. There are so many ways this would have been caught (on linux, mind you) if they just coded in a sane way that I don't know where to begin.

Re:de Raadt

[Anonymous Coward]

> Read overflows don't kill canaries, so you wouldn't detect it except for with an unmapped page--a phenomena that doesn't happen with individual allocations smaller than 128KB

Depends if you allocate in the beginning or the end of the block. A it is more classical to go *after* a block than before, I suppose the block would be alloacted at the end of te 128K, and the read would fail...

Re:de Raadt

[epyT-R]

Smart people know that filters just shield people's feelings from hard reality, and that creates more problems down the road. It's better to let 'em have it all up front. The problem is today's society seems content to breed passive aggressive pantywaists who can't handle criticism without taking it personally.

Re:de Raadt

[Anonymous Coward]

Nobody uses sbrk anymore. And back when allocators did use sbrk, the BSDs already did small block caching, so the freelist crap was completely superfluous.

Re:de Raadt

[chriscappuccio]

Funny, several of the mitigation techniques in OpenBSD and grsecurity have made their way to other systems, even Microsoft WIndows... Basically everything you are saying here is a consistent misunderstanding of what's actually going on. Have you really looked?

Re:de Raadt

[bluefoxlucid]

Theo seems to me to be loudly proclaiming that the bug couldn't have existed with a certain feature, which I think is technically incorrect. I'm mostly in (1) camp, I just think Theo's statements are directly contradictory to this sentiment.

Better practices would not have prevented this bug; they would have reduced the probability of such a bug. Several people didn't realize there was no validation there, but specific test cases and fuzzing/analysis or even just the culture of better programming standards may have changed that. Or not. These things do, however, reduce defect rate--they don't give you zero defects--and so the likelihood of this bug, like any other, would be lower; we'd screen out X% of total defects, essentially, and hopefully this would be one of those.

Frama-C found Heartbleed, but Coverity didn't. Frama-C is GPL, and you can annotate your program to help with analysis. As far as I understand, Frama-C found that the data that was used for memcpy()'s size came from a mystical function that originates data from some untraceable source, was an unsigned int (0..65535 value), and was never validated against the size of the source array, which had the possibility to be smaller than 65535. Because the length of copied data could be up to 65535 bytes and the length of the source data could be smaller than 65535 bytes and the length of the copy was not computed based on the length of the source in such a way as to bound the length to the length of the source, it was conceivably possible to copy more data than was actually there. Hence Frama-C decided this code was, somehow, broken.

I used to be a huge fan of static checking. Looking at Frama-C's plug-ins, I'm wishing there were things like this for Python. It even has impact analysis (when you change something, what parts of the code may be affected? What are you really changing?).

Re:de Raadt

[bluefoxlucid]

I'd actually be very surprised if none of these companies use OpenBSD goodies - Either OpenBSD by itself, or middleware BSD products. And then you can add to this OpenSSH, OpenBGPD and a couple more interesting products. Microsoft used OpenBSD as a basis for the Microsoft Services for Unix. But again - is it relevant to the discussion? Not really.

Nope, it's not. what is relevant is that their front-facing OS is a non-openBSD OS running vulnerable libopenssl without the protections of the OpenBSD allocator because they're using glibc's pmalloc. That they have an OpenBSD appliance somewhere in the rack doesn't protect them. Remember: the point of my post was that all this warbling about OpenBSD's allocator doesn't have any real, practical bearing on the events that unfolded around the Heartbleed bug. If they had used the system allocator (everywhere), all other things equivalent, we'd still have heartbleed.

So, you're assuming there aren't compromised OpenBSD servers because of this. And that no one actually tried to exploit it in OpenBSD. The fact is that no one kows exactly the extent of the damage of this vulnerability, or if it could have been detected way earlier by using OpenBSD or Linux with grsecurity or whatnot.

I'm assuming that there are so few that the probability of OpenBSD servers being the first round of exploits--or really in any significant way exploited early enough that the bug is exposed and understood before the damage is probably done--is laughable at best. Remember: OpenBSD's technical security features WOULD NOT HAVE DETECTED HEARTBLEED until you actually exploited it. If OpenSSL was getting valid data, humming along fine, it would not have read past the end of the buffer. Only when given invalid data causing an out-of-bounds read did OpenSSL behave in ways indicative of program malfunction.

At that point the exploit is "in the wild", and people are probably exploiting banks and forums run on Linux and Solaris, and we must now assume... well, everything we assume in the current situation. So we're no better off.

grsecurity doesn't provide for a way to protect against this exploit, either. It's just another hardly-used security distribution with a strong niche following which I was using to compare volume--how much grsecurity versus how much OpenBSD, the answer being "not much of either", even though both have good technical security measures.

And it still remains a fact that it is a dumb idea to try to micro-manage memory on your library.

You mean like with object pooling, which is essentially what freelists are?

It's a common design pattern. Next you'll tell me Duff's Device is a dumb idea.

Actually, the whining I read was precisely that - why aren't OS developers doing the best they can to avoid and mitigate these kind of errors?

Everyone is blaming OpenSSL for having a freelist. Removing the freelist--or fixing the other broken memory allocations not relevant to Heartbleed--wouldn't help here. Implementing OpenBSD-style allocators may be useful--in fact, I had a memory allocator project 10 years ago that I abandoned which aimed for better memory density and high security by abandoning brk() and using mmap() and thread/class grouping (allocations from the same thread tend to allocate/free together; allocation fragmentation can be dealt with by grouping allocations of a given size together in a range of memory, rather than just buddy allocating in one big open field), and used all kinds of tests with canaries and dtags (deleted! double-free!) and other security bits.

I am not against a complete redesign of the allocator and I have no love for brk() segments. But this is not what people are crying about; they're crying about how Heartbleed mitigated OpenBSD's special allocator, which doesn't fucking matter for reasons already cited above.

That only demonstrates

Re:de Raadt

[bluefoxlucid]

The particular mitigation in question is to not use brk() for the heap. pmalloc and kmalloc use brk() for the heap, except for individual allocations of a size larger than 128KB which are mmap().

Re:de Raadt

[rev0lt]

That they have an OpenBSD appliance somewhere in the rack doesn't protect them.

Well, that depends. Following your assumptions on wide generalization of setups, it is common to have dedicated servers working as SSL proxies. Again, I'd be surprised if at least some of those companies weren't using OpenBSD for that. Or some vendor that leveraged BSD tech in their product.

I'm assuming that there are so few that the probability of OpenBSD servers being the first round of exploits--or really in any significant way exploited early enough that the bug is exposed and understood before the damage is probably done

You cannot assume that.You don't know how long this vulnerability has been exploited, and it is reasonable to expect that some high-profile targets that use OpenBSD in their stack may have been compromised. Its not only about how OpenBSD could have mitigated this - its about why a decade goes by and basic security measures are still the exception in other operating systems.

You mean like with object pooling, which is essentially what freelists are?

AFAIK the problem isn't "trying to optimize thousands of a-couple-of-bytes" allocation hashes. Even if it was, it is a good idea to cleanup free blocks with zeros. If you're allocating a 4k page, you probably should use other mechanisms. The problem is, on top of the fact that no boundary check was performed on a copy operation, this passed a code review and was incorporated in the most widely used SSL library, that reads and process sensitive information.

It's a common design pattern. Next you'll tell me Duff's Device is a dumb idea.

When applied to modern unix computing? It is. You can have a smart design around it, but as it is - its dumb as fuck. Eg. acessing odd memory positions is a stall in most modern CISC cpu's (and some ancient ones too), so your code will actually run slower. In some cpu's, the stall is everything that is not 16-byte aligned. In the end, if you're using C and trying to be clever in the architecture, either you're doing critical kernel stuff or you should be using assembly anyway. Odds are, your very clever algorithm implementation will be a pile of poo on a newer generation of cpus and no compiler will save you from that (have a look at the Bresenham's integer line drawing algorithm for an example).

I had a memory allocator project 10 years ago that I abandoned which aimed for better memory density and high security by abandoning brk() and using mmap() and thread/class grouping (allocations from the same thread tend to allocate/free together; allocation fragmentation can be dealt with by grouping allocations of a given size together in a range of memory, rather than just buddy allocating in one big open field), and used all kinds of tests with canaries and dtags (deleted! double-free!) and other security bits.

That actually sounds interesting. What happened to it?

I got in an argument with Theo some 8 or 10 years ago about static checkers. He told me, rather loudly, that static checkers make programmers lazy because they start just writing to satisfy the checker and then get sloppy with actual code review

I'm a big fan of static analysis, but I do understand his point. Having these features available on development time do take a toll on the quality of the code. Having them available on a CI server or whatever is a very good idea. If an error is triggered, proper atention will be given to it, instead of having someone just changing the code so it stops complaining about the error.

His strong position was that static checkers INCREASE defects in code; but I see that somewhere in the past 5 years he's reversed that position sharply.

He probably tried using one :D

Re:de Raadt

[hobarrera]

If they hadn't used their own allocator, then this bug would have been exposed on OpenBSD ages ago since it would lead to OpenSSL crashing over and over again. At first you migth think that this only helps OpenBSD users, but no: this would have led to research on the matter (the crashed), and the issue being found quite soon after it was introduced.

So it would not have been benefitial only to OpenBSD, but to everyone.

Re:de Raadt

[bluefoxlucid]

You cannot assume that.You don't know how long this vulnerability has been exploited, and it is reasonable to expect that some high-profile targets that use OpenBSD in their stack may have been compromised.

Netcraft reports BSDs as 1% or less of the servers out there, OpenBSD being a fraction of that, FreeBSD being another, NetBSD and other such probably being a smaller fraction than either. I would expect OpenBSD to be the bigger fraction--who uses BSD on a server?--but FreeBSD appears to be more popular as a desktop OS, and that may carry weight. Of course we're talking about the tastes of the 1% so who really knows?

Thing is we know a lot of high-profile targets are straight Linux or they have dedicated appliances that were vulnerable (FortiNet products, SonicWall products, Cisco and Juniper gear even). When making conjectures, I take the larger probabilities--look up Operational Risk Management and related analytical techniques--and draw likely conclusions. "OpenBSD isn't vulnerable" would not have convinced me (or likely anyone) that the situation is any different from a practical standpoint, except that a few machines somewhere would theoretically escape vulnerability, and even then you may be able to modify the attack (i.e. take less than 4k?).

The problem is, on top of the fact that no boundary check was performed on a copy operation, this passed a code review and was incorporated in the most widely used SSL library, that reads and process sensitive information.

Yes I've said this a few times about "better coding practices". Cleaner code would have helped, heartbleed was very self-contained, the process of review and clean code *may* have increased the likelihood of Heartbleed not making it past a review, but it did make it past several manual reviews as-is, etc etc. Part of my larger argument has been that Heartbleed isn't exposed by technical runtime countermeasures until exploited, and apparently nobody thought to look for this particular kind of bug, so it was never tested.

That actually sounds interesting. What happened to it?

Well besides that I am not the world's best programmer--I do have a certain strength in the area, but it's vastly outweighed by my weakness in larger architecture and I always had this perfectionist thing going on with no real code discipline so I was always frustrated with my own bad code--I could never get the allocator tested. You do understand why it might be hard to test a memory allocator as it's incrementally written, right?

The basic plan was to implement parts of malloc(), and fall back to glibc's malloc() for cases I don't handle. I used a staged design, with arbitrary object sizes based on some research papers I read--16 byte objects are common, so I have a "picoheap" or whatever I called it that's just a collection of mmap() areas for holding 16 byte objects. For larger (128 byte-256 byte?) objects I had separate mmap() areas which used canaries to detect write overflow (too much overhead to do that with 16 byte allocations, just made them 4k pages with a bitmap). And so on. I tried to implement one class of allocation, and fallback to malloc() otherwise... and the interposing wasn't something I knew how to do.

I'm sure Peter Gutmann would have something to say about me replacing malloc() with something much better I invented one morning over coffee (and the Web site part is now defunct... I still have the design docs somewhere, probably the schizophrenic rantings of a child).

Eg. acessing odd memory positions is a stall in most modern CISC cpu's (and some ancient ones too), so your code will actually run slower. In some cpu's, the stall is everything that is not 16-byte aligned.

Re:de Raadt

[bluefoxlucid]

How would it lead to OpenSSL crashing over and over again?

Re:de Raadt

[hobarrera]

Because of how OpenBSD's allocator works, the "reading past the allocated space" code would trigger page faults on OpenBSD (not always, but some times). These are fatal, and make the program crash.

One of the messages on the thread linked in TFS mentions how this works in greater detail.

Re:de Raadt

[rev0lt]

I would expect OpenBSD to be the bigger fraction--who uses BSD on a server?

FreeBSD is the bigger fraction. And I use BSD on servers instead of Linux. So do companies like Yahoo and Whatsapp.

Thing is we know a lot of high-profile targets are straight Linux or they have dedicated appliances that were vulnerable (FortiNet products, SonicWall products, Cisco and Juniper gear even)

Well, some versions of JunOS are based on FreeBSD. And BSD-based appliances are quite popular (pfsense, monowall, etc).

(...) I read--16 byte objects are common, so I have a "picoheap" or whatever I called it that's just a collection of mmap() areas for holding 16 byte objects

That vaguely reminds me of the slab allocation available on both FreeBSD and Linux kernels (and Solaris) (http://en.wikipedia.org/wiki/Slab_allocation).

Yes I know. I ingested enough about computer architecture in 1 month when I was 19 to have the Tetris Effect on a hilarious level.

So, do you also agree its dumb? :D

But hey, did you know that on IA-32 you can mark a page with the Supervisor bit, and when you try to access it you cause a page fault exception into the kernel, which can then check if you want to READ/WRITE or EXECUTE the page, and kill the program if EXECUTE, else force a DTLB load (in the CPU) which gets cached and no longer raises an exception until the DTLB fills up and invalidates that entry?

Off the top of my head, no :) You're probably refering to the fact that accessing a linear address that don't map to actual 'real' memory results in a page fault, and then you can decide what to do. That's how virtual memory works, and it is a bit of an overkill to be abusing it. On the other hand, COW uses a somewhat similar mechanism and no one is complaining :)

so the whole stack was automatically NX without all that extra overhead, and the heap was page-granularity protected.

Well, most modern x86 operating systems don't fully use the x86 protection mechanism.If they did, every program would have their separate LDT entry, and each program would have its own set of descriptors to make sure you're not messing around where you shouldn't. This, of course, has its own limitations (LDT entries, for once, since the GDT is limited to 64K), but it also has its own advantages (call gates are awesome, specially when every program has its own stack segment descriptor mapped into linear address space). The common approach is to use a limited set of descriptors in different execution rings, so that shared libraries and other stuff works without too much hiccups. If you saw how Linux handled syscalls in version 2.0/2.2 on x86, you'd laugh. Now modern cpu's have their own instruction to do this, instead of using call gates :)

And kept adding to it for about 3 months before cooling down. I know about word alignment.

Well, I've spent several years working in assembly with x86 ia-32 protected mode. Just not in unix environments :)

Re:de Raadt

[bluefoxlucid]

Sometimes. Most likely, 64KB reads would do this a lot.

This was meant to be a leading question, however. I'll point out again: OpenSSL when not being fed incorrect data (i.e. a long payload supplied during exploit) does not read past the end of allocated space. This situation is non-anomalous, which means OpenSSL would not crash.

In other words: OpenSSL would only repeatedly crash when actively under heavy attack.

Re:de Raadt

[bluefoxlucid]

Some of that was just spurting. Also the PaX stuff isn't unmapped pages; they're mapped, just they're ring-0 only, and so when the userspace ring-3 execution flow tries to execute it you get a protection fault. Then the OS forces a ring-3 DTLB load if it's not an execution attempt, and the program continues--the protection isn't checked if there's a DTLB entry, so this actually works.

FreeBSD is also vulnerable, OpenBSD isn't. That's the thing: It's Linux and vulnerable dedicated appliances everywhere. And apparently FreeBSD; I would think anyone who goes as far as to use BSD in production would be leaning on OpenBSD.

Re:de Raadt

[rev0lt]

Some of that was just spurting. Also the PaX stuff isn't unmapped pages; they're mapped, just they're ring-0 only, and so when the userspace ring-3 execution flow tries to execute it you get a protection fault.

This happens because all descriptors map the same area. They shoudn't. PaX may be a clever trick, but it is to fix a software design flaw. Modern (elf/coff-based et al) binaries have a fixup table *precisely* to be loaded at a random address. Code segments and data segments are separated for the same reason. The same goes for the BSS info. It makes no sense *not to use this*, specially since most platforms are elf-based.

Then the OS forces a ring-3 DTLB load if it's not an execution attempt, and the program continues--the protection isn't checked if there's a DTLB entry, so this actually works.

By design, in x86 systems, every application should have its own set of descriptors (by using an LDT). In most modern systems, it doesn't. Even if using just a set of 3 descriptors for all tasks (per cpu/execution unit, of course), save/reloading of descriptor info could be done upon task switch (just like task state info is stored and a new TSS is loaded). This would allow every application to have a read/write stack that is not reachable by the code segment, and a data segment that does not map the same area as both the stack and the code segment. Linear address could also solve (at least partially) the shared library problem.

I would think anyone who goes as far as to use BSD in production would be leaning on OpenBSD.

Security is just one parameter of the equation. OpenBSD does security quite well, but the rest leaves a lot to be desired. I was a huge OpenBSD fan/user (and still buy the CDs whenever I can), but the 2-release support cycle isn't enough for my needs. And the lack of *any* kind of container or virtualization technology (like jails), lack of a modern filesystem, and somewhat dysmal smp support make OpenBSD unsuitable for most of my needs. Regardless, I do know of companies using OpenBSD in production without any hiccups, and I'd consider it for some workloads.

Re:de Raadt

[bluefoxlucid]

This happens because all descriptors map the same area. They shoudn't. PaX may be a clever trick, but it is to fix a software design flaw. Modern (elf/coff-based et al) binaries have a fixup table *precisely* to be loaded at a random address. Code segments and data segments are separated for the same reason. The same goes for the BSS info. It makes no sense *not to use this*, specially since most platforms are elf-based.

Actually, PaX does use that information. The problem was, originally, that the CPU itself did not have an NX bit. If you set PROT_READ, the CPU and MMU interpreted "READ" to mean "EXECUTABLE", because you could *read* program code and why would you want to do that except to execute it?

Check out the 80686, 200MHz, manufactured in 1999 as the Pentium Pro.

By design, in x86 systems, every application should have its own set of descriptors (by using an LDT).

Yes, and in 2001 no x86 CPUs were physically capable in hardware of marking executability in the LDT.

Re:de Raadt

[rev0lt]

The problem was, originally, that the CPU itself did not have an NX bit

It doesn't need one, if a system actually implements protection according to the spec. Check http://www.intel.com/Assets/en... , section 3.4.5.1. (Page 3-16, vol. 3A). If you're still in doubt, check the original 80386 manual, http://css.csail.mit.edu/6.858... (page 109).

because you could *read* program code and why would you want to do that except to execute it

Well, read and execute are two separate permissions even on unix systems :) (eg. you cannot read a file, but you can order the system to execute it). There is a whole range of applications for read-only buffers, not only for execution, specially if eg. my application deals with DMA transfers. On modern PCI Express systems, this makes even more sense.

Yes, and in 2001 no x86 CPUs were physically capable in hardware of marking executability in the LDT.

I actually find that quite hard to believe. The LDT was introduced with the 80286, in 1981. If you check both manuals I mentioned, you'll find indication that you cannot store a TSS in the LDT and some other special descriptor types. Not code/data ones. That would actually *void* the initial purpose of the LDT, which was providing a poor man's protection mechanism without a paging system. My memory isn't what it used to be, and sometimes I do get some things wrong. It happens. But I've spent over 10 years programming mainly in x86 assembly (covering the end of the 90's), and - while I may not recall all the specifics, I still remember some stuff . The drawbacks of using LDTs have more to do with memory consumption and system complexity than anything else. If you have information that support your claim, please share :)

Re:de Raadt

[bluefoxlucid]

I actually find that quite hard to believe. The LDT was introduced with the 80286, in 1981. If you check both manuals I mentioned, you'll find indication that you cannot store a TSS in the LDT and some other special descriptor types.

As per Wikipedia:

There was no 'Executable' flag in the page table entry (page descriptor) in the 80386 and later x86 processors, until, to make this capability available to operating systems using the flat memory model, AMD added a "no-execute" or NX bit to the page table entry in its AMD64 architecture, providing a mechanism that can control execution per page rather than per whole segment.

What happens is your program starts its VMA with 16MB of non-mapped memory. Then you have the executable .text segment. Directly above that is the non-executable brk() segment (heap). Directly above that are anonymous mappings, including executable shared library .text segments. Finally, you have the stack.

So memory looks approximately like: nnnnXXXXWWWWXXWXWXnnnnnnnWWWWW for non-mapped, eXecutable, and Writable memory. All mapped is readable to simplify this model.

On x86, PROT_READ is also PROT_EXEC; there aren't 2 bits. While you can use a segmentation setup, it must be contiguous: setting the highest executable page to the top of the main executable makes the heap non-executable, but also makes all library code non-executable. Setting the highest executable page to just below the stack makes the stack non-executable, but leaves the heap and anonymous data mappings executable. There is no bit to say, "This part is executable, and this part isn't, and this next part is, but this next part isn't, this part is, and this last part isn't."

Hence the tricks with setting up ring-0 memory protection on data pages and then forcing a DTLB load if they're read/written, to act as a kernel-controlled NX bit.

Re:de Raadt

[rev0lt]

There was no 'Executable' flag in the page table entry (page descriptor) in the 80386 and later x86 processors, until, to make this capability available to operating systems using the flat memory model, AMD added a "no-execute" or NX bit to the page table entry in its AMD64 architecture, providing a mechanism that can control execution per page rather than per whole segment.

I'm not talking about page table entries. I'm taking about segment descriptors. Those are two completely distinct features/funcionalities. Please check the *actual* reference manual link in my previous comment.

What happens is your program starts its VMA with 16MB of non-mapped memory. Then you have the executable .text segment. Directly above that is the non-executable brk() segment (heap). Directly above that are anonymous mappings, including executable shared library .text segments. Finally, you have the stack.

You still don't see the problem. Locking PER-SEGMENT has existed since the 80286. Not per-page but PER-SEGMENT. Because most operating systems use a half-assed, simplified, portable implementation of the x86 protection mechanism this is not used - at all. So you have the stupid contiguous loading that you just described, with all the shitstorm that comes with it.

So memory looks approximately like: nnnnXXXXWWWWXXWXWXnnnnnnnWWWWW for non-mapped, eXecutable, and Writable memory. All mapped is readable to simplify this model.

Mapped and unmapped memory is not relevant for the protection mechanism, UNLESS you want per-page protection (which is kinda stupid anyway, code should reside in its own descriptor).

On x86, PROT_READ is also PROT_EXEC; there aren't 2 bits. While you can use a segmentation setup, it must be contiguous: setting the highest executable page to the top of the main executable makes the heap non-executable, but also makes all library code non-executable.

Again, I'm not talking about pages. Segment descriptors are on top of the paging mechanism (ie. all addresses are linear addresses if using pages, its not even mandatory), and you CAN have execute-only segments on top of this. You can have multiple segment descriptors mapping the same linear addresses with different permissions, if you want. Even with different DPLs. Read the actual manual, and you'll quickly understand this.

There is no bit to say, "This part is executable, and this part isn't, and this next part is, but this next part isn't, this part is, and this last part isn't."

There is a way of saying "this segment is executable, this one isn't", for an arbitrary number of segments. The GDT can have upto 8191 descriptors, and *each* LDT has this kind of limit. On modern systems, you still have the dumb-as-f**k 4 main descriptor approach + upto 4 for "userspace". This happens because the protection mechanism of almost all the SOs specifically DON'T make use of all the x86 protection features.

Hence the tricks with setting up ring-0 memory protection on data pages and then forcing a DTLB load if they're read/written, to act as a kernel-controlled NX bit.

If you're interested, take a couple of minutes to understand how the protection mechanism works on the 80386. All of it. You'll quickly realize how shitty most implementations are.
On a similar note, check "call gates" and then ask yourself why most modern CPUs have an instruction that implements what is a call gate. If you want an answer, have a look at the shitty shitty linux 2.0/2.2 code that deals with syscalls.

Re:de Raadt

[bluefoxlucid]

Ah, ok. SO like Segmexec in PaX where the address space is dual-mapped and split 50/50, or W^X where part of the memory is NX.

Mapped and unmapped memory is not relevant for the protection mechanism, UNLESS you want per-page protection (which is kinda stupid anyway, code should reside in its own descriptor).

Code resides in segments in a binary. A library has data and code segments, mapped separately. They're mapped per-page for memory management: if you experience memory pressure, small pages (4K) can be swapped out. Code pages get invalidated and re-read from the original source on disk if needed.

LDT in 32-bit flat protected mode is an interface I never saw. Odd. I only knew about the single segment (code, data) layout using CS and DS and SS.

Re:de Raadt

[rev0lt]

Ah, ok. SO like Segmexec in PaX where the address space is dual-mapped and split 50/50, or W^X where part of the memory is NX.

Yeah, sort of exactly like that. But it has existed since "forever" in x86-32 and you can specify arbitrary segments per-task.

Code resides in segments in a binary. A library has data and code segments, mapped separately. They're mapped per-page for memory management: if you experience memory pressure, small pages (4K) can be swapped out. Code pages get invalidated and re-read from the original source on disk if needed.

Yeah, but because the address translation system used by segments sits on top of the actual paging mechanism, this is transparent :) Its all linear addresses.

LDT in 32-bit flat protected mode is an interface I never saw. Odd. I only knew about the single segment (code, data) layout using CS and DS and SS.

You're probably a typical unix guy :) And AFAIK, most academic literature does not cover this. Its odd how my path differs from the traditional "academic"way - I learned from system architecture and multitasking from the cpu manuals, so you can imagine my surprise when I started looking into existing operating systems :D

I just donated

[Anonymous Coward]

I think my CC number got stolen.

Re:I just donated

[Anonymous Coward]

I think my CC number got stolen.

Wow, I hope you didn't lose your monies! Speaking of money, and supporting OpenBSD, money doesn't grow on trees. And, Linux Advocates is growing. Naturally, we anticipate operating costs and hope to be able to meet them.

But, any amount you feel you are able to donate in support of our ongoing work will be most surely appreciated and put to very good use. Your contributions keep Linux Advocates growing.

Show your support by making a donation today: Paypal or donate Bitcoins.

Thank you.

Dieter T. Schmitz
Linux Advocates, Owner

http://www.linuxadvocates.com/p/support.html

Re:I just donated

[Anonymous Coward]

I know. Pay your bill, your card is being refused by everybody.

Okay, Go!

[xdor]

Obviously since OpenBSD is running their fork of OpenSSL 0.9.8 which essentially doesn't have this exploit, this is just a shameless plug.

But having an OpenBSD vetted OpenSSL 1.0.1g+ for Ubuntu, now that would be something!

Re:Okay, Go!

[Rigel47]

It's not a shameless plug. Theo has been openly critical of the OpenSSL team's development practices. By forking in-house he's essentially saying that they will put their proverbial money where their mouth is by doing their own development.

Re:Okay, Go!

[buchner.johannes]

Obviously since OpenBSD is running their fork of OpenSSL 0.9.8 which essentially doesn't have this exploit, this is just a shameless plug.

OpenBSD 5.3 - 5.5 was affected: see their Security Advisories

Re:Okay, Go!

[LWATCDR]

Pretty much. They are also removing the heartbeat feature as well support for some other operating systems in their fork.
In other words it is a PR grab.

Re:Okay, Go!

[Lunix Nutcase]

OpenBSD 5.3 was running 1.0.1c which was affected by the bug. This is not PR. It is fixing bugs in a critical component of their OS.

Re:Okay, Go!

[chill]

Not necessarily. It looks like they're removing what they can't support, such as VMS, Netware and OS/2. The few people that care can still use the original OpenSSL code.

I'd expect them to ensure it support the hardware platforms OpenBSD supports at the very least. Then, if they go the "portable" route like they did for OpenSSH, support for the other Unix and Unix-like systems.

http://www.openssh.com/portable.html

More power to them.

Re:Okay, Go!

[Lunix Nutcase]

Correction of myself: That should be 5.3 and 5.4 which both had 1.0.1c.

Re:Okay, Go!

[xdor]

Yeah, I just read their security advisory. I was basing my information on the original Heartbleed slashdot article which listed OpenBSD as unaffected.

(Note to self: Verify all thy claims before making a near-first comment on slashdot...)

Re:Okay, Go!

[Anonymous Coward]

IIRC the phrase was "OpenSSH is not affected". For one reason or the other, people keep confusing OpenSSH and OpenSSL.

Re:Okay, Go!

[chriscappuccio]

OpenBSD was using a variant of 1.0.1c with the bug.

Re:Okay, Go!

[chriscappuccio]

A PR grab...that you can run on any modern unix based OS. Just not VMS or OS/2.

Re:Okay, Go!

[LWATCDR]

My mistake then.

Anyone know if there are regression tests?

[QilessQi]

If they're doing a large-scale refactoring, a regression test suite is really advisable (in addition to static code analysis) to ensure that they don't create new, subtle bugs while removing things that might look like crud. Does anyone know how good their test coverage is?

Re:Anyone know if there are regression tests?

[Anonymous Coward]

If they're doing a large-scale refactoring, a regression test suite is really advisable (in addition to static code analysis) to ensure that they don't create new, subtle bugs while removing things that might look like crud.

Yes, that would be nice. But even without that it is a situation where you trade known critical bugs for theoretical new bugs.
If testing and analysis delays the refactoring then perhaps that is something that should be done in the step after the first.

Re:Anyone know if there are regression tests?

[Walter White]

... Does anyone know how good their test coverage is?

Not obvious to me if by "their" you mean OpenSSL or OpenBSD (*) but it seems to me the answer is "not sufficient." I'm sure it will be enhanced to cover Heartbleed.

(*) OpenSSL, OpenBSD ... phrased that way it sounds like a match made in heaven! ;)

Re:Anyone know if there are regression tests?

[Em Adespoton]

Added to this, most of what they're doing is removing code and exposing the underlying code to the safeguards they already have in place at the OS level. Refactoring suddenly becomes a LOT easier, as there's less to test. They're pruning their tree, essentially.

The beauty is that the way the handlers are designed at the OS level (and have already been tested against all other packages) means that if there IS a failure, it'll immediately cause a hard fail in OpenSSL -- which might seem bad, but it means that it'll be immediately reported and fixed, and the actual problem will be easy to find. It also means that there's less likelihood of an attacker being able to leverage the bug other than to perform denial of service attacks.

Re:Anyone know if there are regression tests?

[QilessQi]

Whatever they're using as the baseline of their fork. There are already patches that fix Heartbleed (the simplest being "don't support heartbeats", which are not mandatory in the spec anyway). If they're taking this as an opportunity to do radical cleanup, that's great -- but I'm sure we'd all feel better if regression tests were in place to reduce the risk of introducing another subtle bug. Major surgery on critical security infrastructure should not be rushed.

Re:Anyone know if there are regression tests?

[Zero__Kelvin]

"Does anyone know how good their test coverage is?"

They think it's pretty good, but they haven't had time to test it yet.

Re:And they've already stopped

[bill_mcgonigle]

$30,949 is how much the OpenBSD Foundation received in donations in 2013. That has to get fixed as their expenses were $54,914 and only a one-time transfer from an old account covered the deficit.

The community that depends on OpenSSH, OpenNTPD and the like needs to figure out how to support these projects.

Personally I'd like to see the Foundation offer targeted donations to specific projects with a percentage (~20% perhaps) going into the general operations fund. I bet there are a bunch of people who would throw a hundred bucks at OpenSSH but would be concerned that a general donation would go to some odd thing Theo is doing (whether that be fair or not).

And if "Fixing OpenSSL" were one of the donation options, then hold on to your hats - I think we're all in agreement on this. We do know that the folks currently working on the projects are paid by others but if the Foundation can get enough money to offset expenses then it could actually do some development work and possibly finally take care of some sorely-neglected tasks on a few of these codebases.

What about a re-implementation...

[FunkyELF]

... in a safe(er) language.
I wish the Go language supported building of shared libraries. Would be a nice implementation language for software like this.

Re:What about a re-implementation...

[xfizik]

C is a perfectly safe language if used properly. Not to mention that it is as ubiquitous as it can possibly get without sacrificing portability.

Re:What about a re-implementation...

[Desler]

What about it? If you want a Go implementation, then go do it.

They are not using Go because they want portable code that can run on all the hardware platforms they support. Go does not support all of those platforms.

Re:What about a re-implementation...

[Anonymous Coward]

... And ran faster ...

You can safely write something like OpenSSL in C/C++, hence the fact that OpenBSD exists with the namesake that it has earned (secure).

Re:What about a re-implementation...

[Anonymous Coward]

And what do you think Go is written in? Magic pixie dust?

Re:What about a re-implementation...

[Anonymous Coward]

Go ahead, do it. The OpenBSD people are actually doing something, instead of only being busy talking about it.

Re:What about a re-implementation...

[cpghost]

Every so called "safer" language (than C) is also less efficient. For OpenSSL, we need maximum efficiency/speed in big data scenarios, and in cases where hardware acceleration is asked for. Playing with Go, Java & Co. is a no-go here. Plus, C can be just as safe, when used properly and when code is properly audited and screened. The problem with Heartbleed was that auditing took way too long to materialize and to catch up. A bug in a, say, Go version of OpenSSL would have probably taken just as long to get discovered, if auditing happens so seldom.

Re:What about a re-implementation...

[Anonymous Coward]

How about Ada?

Re:What about a re-implementation...

[Lunix Nutcase]

And all these vaunted "safer languages" are written in... C.

Re:What about a re-implementation...

[Anonymous Coward]

All languages are safe if used "properly".
The trick is being resilient against the occasional mistake, and C does that really poorly.

Re:What about a re-implementation...

[Lunix Nutcase]

So if C is so bad why should we trust the languages that are implemented in it? You do realize that most of these "safe" languages are written in C, right?

Re:What about a re-implementation...

[AnotherBlackHat]

While it might be nice to use a safe(r) language, can't we at least have a compile option in C that adds bounds checking?

And while you're at it, how about making it impossible to execute code that isn't in the code segment and write protecting the code segment.

Re:What about a re-implementation...

[Nutria]

C is a perfectly safe language if used properly.

As safe as juggling very long, very, very greasy sharp knives while skating on very thin ice...

Re:What about a re-implementation...

[Lunix Nutcase]

And yet you'll trust languages implemented in it?

Re:What about a re-implementation...

[gweihir]

That is complete BS. code is insecure because the coders suck. Language makes no difference. In a "safe" language, the bigs are just harder to find.

Re:What about a re-implementation...

[gweihir]

Only for those of small skill. Those people should stay away from any security-critical code anyways.

Re:What about a re-implementation...

[dirtyhippie]

I'll give you ubiquitous and portable, but C is not remotely a "perfectly safe" language. That's a ridiculous claim.

Re:What about a re-implementation...

[EvanED]

First: Many languages are largely or even entirely self-hosted in terms of compiler and/or runtime. This means that if they provide, say, better type safety than C, those benefits carry over to the portions of the language that are self-hosted.

Second: the directness of the problem. It's easy for a C program to allow a very direct exploit, e.g. Heartbeat. I'm not saying easy to find, or that you'll necessarily get what you want to see every time, but the bug itself is about as simple as you can possibly get. If your language runtime has a bug instead, it's much more likely to be a very indirect one, because now not only do you likely have to cause a specific behavior in the program itself, but that behavior has to trip up the runtime in a way that causes that bug to lead to something bad. This isn't really fair to say this, but consider the Heartbeat vulnerability: to have the same thing happen in a safe language, not only would the program have to have the potential for a bug (unchecked input) but you'd also have to trick the runtime into dropping its bounds check.

Sure, it's not guaranteed to cure all ills, and runtimes can have bugs. But at the same time... it dramatically raises the bar.

Re:What about a re-implementation...

[Anonymous Coward]

Did you miss the memo?
Even the old crufty gcc switched to C++, because C just doesn't cut it anymore.

Re:What about a re-implementation...

[QilessQi]

I understand that Karpeles (of Mt.Gox fame) wrote his own SSHD using PHP. Let's use that! :-)

http://falkvinge.net/2014/03/1...

Re:What about a re-implementation...

[Lunix Nutcase]

If your language runtime has a bug instead, it's much more likely to be a very indirect one, because now not only do you likely have to cause a specific behavior in the program itself, but that behavior has to trip up the runtime in a way that causes that bug to lead to something bad.

Yeah and? Has that stopped all the exploits of the Flash runtime and the Sun/Oracle JVM? Nope. In fact, those two are among the most exploited pieces of userspace software on the OS.

Re:What about a re-implementation...

[EvanED]

While it might be nice to use a safe(r) language, can't we at least have a compile option in C that adds bounds checking?

That's extremely difficult to do for C. People trying to do that has resulted in multiple PhD theses and no one still has a perfect solution. If you actually want that, then use CCured, which is probably as close as it gets.

And while you're at it, how about making it impossible to execute code that isn't in the code segment and write protecting the code segment.

I'm pretty sure that's how things are now, though I could be wrong. Non-writable code has been around for ages, and non-executable data was the whole NX/DEP from a decade ago. I think that's pretty ubiquitous now. (I guess I've almost always heard of NX protecting the stack, but I assume you'd mark heap & static pages NX too.)

Re:What about a re-implementation...

[Lunix Nutcase]

And thay changes things, how? C++ allows all the same "unsafe" things as C does. Have you ever used C++ before?

Re:What about a re-implementation...

[EvanED]

Language makes no difference In a "safe" language, the bigs are just harder to find.

I think this is a dumb argument. Let's divide up problems into "memory errors" and "logic errors", where we broadly interpret "memory errors" as "errors your language or runtime won't let you make."

This means that if you program in C, you have to deal with memory errors and whatever logic errors you make in C. If you program in another, safe, language, you no longer have to worry about memory errors and only have to worry about logic errors in that language.

That means that unless you can argue that you'll make more logic errors in your safe language, you've already won.

Furthermore, because in C you have to spend time and effort making sure you're not susceptable to memory errors, that takes time and effort away from looking for other errors. Not only that, but automated tools have a harder time dealing with C than they do with many safe languages, which means you have less tool support.

And that's not even getting into more esoteric languages where you can encode non-trivial proofs into the type system and have the compiler prove correctness with respect to certain properties.

Re:What about a re-implementation...

[Anonymous Coward]

Bullshit. clang is written in C++ which has a _much_ safer type system.

Re:What about a re-implementation...

[EvanED]

In fact, those two are among the most exploited pieces of userspace software on the OS.

Coincidentally, they're also the two applications that are internet-facing the most. Oh wait, that's not a coincidence at all. If you put C into that role, and let your browser download and run C programs, the result would make Java and Flash look like Fort Knox.

(NaCl isn't C, I will point out, and is closer to a better Java implementation than it is to compiling and running C.)

Re:What about a re-implementation...

[Anonymous Coward]

That changes everything. All the crazy memory and resource management code that is inherent to C programs can be replaced by a clean lifetime management. RAII is the magic word. And yes I have programmed in both and have come to the conclusion: Correctly written C++ is way way less error prone. The OpenSSL error would have never happened in an idiosyncratic C++ program (as opposed to a program written by people with C habits). Unfortunately learning C++ is very hard for C programmers - it takes years to pick up the correct habits.

Re:What about a re-implementation...

[bluefoxlucid]

Actually, a certain amount of effort is required to understand code. Depending on how the language provides its interfaces, the abstract and logical ways in which people think and which programmatic processes normally flow based on how people envision them are either simple to interpret (for humans) or immensely complex to interpret.

Because of this, one language may have an advantage over another in terms of both speed of program implementation and frequency of defects. Fewer objects for programmers to track, and more objects are more naturally understood, thus less mental effort required to ensure correct code, and fewer cases where multiple visual validations by different people will produce the same corner case where incorrect code is incorrectly interpreted as correct.

Re:What about a re-implementation...

[QilessQi]

As I understand it, one reason that security-related code is best done in low level languages is that the implementer has absolute control over sensitive data.

For example, consider an server which acquires a passphrase from the client for authentication purposes. If your implementation language is C, you can receive that passphrase into a char array on the stack, use it, and zero it out immediately. Poof, gone in microseconds.

But let's say you used some language which dynamically allocates memory for all strings and garbage-collects them when they go out of scope. It's "safer" in one respect, because it prevents the developer from having to do their own memory management. But auto-growing strings (and lists) often work via some invisible sleight-of-hand whereby the string's data is copied to new memory once it grows enough to fill its original underlying buffer. This can happen several times as you concatenate more characters onto the end of that string. So as you read it a long passphrase into a dynamically-growing string, little now-unused copies of the prefixes are being put back on the heap all the time, completely outside your control. If that daemon dumps core and you inspect the dumpfile, you might see something like "correct-horse-battery-sta". Marry that to the log of IP connections, and boom, you can make an educated guess at what Randall Munroe's passphrase is.

Re:What about a re-implementation...

[EvanED]

(NaCl isn't C, I will point out, and is closer to a better Java implementation than it is to compiling and running C.)

I will weaken this statement a little bit. I assert it's closer to a better Java implementation than it is to a standard industrial C implementation. You could make a C implementation more like NaCl's, but depending on how you look at it (1) it would still make Java and Flash look like Fort Knox because it doesn't even try to protect against Heartbleed-like vulnerabilities, or (2) it would satisfy the constraints of "a safe language", but no one really uses them and I don't know of any industrial compilers that implement NaCl-style protections for standalone programs.

Re:What about a re-implementation...

[Anonymous Coward]

Show me an OS with more than 1% market that has a kernel and network stack that is not written in C/C++.

Re:What about a re-implementation...

[ADRA]

I can't say for Flash, but most of the headline Java bugs related to the web start API's / DLL's which are actually outside of the core JVM sandbox (though there were a few in-sandbox flaws which were patched as well). You could say the same thing if there were gaping holes in Jlaunch, or Oracle's JVM API, etc.. The only difference is that web start for better or worse is included in the standard JRE release.

You don't hear about the countless exploits possible in java based server code, considering that basically everything entering a socket on the server is already in JVM, hence not likely to be exploited unless the site developer made some serious flaws themselves.

Re:What about a re-implementation...

[Anonymous Coward]

The Flash runtime lacks bounds checking for its SWF file parser/interpreter, and they can't really fix it all because of back-compat issues, this is probably what 99% of the on-going flash exploits are.

The JVM exploits in the browser are due to the sandboxing implementation, which is supposed to suppress java code that requests certain operations on the OS, not due to runtime exploits (GC, code generator, etc). I've yet to see one JVM-related exploit on a JVM running on the server.

Re:What about a re-implementation...

[Zero__Kelvin]

"Furthermore, because in C you have to spend time and effort making sure you're not susceptable to memory errors, that takes time and effort away from looking for other errors."

Your analysis gets it wrong. With so called "safe" languages people are less vigilinte because they can get away with being lazy and not really understanding what is going on. With C you have to be hypervigilinte and know your stuff, which are two very good qualities for a programmer to have.

Re:What about a re-implementation...

[Nutria]

Given the number of bugs (security and otherwise) in so many applications, there must be 10 metric trainloads of "small skill" programmers out there.

Re:What about a re-implementation...

[Anonymous Coward]

That would be a reasonable question to ask, if you were totally ignorant about how a compiler or interpreter works.

It's like saying C isn't garbage collected, so any language implemented on top of it can't be, either.

Re:What about a re-implementation...

[FunkyELF]

I only used Go as an example of a somewhat safer (type checking, bounds checking, etc) language.
I never said I want a Go implementation, in fact I alluded to the fact that Go can't even build shared libraries.

Re:What about a re-implementation...

[Nutria]

And yet you'll trust languages implemented in it?

Why do you presume that of me?

(Back in the day, languages bootstrapped themselves. Now GOML!)

Re:What about a re-implementation...

[Nutria]

With C you have to be hypervigilinte

And yet the vast majority of C programmers... are not hypervigilant.

Re:What about a re-implementation...

[donscarletti]

Every so called "safer" language (than C) is also less efficient.

Depending on what you're doing. Compiled languages without pointers (such as Fortran and Pascal) are usually much faster for mathematical tasks, since side effects are so few (essentially concerning globals only), the compiler can much more easily automatically vectorise, reorder, factorise and unroll code. They also happen to be more safe, since you cannot simply tell the computer to write at a memory address, buffers can be bounds checked and so no overflows or underflows.

Problem is, they generally suck for IO, which is why they aren't used for SSL. Still, you should qualify where they are less efficient.

Re:What about a re-implementation...

[Anonymous Coward]

Not anymore, they are written in their own language!

Re:What about a re-implementation...

[Zero__Kelvin]

"And yet the vast majority of programmers... are not hypervigilant."

FTFY. Let's not single C out as if it is the exception to the rule.

Re:What about a re-implementation...

[Anonymous Coward]

That changes everything. All the crazy memory and resource management code that is inherent to C programs can be replaced by a clean lifetime management. RAII is the magic word. And yes I have programmed in both and have come to the conclusion: Correctly written C++ is way way less error prone. The OpenSSL error would have never happened in an idiosyncratic C++ program (as opposed to a program written by people with C habits). Unfortunately learning C++ is very hard for C programmers - it takes years to pick up the correct habits.

"idiosyncratic"--I don't think that word means what you think it means.

Re:What about a re-implementation...

[Anonymous Coward]

All programmers(c programmers) create bugs(logic or memory bugs), aka Heartbleed bug...

Re:What about a re-implementation...

[Anonymous Coward]

Juggling very long, very, very greasy sharp knives while skating on very thin ice is only unsafe for those of small skill, too.

Re:What about a re-implementation...

[Nutria]

Let's not single C out as if it is the exception to the rule.

While true, this thread is about whether or not C is or can be a safe language.

Re:What about a re-implementation...

[Anonymous Coward]

You've posted this in several threads. I don't understand why you think this is a good argument.

Re:What about a re-implementation...

[Anonymous Coward]

> But let's say you used some language which dynamically allocates memory for all strings and garbage-collects them when they go out of scope. It's "safer" in one respect, because it prevents the developer from having to do their own memory management.

You can still use a char array in Java and fill it with blanks after use. This will be similar to a char array in C only with bounds checking. It will get garbage collected some time later but this does not matter since sensitive data will already be overwritten after you are done with it.

Re:What about a re-implementation...

[Kjella]

For example, consider an server which acquires a passphrase from the client for authentication purposes. If your implementation language is C, you can receive that passphrase into a char array on the stack, use it, and zero it out immediately. Poof, gone in microseconds. But let's say you used some language which dynamically allocates memory for all strings and garbage-collects them when they go out of scope. (...)

That would be true if high level languages only offered the default implementation but usually they have a special implementation like SecureString in .NET, it'll let you do the exact same thing. For bonus points it'll also encrypt the data in memory in case you have to keep it around a little while, sure it's a bit of security through obscurity but it won't be trivial to find with a memory dump. The issue is more that people who aren't aware of the issues won't ever think to look for or use these classes, but they're available.

Re:What about a re-implementation...

[ljw1004]

one reason that security-related code is best done in low level languages is that the implementer has absolute control over sensitive data. For example, consider an server which acquires a passphrase from the client for authentication purposes. If your implementation language is C, you can receive that passphrase into a char array on the stack, use it, and zero it out immediately.

That scenario actually explains why security-related code is best done in MANAGED languages using something like SecureString
http://msdn.microsoft.com/en-u... -- this way, you still have API control to zero it out immediately, but you also benefit from the fact that you can make it ReadOnly, the fact that it's encrypted, the fact that it was authored by someone who's more expert in security than you and has had more eyes to review it than your ad-hoc solution.

Re:What about a re-implementation...

[blueg3]

So if C is so bad why should we trust the languages that are implemented in it? You do realize that most of these "safe" languages are written in C, right?

I'm just going to link to a previous comment where I answered the same question.

TLDR: Languages aren't "written in" anything, and the language the compiler is written in has no bearing on the capabilities of the language it compiles. (We're all Turing complete here.)

Re:What about a re-implementation...

[Lakitu]

If C-programmers make secure programs 85% of the time, it's pretty safe to make something with.

It's not safe to make everything with.

It's like how desks and other furniture will have rounded edges and corners instead of sharp points. Sure, you trust adults not to bump into inanimate objects around the office and hurt themselves, but would you bet on it never happening?

Re:What about a re-implementation...

[blueg3]

...you can receive that passphrase into a char array on the stack, use it, and zero it out immediately. Poof, gone in microseconds.

Only if you've set that part of your stack to locked. Otherwise it could get paged out to disk. Thanks to the fun of timing on computers, the amount of actual time that passes between "receive [into memory]" and "zero out" is arbitrarily long.

Re:What about a re-implementation...

[QilessQi]

Issues like that are why real, bulletproof security is incredibly hard. At least with low-level languages, you're close enough to the machine to at least be able to think about such things, and maybe even do something about them.

Re:What about a re-implementation...

[Zero__Kelvin]

No it isn't because that is a stupid question. C is a language, and like all languages it is never "safe" unless you know what you are doing. Also, like all languages I have encountered, it is "safe" if you do know what you are doing. There is no such thing as a "safe" or unsafe language; only safe and unsafe programmers.

Re:What about a re-implementation...

[QilessQi]

Agreed, in Java using a char[] still gives you some safety -- the fact that Java has primitives like byte and byte[] also let you mix high- and low-level code. But other languages may not give you that ability to get down-and-dirty with the machine.

Also, as another poster on this thread has observed, paging makes things even more complicated. If you can't prevent that char[]'s block of memory from getting swapped out to disk, then in theory there's an attack vector. C may let you avoid that scenario.

Re:What about a re-implementation...

[JDG1980]

And thay changes things, how? C++ allows all the same "unsafe" things as C does. Have you ever used C++ before?

Since C++ is a superset of standard C, yes, you can write the same kind of unsafe code in C++ that you would in C. And indeed many programmers do this.

But C++ gives you the tools to automatically catch various kinds of errors and memory leaks. If you use class destructors correctly, you can ensure that an object is automatically closed properly when it goes out of scope. There are a lot of standard classes such as smart pointers that are specifically designed with this kind of programming in mind. It's not 100% foolproof but it is a lot more reliable than having to remember to do it all manually in C (or C masquerading as C++).

Re:What about a re-implementation...

[Anonymous Coward]

Allows, yes. Deprecates, too. And it does offer safe alternatives for those dangerous constructs.

For instance, my C++ Standard Library offers iterators that reliably crash on read overflows, unlike C's pointers. That would have directly prevented HeartBleed. It's even safer than guard pages which may not crash on small read overflows. This isn't some rare expensive implementation, it's a free one used by thousands of developers every day.

Re:What about a re-implementation...

[thoth]

If your implementation language is C, you can receive that passphrase into a char array on the stack, use it, and zero it out immediately. Poof, gone in microseconds.

Or the compiler might helpfully optimize out your buffer clear : http://www.viva64.com/en/d/020...
Or in general: http://www.viva64.com/en/b/017...

There's just a ton of landmines to avoid while coding in C. Including the tools themselves.

Re:What about a re-implementation...

[Anonymous Coward]

Reducing the attack surface is worthwhile, even if it isn't perfect. More importantly, implementing a language's runtime in C is a very different case from implementing a language's compiler in C. Also, why use C? You could implement your language in Rust or some other safe language.

Re:What about a re-implementation...

[Nutria]

There is no such thing as a "safe" or unsafe language; only safe and unsafe programmers.

Sigh.

It's a good god damned harder to introduce an array index out-of-bounds error in Ada, PL/1, Pascal, BASIC and COBOL than in C.

Why? Because the RTLs in those languages check for out-of-bounds errors.

Thus, those languages, while not perfectly safe (nothing can be), are manifestly safer than C.

Re:What about a re-implementation...

[caluml]

I think we need an OS written entirely in Java...

Re:What about a re-implementation...

[JDG1980]

the fact that it was authored by someone who's more expert in security than you and has had more eyes to review it than your ad-hoc solution.

You may be right. Still... isn't that what most people were thinking when they used OpenSSL? It's a bad idea to roll your own crypto, we all know that, but we assumed that OpenSSL was written by people who understood security and that lots of eyes made bugs shallow. Turns out, that was completely wrong: OpenSSL was written by poorly trained monkeys, and however many eyes may have been scanning it, it obviously wasn't enough.

Re:What about a re-implementation...

[Zero__Kelvin]

"Thus, those languages, while not perfectly safe (nothing can be), are manifestly safer than C."

Bullshit. Tell that to the robot arm that is crashing down on your skull because the code to stop it was blocked by the GC (excepting ADA, which has other dangers, I'm sure)

Again, the biggest problem you have is not having any idea what you are talking about, and going on and on trying to quantify a language using qualatative terms.

Re:What about a re-implementation...

[gnasher719]

But C++ gives you the tools to automatically catch various kinds of errors and memory leaks. If you use class destructors correctly, you can ensure that an object is automatically closed properly when it goes out of scope. There are a lot of standard classes such as smart pointers that are specifically designed with this kind of programming in mind. It's not 100% foolproof but it is a lot more reliable than having to remember to do it all manually in C (or C masquerading as C++).

None of these would have stopped the Heartbleed bug.

Re:What about a re-implementation...

[Anonymous Coward]

d00d, you've just moved the goalposts. you're assuming that correctly written just follows
from using c++. this is just bad code, why do you think the author would have written
better code in c?

Re:What about a re-implementation...

[blueg3]

Real security is very hard. But really, real [lots of things in programming] are very hard if you want them done right. It's certainly possible for a higher-level language to expose the capabilities necessary to do things right. But if they don't, then it's a bad situation.

Re:What about a re-implementation...

[mysidia]

I never saw a C program with a remote file inclusion bug or a C code injection bug caused by an eval().

Pretty much all the errors caused by C fall into two buckets: reading an improper memory location and writing an improper memory location (including double-free'ing an invalid memory address).

As long as you can be certain to avoid those two conditions, C is just as safe as other languages. There are ways you can design your C programs, and rules you can follow which make it unlikely for you to include such errors.

For non-trivial programs, there are plenty of advantages of managing your own memory: which you cannot do in other languages such as Python or Java.

The other languages' use of garbage collection results in great space and runtime inefficiencies.

Re:What about a re-implementation...

[unixisc]

Isn't OS-X written in ObjectiveC - at least the parts that are not FreeBSD or XNU?

Re:What about a re-implementation...

[Anonymous Coward]

> Since C++ is a superset of standard C

Bzzt, wrong. C++ and C are different languages. C support things that C++ does and vise versa. They do have a common heritage, which is why they are very similar.

Re:What about a re-implementation...

[petermgreen]

While it might be nice to use a safe(r) language, can't we at least have a compile option in C that adds bounds checking?

Not really for the general case.

In a normal C compiler when a pointer is passed from one function to another, stored in a field of a structure, stored in a global variable etc no information about the start and end of the memory block it points to is stored/passed along with it.

In theory you could have a C compiler that used extended pointers which stored start and end information along with the pointer itself. In practice however such a C compiler would have several issues that would prevent it being widely used. Firstly it would be ABI incompatible with the standard C compiler, so you'd either have to build your whole OS and every app with this compiler or keep two paralell libraries sets. Secondly it would break assumptions that a lot of code makes about the size of pointers and their convertibility to/from intergers. Thirdly it would massively increase memory use.

There have been partial solutions for special cases which provide special versions of system functions that are commonly used in an unsafe manner then modify calls to those functions for the cases where the compiler does know the buffer size (e.g. because the buffer is a local variable) but they are far from a perfect fix.
.

Re:What about a re-implementation...

[EvanED]

With so called "safe" languages people are less vigilinte because they can get away with being lazy and not really understanding what is going on.

[Citation needed]

In my experience, this might be true if you start talking about performance. It becomes easy to create and discord oodles of objects on the heap unnecessarily or whatever.

But I don't find myself becoming less vigilant when I'm working in a more abstract language. I find myself thinking more about the problem and less about implementation details.

Re:What about a re-implementation...

[EvanED]

Show me an OS with more than 1% market that has a kernel and network stack that is not written in C/C++.

I'd argue that's bad too. (Some sample evidence: Linux kernel buffer overflow (2013). Linux KVM buffer overflow (2013). Remote Linux buffer overflow that could potentially lead to arbitrary code execution (2014). Integer overflow seemingly leading to buffer overflow in FreeBSD (2013). Windows 8 double free vulnerability (2014). etc.) There needs to be a small kernel of code that is in something very low-level, but honestly most of what is in current OS "kernels" (and I don't think that term applies to a piece of software with tens of millions of lines of code) doesn't have to be. Java isn't the right thing and maybe you don't even want something GC'd, but I also think C isn't either.

Re:What about a re-implementation...

[Anonymous Coward]

You could simply optimize it to use plain sockets without encryption (Since OpenSSL leaks your keys anyway). At least you won't have the illusion of security. Plus it will be much much faster and you wont have to play the revoke all your certificates game.

Re:What about a re-implementation...

[Anonymous Coward]

It can also send your private keys in microseconds. Fantastic!

Lets be honest here for a second. C code is hard to formally prove and verify. Also C is very verbose and error prone compared to most functional languages. Writing tons of hard to understand highly error prone code is much more serious an issue than keeping keys for a few more microseconds don't you think? I think that instead of making giant libraries that support everything and run very fast we should start with the goal of making simple and secure library that is designed especially to be easily verified. Seriously what is the point of having a crypto library with even a single critical flaw? It's highly likely that OpenSSL has many of these types of flaws. When we have something that works properly we can start thinking about making it fast without losing the security. I am afraid C is just another textbook example of premature optimization.

Re:What about a re-implementation...

[Anonymous Coward]

That was attempted. JavaOS was a disaster and finally discontinued in 2003.

Re:What about a re-implementation...

[Anonymous Coward]

Bounds checking? c++ supports that

Re:What about a re-implementation...

[goose-incarnated]

...Let's divide up problems into "memory errors" and "logic errors", where we broadly interpret "memory errors" as "errors your language or runtime won't let you make."

...

Furthermore, because in C you have to spend time and effort making sure you're not susceptable to memory errors, that takes time and effort away from looking for other errors...

While I broadly agree with your argument, I have to point out that the heartbleed exploit was due to the OpenSSL devs forgoing the system's malloc implementation and rolling their own abstraction for performance reasons. In effect they bypassed the system's protection, so arguing that removing the need for manual memory management would make code safer (it would) is irrelevant to the heartbleed exploit.

In this instance, had they been using Java or similar, it is likely that they would have still rolled their own for performance reasons, thereby still bypassing the languages protections.

Re:What about a re-implementation...

[gweihir]

That idea does not work: In practice most programmers always create the most complex code they can. Hence code comprehension complexity is solely dependent on programmer skill. The other thing why this idea is flawed is that a good coder encapsulates complexity so that you do not have to "track more objects" in some languages.

Re:What about a re-implementation...

[gweihir]

Most programmers these days are "small skill". I blame IDEs and languages that coddle them and let "small skill" people produce something resembling code without understanding what they are doing. http://blog.codinghorror.com/t... is an eye-opener.

Re:What about a re-implementation...

[gweihir]

Yes, but for them _anything_ is unsafe.

Re:What about a re-implementation...

[EvanED]

While I broadly agree with your argument, I have to point out that the heartbleed exploit was due to the OpenSSL devs forgoing the system's malloc implementation and rolling their own abstraction for performance reasons.

No. No it wasn't. The Heartbleed exploit was a classic buffer overread bug that would have been prevented by any language with bounds checking.

On OpenBSD only (for some definitions of only), this bug would have been rendered harder to exploit because of OpenBSD's hardened allocator. An additional problem was OpenSSL's custom allocator and their lack of testing with the system one. Had they not done that, it would have been much harder to exploit on OpenBSD -- but only OpenBSD would have been helped (again, for some definitions of only), and the root cause of the Heartbleed bug was still there.

Re:What about a re-implementation...

[goose-incarnated]

While I broadly agree with your argument, I have to point out that the heartbleed exploit was due to the OpenSSL devs forgoing the system's malloc implementation and rolling their own abstraction for performance reasons.

No. No it wasn't. The Heartbleed exploit was a classic buffer overread bug that would have been prevented by any language with bounds checking.

[Any language with bounds-checking protection] that would likely have been bypassed by the dev-team due to performance reasons. Seriously, for performance reasons this dev-team bypassed malloc of all things; do you really want to assert that they wouldn't have bypassed a bounds-checker?

In my previous post I thought I made this bit clear; it was not that there was protection on some platforms, it was that they bypassed all platform allocators in favour of their own. That's the bug right there. Everything else, like overruns, overreading, etc is a result of that decision. I cannot believe that, with a different language, they would have made a different decision

Re:What about a re-implementation...

[bluefoxlucid]

Somebody has to write the back-end code; and you're arguing on one side that poor programmers will fuck up anyway, and on the other side that good programmers will fight the language paradigm (and make some jumble of weird shit like C++ std.cout operator overloading "to reduce complexity" so nobody can read and understand their code).

Re:What about a re-implementation...

[Anonymous Coward]

You're an idiot.

Re:What about a re-implementation...

[Anonymous Coward]

Not with memcpy you can't.

Re:What about a re-implementation...

[EvanED]

Seriously, for performance reasons this dev-team bypassed malloc of all things; do you really want to assert that they wouldn't have bypassed a bounds-checker?

How would they have bypassed the bounds-checker? About the only way would have been to say int[] all_my_programs_data = new int[1000000000] and then write an interpreter for their own language that uses that array as its data store!

Let's take the example from XKCD: "HAT (500 letters)". To read past the end of the "HAT", they would have had to manually copy that string to some communal store, like all_my_programs_data, and then read past the end. Aside from completely ignoring the language runtime and implementing your own on top, in a language with enforced bounds checking you would not have been able to read past the end of "HAT"!

I've only clicked on your reply a couple minutes ago, but aside from "change the language runtime to no longer enforce bounds checks", I literally cannot think of any other way you would bypass a language's bounds checks.

Everything else, like overruns, overreading, etc is a result of that decision.

No it isn't! It's almost entirely orthogonal!

The OpenBSD malloc that they bypassed makes exploits of already compromised programs harder; that's why Theo refers to "exploit mitigation". If OpenSSL didn't have the overread to begin with, the fact that they replaced malloc would be a questionable decision but wouldn't have led to any exploit. And even with a hardened allocator (or most hardened allocators, anyway), the exploit is still there, it's just much harder to get anywhere near as much confidential information.

That's the only way that they aren't orthogonal: the two mistakes reinforce each other on OpenBSD. In all other respects, they are completely independent.

Re:What about a re-implementation...

[Anonymous Coward]

I'd be curious to know how Rust and D stack up, efficiency-wise.

Re:What about a re-implementation...

[Zero__Kelvin]

"But I don't find myself becoming less vigilant when I'm working in a more abstract language. I find myself thinking more about the problem and less about implementation details."

But you have the experience with, and therefore the understand of, the issues. You wouldn't have that if you started with a "safer" language and stayed there, as would be the case if everybody "just used safer languages"..

Re:What about a re-implementation...

[david_thornley]

If you are certain to avoid memory management problems in C, you're not using much of the memory facilities. It's really easy to get memory management wrong in C.

Re:What about a re-implementation...

[Desler]

Unless the language is portable to all platforms it's useless for a portable library. And none of those "safe" langauges are portable as C.

Re:What about a re-implementation...

[david_thornley]

C++ is safer than C, and just as fast.

Re:What about a re-implementation...

[david_thornley]

The closest thing I know is to write in C++, use library containers instead of arrays, and use the bounds-checked calls. There is no frickin' way you're going to make raw pointers safe and bounds-checked in general. I suspect it's equivalent to the Halting Problem, but haven't done the work to check. The only possible approach is to have a strict discipline, which is much easier to do in C++.

Re:What about a re-implementation...

[david_thornley]

With higher-level languages, you can make language constructs that enforce things like that. If you have a set of rules about locking memory pages and zeroing out data, you're going to miss something sometime. If you have a language construct that does it, you won't miss things. If you have to write your own, you'll be able to test it and prove correctness once, and guarantee not making those mistakes 238 times.

Wonderful!

[cold fjord]

I have little doubt that the OpenBSD team will significantly improve the code.

"Please Put OpenSSL Out of Its Misery"

[Anonymous Coward]

We also have a comment from the FreeBSD developer Poul-Henning Kamp.

He starts by saying "The OpenSSL software package is around 300,000 lines of code, which means there are probably around 299 bugs still there, now that the Heartbleed bug — which allowed pretty much anybody to retrieve internal state to which they should normally not have access — has been fixed." After that he notes that we need to ensure that the compiler correctly translates the high-level language to machine instructions. Later Kamp rants a bit about the craziness of CAs in general — would you trust "TÜRKTRUST BLG LETM VE BLM GÜVENL HZMETLER A.."? Then he lists some bullet points about things that are wrong in OpenSSL:

- The code is a mess
- Documentation is misleading
- The defaults are deceptive
- No central architectural authority
- 6,740 goto statements
- Inline assembly code
- Multiple different coding styles
- Obscure use of macro preprocessors
- Inconsistent naming conventions
- Far too many selections and options
- Unexplained dead code
- Misleading and incoherent comments

"And it's nobody's fault. No one was ever truly in charge of OpenSSL, it just sort of became the default landfill for prototypes of cryptographic inventions, and since it had everything cryptographic under the sun (somewhere , if you could find out how to use it), it also became the default source of cryptographic functionality. [...] We need a well-designed API, as simple as possible to make it hard for people to use it incorrectly. And we need multiple independent quality implementations of that API, so that if one turns out to be crap, people can switch to a better one in a matter of hours."

Re:"Please Put OpenSSL Out of Its Misery"

[Anonymous Coward]

Since there are so many people using OpenSSL, it would be nice to see various companies/organizations (RedHat, IBM, Cisco, banks, national governments) and others who depend on this library perhaps to toss some resources at rewriting OpenSSL (perhaps OpenSSH) and doing it the "right" way. At the minimum, they should toss something at the OpenBSD foundation for having to clean up the mess and produce something usable that so many companies, organizations, and governments rely on for their day to day security.

OpenSSL doesn't need to be fixed, it needs to be reviewed closely. This is what NIST/the NSA should be paid to do.

Re:"Please Put OpenSSL Out of Its Misery"

[Anonymous Coward]

I agree that the OpenSSL code base is very bad. (I was doing some work based on modifying the library recently and I had to hold my nose.) However, I take objection with some of this:

- 6,740 goto statements

Otherwise known as "the only sane way to simulate exceptions in C". Seriously. Read up on how "goto" is used in low-level code bases such as OS kernels, instead of citing some vague memory of a 1960s paper without understanding its criticisms.

- Inline assembly code

Otherwise known as "making the thing go fast". Yes, I want the bignum library, or hashing algorithms, to use assembly. Things like SIMD make these tasks really effing fast and that is a good thing...

Re:"Please Put OpenSSL Out of Its Misery"

[Anonymous Coward]

It's not just the library that's in shit shape, the openssl commandline tools themselves are annoying. Getting it to generate a UCC/SAN certificate with multiple hostnames is a hoot (you hardcode the list of alternate names into the openssl configuration file. Then when you want to create a different certificate you hardcode a new list of alternate names into the openssl configuration file), and just using it for its intended purpose basically requires that you either completely understand SSL certificates and what a Common Name is, or you have read a walkthrough to explain that when it asks for your name, it means it wants your hostname.

Re:"Please Put OpenSSL Out of Its Misery"

[Anonymous Coward]

What else?
I mean, I've learned enough about the OpenBSD team's work to realize that OpenSSH is widely respected.
OpenSSL wide usage led me to believe that OpenSSL was probably also taken care of by some equally respected people.
What other super-critical code is really important and widely used, but is code which people aren't really happy with?
I know that TrueCrypt has some questionability ( actually that status was recently updated and discussed: http://it.slashdot.org/story/14/04/14/2211232/first-phase-of-truecrypt-audit-turns-up-no-backdoors ). However, it isn't used quite as widely as other critical software.
Since I imagine there must be something, are there any knowledgeable experts that knows of another major item that really must be dealt with, and which (like SSL) is widely obvious that it deserves more eyes and effort? (I know that without that last clause, thousands of projects could probably qualify.) And preferably, unlike the million-dollar Millennium Prize Problems, actually stands a high chance of getting substantial improvements fairly quickly? ... and which isn't closed source? (Sorry, I had to exclude Microsoft Windows.)

What open source projects fit that criteria, and so are just begging for additional expert review/cleanup?
As an example idea: with all of the racing being done between filesystem battles (Ext4, BtrFS, ZFS, none of which OpenBSD natively supports), are those pleasant from the important perspectives (security... or perhaps a more critical concept for a filesystem driver is simply reliability)?

Re:"Please Put OpenSSL Out of Its Misery"

[Tharkkun]

I don't understand why we would donate more money to the people that left us in this mess in the first place?

Re:"Please Put OpenSSL Out of Its Misery"

[lactose99]

You do know that you can use the SAN environment variable to create UCC certs without having to modify openssl.cnf right? Its much easier to create multiple UCC certs that way.

Re:"Please Put OpenSSL Out of Its Misery"

[JDG1980]

Otherwise known as "the only sane way to simulate exceptions in C". Seriously. Read up on how "goto" is used in low-level code bases such as OS kernels, instead of citing some vague memory of a 1960s paper without understanding its criticisms.

I agree that using the goto statement is about the only sensible way to simulate a try/throw/catch block in C (of course, you can wrap this in macros to simplify). But that's a serious flaw in the C language, and it means that the maintainers of the C standard should have updated the standard with conditional execution methods that allows this to be handled in a more elegant manner – maybe something like Windows structured exception handling.

But 6,740 of them? Really? I find it hard to believe that all were necessary, unless OpenSSL's code base is even more bloated than I've been led to believe.

Otherwise known as "making the thing go fast". Yes, I want the bignum library, or hashing algorithms, to use assembly. Things like SIMD make these tasks really effing fast and that is a good thing...

These days it's usually recommended to handle SIMD with compiler intrinsics, not inline assembly. You get the added power without having to do the whole inner loop on bare metal, or worry about your register usage conflicting with that of the compiler. (GCC's inline assembly syntax is almost incomprehensible.) Maybe, maybe, there are a tiny handful of inner loop situations where you need actual inline assembly, but don't jump to that conclusion ahead of time. They should have first written the algorithms in C, then tested and profiled, then if there were areas where more speed would be helpful, try compiler intrinsics to speed up and/or parallelize the bit-twiddling; and only then resort to inline assembly if that wasn't good enough. But OpenSSL was full of premature optimizations like their crappy fake malloc that was designed for unspecified systems that allegedly had poor performance with the system malloc. Why should we all have to put up with poor security because some idiot is still running a 386?

Re:"Please Put OpenSSL Out of Its Misery"

[Anonymous Coward]

They should have first written the algorithms in C, then tested and profiled, then if there were areas where more speed would be helpful, try compiler intrinsics to speed up and/or parallelize the bit-twiddling; and only then resort to inline assembly if that wasn't good enough.

If you look at the pieces that have assembly, they do also have generic portable C implementations, so I would guess that somebody at some point made these determinations. (Whether they are current optimizations that hold up on hardware you'd buy today, I don't know.) I was a little surprised, for instance, that some algorithms don't have asm for ARM.

Re:"Please Put OpenSSL Out of Its Misery"

[melatonin]

Otherwise known as "the only sane way to simulate exceptions in C".

Right, because using exceptions for error handling is safe.

Re:"Please Put OpenSSL Out of Its Misery"

[Anonymous Coward]

- Inline assembly code

Otherwise known as "making the thing go fast". Yes, I want the bignum library, or hashing algorithms, to use assembly. Things like SIMD make these tasks really effing fast and that is a good thing...

Yes but the real question is "Do you prefer this speed to keeping your private keys private?".

Re:"Please Put OpenSSL Out of Its Misery"

[tulcod]

http://marc.info/?l=openssl-de...

This was the first patch sent to openssl-dev after the heartbleed revelations. Although in this case it's a misplaced "goto err", it could have been a "goto fail".

Is there a case for using goto once every decade? Sure. But not 6740 times.

Re:"Please Put OpenSSL Out of Its Misery"

[Anonymous Coward]

Sorry, are you suggesting Poul-Henning Kamp, long time FreeBSD kernel developer, responsible for the GEOM storage layer, FreeBSD jails, and the Varnish project, doesn't know what he's talking about?

I would respectifully suggest, just possibly, that he does.

Re:"Please Put OpenSSL Out of Its Misery"

[chriscappuccio]

These are the exact issues that OpenBSD is fixing. Also PHK has commended OpenBSD for taking the effort, so I think he agrees.

Re:"Please Put OpenSSL Out of Its Misery"

[Anonymous Coward]

I was aware of who PHK is. Idiotic comments are idiotic comments.

Re:"Please Put OpenSSL Out of Its Misery"

[Anonymous Coward]

I will again say that "once in a decade" absurdly low if you are doing any kind of kernel development.

I happen to have an OpenBSD machine with full source handy.

$ grep -r goto /usr/src | wc -l
  44576

Re:"Please Put OpenSSL Out of Its Misery"

[Anonymous Coward]

Sorry, ironically enough that machine didn't have the kernel source. Extracted that, did that again, and the total is 55022. So about 10K in the kernel, 44K in user mode.

Re:"Please Put OpenSSL Out of Its Misery"

[strikethree]

"And it's nobody's fault. No one was ever truly in charge of OpenSSL, it just sort of became the default landfill for prototypes of cryptographic inventions

Erm, OpenSSL is the continuation of a project by (IIRC) an Australian named Eric A Young. I have been using that code base since it was called SSLeay. The mists of time are not THAT thick yet.

Ted Unangst's article

[grub]

Ted Unangst wrote a good article called "analysis of openssl freelist reuse"

His analysis:

This bug would have been utterly trivial to detect when introduced had the OpenSSL developers bothered testing with a normal malloc (not even a security focused malloc, just one that frees memory every now and again). Instead, it lay dormant for years until I went looking for a way to disable their Heartbleed accelerating custom allocator.

it's a very good read.

Re:Ted Unangst's article

[grub]

heh and I see it was linked to in TFA. Sorry.

Re:Ted Unangst's article

[MozeeToby]

The most concerning part comes at the end "Here's a 4 year old bug report showing the issue, and another, and another". OpenSLL is supposed to be security software... shouldn't happen.

Re:Ted Unangst's article

[Anonymous Coward]

That's ok, it's not like anyone reads the article anyway.

Re:Ted Unangst's article

[GumphMaster]

My favourite bit: "There are probably many ways to shave this yak; here’s one." I always love a new (to me) take on classic clichés.

It strikes me that, even if you accept a need for internal memory management like this, you would expect the security sensitive software to assume that every freed block of memory contained something sensitive and zero it immediately. Had it been doing that this bug would also have appeared many moons ago.

Re:Ted Unangst's article

[LIGAFF]

The same speed-above-all sensibility which led to a one-off memory allocator and use of inlined assembly code would not permit wasting time zeroing memory before or after use.

Backport\Upstream? Seems unlikely

[Anonymous Coward]

Removal of ancient MacOS, Netware, OS/2, VMS and Windows build junk
Removal of “bugs” directory, benchmarks, INSTALL files, and shared library goo for lame platforms
Ripping out some windows-specific cruft
Removal of various wrappers for things like sockets, snprintf, opendir, etc. to actually expose real return values

There's no doubt that OpenSSL needs work, but they seem to be needlessly combining actual security review with "break every platform that I don't like." At a minimum, anyone else trying to benefit from this will need to unravel the worthwhile security changes from the petty OS wars crap.

Thanks!

[Anonymous Coward]

Just wanted to give my thanks to freetards everywhere for breaking the internet!

Sent from my Windows 8 Phone.

Re:Thanks!

[the_povinator]

I'm wishing there was a "+1 troll" option for moderation.

Re:Thanks!

[gweihir]

You do know that the difference is that if this was closed source, we would just have heard about it a lot later, right?

Re:Thanks!

[Anonymous Coward]

It is a good point in a backhanded way. If Microsoft's code had been the root cause, there would be a hatestorm of immense proportions. Since it's open source, the overall attitude has been, "oops! it's okay, they can fix it,it's an honest mistake!" and few people even bat an eye about how bad the code really is and how few people it took to really screw it up. It's a double standard.

Re:Thanks!

[TechyImmigrant]

No. We all love to hate on OpenSSL because it's a pile of poo.

There are vested interests who make a living because they have write permissions to OpenSSL and they can charge companies to do it and the barrier to entry to others is really high because it's a undocumented, over complex pile of source.

Re:Thanks!

[Anonymous Coward]

How can you be sure?

Something like this might have been avoided completely, as the company might have had more structured leadership (and thus better communication and code architecture). Alternatively the bug might have been fixed much earlier, as the company might have had more resources for good code audits than open source (which relies on donations).

Re:Thanks!

[Zero__Kelvin]

" If Microsoft's code had been the root cause, there would be a hatestorm of immense proportions. Since it's open source, the overall attitude has been, "oops! it's okay, they can fix it,it's an honest mistake!""

I must have missed it. When did the OpenSSL team use illegal and immoral businesses practices to coherce or trick people into having to pay money for their software? You see. That's the difference in a nutshell. If you offer someone something for free they tend to be more forgiving of flaws than if you force them or trick them into buying it.

Re:Thanks!

[Anonymous Coward]

People trusted OpenSSL because the FOSS community zealots have been implying for years that open source is always better than closed source. That itself is a trick. They're more forgiving because it isn't Microsoft. Even Google or Apple would've gotten a free pass.

Re:Thanks!

[Anonymous Coward]

The tech press hasn't been overly forgiving, those paid to report on business and ms related tech have used this as a stick with which to beat open source and linux, ignoring the fact that the openness of the code isn't what caused the bug in the first place, it just happened not to make this particular bug a shallow one on this occasion. Scroll up and you'll see trolls harping on about myths of bug-free code because of open source practices, everyone with half a brain realises that such expectations are incredibly stupid, these myths are fabricated by those who are, even in this day and age, scared by free software.

Re:Thanks!

[gweihir]

You obviously have never reviewed security critical "closed" code. I have. It is routinely a lot worse than the open code, exactly because almost nobody looks at it.

Re:And they've already stopped

[Anonymous Coward]

Apparently you didn't read the second news item on the OpenBSD news site, where they reached their 2014 funding goal of $150,000 last week.

Re:And they've already stopped

[Anonymous Coward]

Should they not be getting some tax funding??? This is so ironic projects like this that if they fail can take down the next every company that uses these projects pays taxes should tax money not be given with out any strings like no nsa back doors or the sort but rather make sure all bugs are taken care of? To many companies profit from ssl yet the project that maintains it is on very week standings.

"Ancient." "Cruft."

[jabberw0k]

I read that as discarding stuff for Windows 98, 2000, and other ancient platforms that have fallen almost entirely from use, and certainly outside the pool of what's tested: A good thing.

Re:"Ancient." "Cruft."

[Razgorov Prikazka]

You forgot Windows 1.x, 2.x, 3.x, 95, PocketPC 200x, mobile 5, 6, 7, 8, RT, NT3.1, 3.5, 4.0, XP, Server 20xx, XP, Vista, 7, 8, 8.1 and finally CE1.x to CE7.x.

Those should be avoided at all times as well if security is the main concern. Have you ever heard of a security breach on a OpenBSD system? You probably did, it's because that is actually newsworthy! News of a new MS security breach is chucked into the same lame bin as 'Cat is stuck in tree', 'Small baby is born', 'MH370 is finally found', 'Cat still stuck', 'MH370 still not found', 'Is this the year for BitCoins'?, "Cat climbed down himself', and other nonsense that will surprise no one at all.

(P.S. This is not meant snarly, cynical or negative, just slightly blasé)

Re:"Ancient." "Cruft."

[Anonymous Coward]

Ah, I see. So when I hear of a security breach for Windows, OSX, or Linux it's because those are active hives of insecurity, but if I hear about one for BSD, it's only because they're so rare... Riiiiight. Got it. Windows, full of viruses, everything else is "secure" until OSX starts getting more malware... Then Linux and BSD are paragons of security, until you look at the Linux updates and news and see that it's got some consumer end users now and viruses too... But BSD?

Oh no way is it any where as insecure as all the other operating systems. Nope. No Siree. This OpenSSL thing -- Well that's just a bug in a package not BSD proper. It would be like blaming Adobe Flash or Java bugs on Windows boxes --wait... bad example! What I mean to say is, BSD is the least popular consumer OS so it's got the best security Just like Linux and OSX and .... OK, look. What we have to realize is that BSD is superior because they have awesome unit test suites with input fuzzing for all their security related softwa-aaait?

They don't practice the bare minimum security test harness that any security researcher would throw at a piece of software for their default codebase? Huh. Well then. I guess BSD is just a bunch of kludge ridden crap like every other piece of shit on the market. And if you don't believe me, you haven't fucked with any of their source code for long enough to know better.

Re:"Ancient." "Cruft."

[Anonymous Coward]

So brave!

Re:"Ancient." "Cruft."

[cheesybagel]

For whatever unfathomable reason Microsoft decided to make Winsock use the BSD socket API *but* you need to use Windows specific error handling mechanisms, Windows specific constants, initialization and shutdown functions, etc.

Re:"Ancient." "Cruft."

[petermgreen]

And while it has a "select" function it's not much use in practice because it can ONLY select on sockets, so you end up with windows specific event and/or thread handling as well.

Re:"Ancient." "Cruft."

[Anonymous Coward]

Winsock was not created by Microsoft, it was developed by third party vendors selling IP based products. In essence, each vendor (such as Sun, FTP, NetManage) implmented their own version of Berkeley sockets to emulate what was found on Unix. All the vendors got together in an informal BoF discussion to create a unified Windows Socket API in 1991 and Winsock 1.0 was born.

Re:"Ancient." "Cruft."

[Anonymous Coward]

Evidently you can add "Slashdot still doesn't support unicode" to your list of examples...

Re:"Ancient." "Cruft."

[Anonymous Coward]

I'm shocked Windows ME is not there...

Re:"Ancient." "Cruft."

[cupantae]

Take the functionality, ditch the compatibility. Sounds right.

Re:"Ancient." "Cruft."

[the_B0fh]

Wow. What a moron. No wonder you had to post as AC.

We're talking about OpenBSD, not BSD. Not Linux.

They're not the same.

Re:"Ancient." "Cruft."

[the_B0fh]

Just like how openssh is unusable on Linux, other BSDs, embedded platforms, windows, and so on, right?

And you do realize that by them forking the code, *THEY ARE NOW THE UPSTREAM* for this?

While it may sound like that...

[Anonymous Coward]

The first step to cleaning up the code is getting it into a state where you're not leaving crap in place because 'It's for something I don't understand.'

That's what got us in the current OpenSSL mess in the first place.

Additionally, once the core code is cleaned up you can always follow the changelogs and merge the legacy stuff back in (assuming they're using git, or another VCS with a good git check(in/out) module.)

Honestly anyone still running any of those OSes is probably running a 0.9 series library and thus wasn't vulnerable to this bug to begin with. Who knows how many of those alternate paths even still worked anymore.

Re:Backport\Upstream? Seems unlikely

[gman003]

It's a fork specifically for OpenBSD. Why would they keep support for other OSes?

I agree that if they were trying to create a general replacement fork of OpenSSL, that those would be bad things, but for what they're trying to do, these are good decisions. They're trying to improve OpenBSD's security - OpenSSL is a big attack surface, and they're trying to make it smaller by removing the things they don't need.

This will complicate things both ways, going forward. Updates to OpenSSL might be harder to integrate with OpenBSD's fork (if it becomes an actual independent product, can we call it OpenOpenSSL? Or Open^2SSL?), if it touches upon the altered parts. Likewise, anyone trying to merge an Open^2SSL fix into OpenSSL might have difficulty. I expect that if OpenBSD's fork of OpenSSL becomes a separate project, one or the other will die off, simply due to all that duplicated effort.

What I expect to happen in that case is that Open^2SSH will maintain compatibility with all the platforms OpenSSH or OpenSMTPD (which are OpenBSD projects) support - pretty much any Unix-like environment, including Linux, BSD, OS X, Cygwin, and most proprietary Unices. If there's enough desire for support for other platforms, a second fork might happen to maintain them, but I honestly doubt it (Mac OS 9? Really?).

Re:Backport\Upstream? Seems unlikely

[Anonymous Coward]

I think the point is to have as little code as possible, and to have no code that isn't covered by their tests. Both of which are excellent ideas if you want to write secure code.

Re:Backport\Upstream? Seems unlikely

[Anonymous Coward]

Have you read the OpenSSL code base? A lot of what appears inside an #ifdef WIN32 is complete garbage and in most cases you'd be fine with the normal libc stuff the Unix version gets.

Re:Backport\Upstream? Seems unlikely

[dirtyhippie]

It's not remotely about petty OS wars. Complexity is bad for security, mmkay? If you want a newer version of openssl for OS/2, netware, or pre OSX MacOS, I'd really like to know what exactly you are doing. Dropping those platforms is the right thing.

Re:Backport\Upstream? Seems unlikely

[gweihir]

Indeed. Most coders just add more code when they run into an issue. That is a problem for normal code, but it is death for anything security-critical.

Run!

[digitalPhant0m]

The OpenBSD has started

The OpenBSD cometh.

OpenSSL OR...

[higuita]

Or simply support and use the GnuTLS!

both have their own set of problems, but at least now you have the a alternative.

Re:OpenSSL OR...

[Anonymous Coward]

The biggest problem is "GNU" in the name, scaring companies away.

Re:OpenSSL OR...

[gman003]

OpenBSD tries extremely hard to make the entire system BSD-licensed. AFAIK the only non-BSD items in a default installation is GCC, and that is an optional-but-default item. There are a few optional, not-compiled-by-default and rarely-used kernel modules that are GPL (an FPU emulator for very early x86 systems is the only one I recall), and of course you can install non-BSD packages as you wish, but the base OS and all components are BSD-licensed.

GnuTLS, naturally, uses the LGPL, which is probably why they went with OpenSSL (BSD-licensed) in the first place.

Re:OpenSSL OR...

[greg1104]

It's not "simply" though. The interfaces in OpenSSL and GnuTLS are not swappable APIs. We went over this a few years ago for PostgreSQL, and one of the major issues was having too many OpenSSL-isms in our code to swap easily.

Those of us who dislike bad open source licenses have been trying to kick OpenSSL out of projects for years now, and it hasn't gone anywhere but upward in adoption. I've been amazed at how often I see its advertising clause in the credits of video games I play.

Re:OpenSSL OR...

[higuita]

Let then eat their dog food! if they want to take other people code without helping back.

If they don't like it anything in the code, they should improve it and release it to the world or for ever maintain a internal version...

if they know better, they don't be afraid of the GNU part and collaborate in the gnutls development. Please note that the gnutls is LGPL, so they are free to use it in commercial programs, as long any change to the gnutls is released... nothing more.

Re: Not 0.9.8

[Anonymous Coward]

I checked the CVS comments last night; pretty sure they are working off 1.0.1g. Based on the commit comments they are breaking it into pieces (using the crypto functionality of OpenBSD not OpenSSL) as well as ditching all the code that is intended to make it work on other systems. It looks like the final product will be integrated in the base - not portable.

Re:Backport\Upstream? Seems unlikely

[jeffmeden]

It's a fork specifically for OpenBSD. Why would they keep support for other OSes?

You only fork when you want to put distance between the original; there is nothing stopping them from making changes/"improvements" to the original OpenSSL project except for scope constraint (i.e. if they just want OpenBSD to be secure) or ego. Either one stinks of selfishness. I cant criticize them directly since they are still doing all of their work for "free" and are publishing it freely, but it has to be pointed out that they are choosing the greater of two evils.

Re:Backport\Upstream? Seems unlikely

[DMUTPeregrine]

Their theory is that they need an SSL system for OpenBSD. They're not trying to build it for other platforms, and the extra code adds complexity (and can contain vulnerabilities) so they're not going to maintain it. They're cutting out unnecessary cruft. That cruft may be needed for some users, but OpenBSD doesn't have any use for OS/2 support.

Re:And they've already stopped

[Anonymous Coward]

The OpenBSD project has some history of being funded by the American federal government (perhaps indirectly, as there was some sort of university involved).
To summarize, that ended rather poorly.
The project is officially headquartered in Canada, home of Theo (project lead) and also someone else with ties to the University of Alberta (which is probably related to why University of Alberta has benefited from early use of anti-spam techniques in OpenBSD, and why University of Alberta is a distribution site, hosting the main website last time I checked).
A lot of the government funding that I hear about comes from an organization like the NSF, which is the (American) National Science Foundation. I don't hear about nearly as much funding from the Canadian national government. Then again, I am American, so that makes it a bit less surprising if I'm more familiar with programs that involve the American government. (It is quite possible that Canada does do more than what I am aware.)

Re:Backport\Upstream? Seems unlikely

[Anonymous Coward]

The ancient garbage needs to go. If the platform is effectively dead and the developers can't test against it, delete the code its time for the lazy/cheap to upgrade it they want support/improvements.

Re:And they've already stopped

[Minwee]

$30,949 is how much the OpenBSD Foundation received in donations in 2013.

That's about $29,000 more than OpenSSL receives every year, and still $22,000 more than they received this month when the entire world realized that they had been freeloading and scrambled to make themselves look good by making one-time donations.

Re:Backport\Upstream? Seems unlikely

[MightyMartian]

Indeed. If there are still a significant-enough number of OS/2 users out there to warrant OpenSSL upgrades, then someone will fill the need. But we all know there isn't enough users of these old OSs to actually warrant ancient code being maintained.

I'd love to hear his /. beta rant

[Anonymous Coward]

Yes, Theo has a bad temper

That rant would be epic. But seriously, the login doesn't even work. Showing stories doesn't work. There's no post new message button. There's only a reply to button. How do we disable this crap? I see the "click here to return to the Classic version of Slashdot" link has been disabled. I guess too many people were using it. How do I disable it so I can login again?

Re:Backport\Upstream? Seems unlikely

[MrBingoBoingo]

With something as big and messy as crufty as OpenSSL, there probably isn't a sane way to approach the problem of decrapifying it that doesn't involve first stripping it down to the minimum.The OpenBSD devs aren't Windows devs, Apple Devs, or Linux Devs. There is no "greater evil" in making something more secure in less time for your own platform when contorting themselves to maintain compatiility keeps junk that slows them in their task to the point they don't every get to the clean secure rewrite.

Re:Backport\Upstream? Seems unlikely

[serviscope_minor]

they are choosing the greater of two evils.

No.

Eventually supporting too many screwy and ancient systems starts to cause just so many problems that it is really, really hard to write solid, well tested, clear code. The heartbleed bug was exactly a result of this. Because of supporting so many screwy platforms, they couldn't even rely on having malloc() work well. That means they had their own malloc implementation working from internal memory pools. Had they not, they would have benefited from the modern mmap() based implementations and you'd have got a segfault rather than a dump of the process memory.

Supporting especially really old systems means having reimplementations of things which ought to be outside the scope of OpenSSL. Then you have to decide whether to always use the reimplementation or switch on demand between the custom one and the system one and whether or not to have some sort of quirk/bug correction.

This sort of stuff starts to add up and lead to a maintainance nightmare.

What OpenBSD are doing: throwing out all the accumulated crud and keeping the good parts is a fine way to proceed. It will almost certainly be portable to the other BSDs, OSX and Linux since they provide similar low level facilities. I doubt a port back to Windows would be hard because modern windows provides enough sane facilities that it's generally not too bad for heavily algorithmic code like this.

Basically there's no way for them to get started except to first rationalise the code base and then audit it.

Right on.

[PhrostyMcByte]

Otherwise known as "the only sane way to simulate exceptions in C". Seriously. Read up on how "goto" is used in low-level code bases such as OS kernels, instead of citing some vague memory of a 1960s paper without understanding its criticisms.

People who don't use goto for error handling in C more often than not either have incorrect error handling or way too much error-prone duplication of resource cleanup code. It makes sense to very strictly warn newbies away from goto, much in the same sense that you warn them from multithreading. You don't want them used as a universal hammer for every nail in the code. At some point though, people need to jump off the bandwagon and learn to respect, not fear, these things that actually have some very compelling uses.

Re:Right on.

[Anonymous Coward]

"People who don't use goto for error handling in C more often than not either have incorrect error handling o"

Parser fail. Please be more clear.

Re:Right on.

[Anonymous Coward]

People who don't use goto for error handling in C more often than not either have incorrect error handling or way too much error-prone duplication of resource cleanup code. It makes sense to very strictly warn newbies away from goto, much in the same sense that you warn them from multithreading.

Well, to some extent. Multithreading can crew you over and make thing hard to fix, but the newbie learns pretty quick why multithreading can complicate things.
I feel that goto mainly becomes a problem if you need to use a goto because of bad structure. The thing is that removing goto isn't going to help the programmer and teaching them how to structure their code is going to resolve the problem anyway.
The big thing that can cause hard to solve problems that I feel often is left out is the usage of floats. Telling people to not use floats in a loop or using them for calculating differences should be taught before you tell them not to use goto. Teaching them when it is safe and how to do it in a safe way should be done after they know how to use goto.

Re:Right on.

[rk]

Heh. I've written many gotos in C. Almost universally, the label they go to is called "error_exit" which sits right before resource deallocators and the return statement. :-)

Re:Right on.

[Anonymous Coward]

It's very clear to anyone with half a brain that you aren't ever going to see a secure operating system or crypto library that is written in C.

Tell me why in 2014 we have things like for loops and gotos instead of list comprehensions and recursion will tail optimization to write crypto libraries? Languages like C make you do the same repetitive things over and over where a single mistake can cause the entire security of the system to be compromised. Also with languages like C and C++ you are continuously fighting the language (writing for loops macros dealing with memory) instead of focusing on writing correct code. Anyone with knowledge of languages like Haskell, ML, Erlang and maybe Python knows what I am talking about.

If you want security you need the following properties in a language:

1. Immutability
2. Iteration abstractions (ex: map, foldr, filter, list comprehensions)
3. Tail recursion
4. Pattern matching
5. Static type checking

Writing formally proven C code costs around 10K USD per line on average. That would put the cost of cleaning up OpenSSL at 3 Billion USD. So make a choice people plain text or slightly slower crypto. There is also no technical reason why functional languages can't be designed to be as fast as C.

OpenSSL can just backport anything OpenBSD fixes.

[Ungrounded Lightning]

There's no doubt that OpenSSL needs work, but they seem to be needlessly combining actual security review with "break every platform that I don't like." At a minimum, anyone else trying to benefit from this will need to unravel the worthwhile security changes from the petty OS wars crap.

I don't see this as a problem. Since OpenBSD is working on their own, for-themselves, branch, they can fix it any way they want. If they do a good job (as expected), the OpenSSL project can then backport their fixes into their project and integrate it to their hearts' content.k (If they chose not to, someone else can chose to fork and do it, and the two versions can fight it out for acceptance.)

This is how it works in the Bazzaar.

What other dragons are out there?

[jones_supa]

The single heartbleed vulnerability awakened people to actually take a deep look into the OpenSSL code. Where were all the "eyeballs" before that? Now we are in a position where suddenly the whole OpenSSL code needs massive rearchitecturing. It just makes me cringe when I think what other OSS projects possibly have similar serious problems, possibly in mission critical components. It's starting to be quite obvious that there is not enough people to actually take a look under the hood and say, hey this quite crusty code and needs fixing.

I find the open development process of software to be extremely interesting, but am not scared to point out possible flaws in it. So should be no one else.

Re:What other dragons are out there?

[FranklinWebber]

>...heartbleed vulnerability ...Where were all the "eyeballs" before that?

Inside the NSA.

PolarSSL

[Aethedor]

Maybe it's time to realize that OpenSSL has become obsolute. For me it's totally unacceptable that even now the documentation is [STILL INCOMPLETE]. Instead of wasting time with cleaning up a pile of dirt, use that time to start supporting PolarSSL in all your applications. Its code is clean and it is well documented. Once you give PolarSSL a try, I'm sure you will wonder why the hell you were using OpenSSL all that time.

Re:PolarSSL

[Aethedor]

Hmm, placed the PolarSSL link at the wrong place. I hate it when you can't edit your post.

Re:PolarSSL

[Nightshade]

Yes, openssl is a piece of junk that is far too widely used. Polarssl looks nice and especially interesting is the version that was mathematically proven to be immune to a whole bunch of CWEs: http://trust-in-soft.com/polar...

But for OpenBSD they can't use polarssl since it's gnu licensed. The sad thing is polarssl was originally called xyssl and xyssl was originally BSD licensed. If only OpenBSD would start with the final xyssl codebase and replace OpenSSL with that...

OpenSSL for OpenBSD

[Anonymous Coward]

There's no doubt that OpenSSL needs work, but they seem to be needlessly combining actual security review with "break every platform that I don't like." At a minimum, anyone else trying to benefit from this will need to unravel the worthwhile security changes from the petty OS wars crap.

They are fixing OpenSSL for their own needs, probably with little or no expectation of use on other projects.

They did the same thing with SSH: they took the original SSH code, forked last open source copy before it went closed source, and created OpenSSH. Then a "portable" variant was created to run it on non-OpenBSD systems--which basically everyone else now runs.

I'm guessing the same will happen here: clean up the original and then at some point someone may make it portable.

Re:Backport\Upstream? Seems unlikely

[Anonymous Coward]

No you fool. "Do one thing and do it well". They're applying the tried and true Unix Philosophy. That's all this is about. Complexity Doesn't matter. It's the doing of the one thing, and wellness. Doing of all the things is the scourge of existence.

Get your priorities straight, or I'll beat you sensless with a lathered up POSIX roped soap, as it's the one thing a dirtyhippie can do with it well.

Re:Backport\Upstream? Seems unlikely

[Anonymous Coward]

It's a fork specifically for OpenBSD. Why would they keep support for other OSes?

You only fork when you want to put distance between the original; there is nothing stopping them from making changes/"improvements" to the original OpenSSL project except for scope constraint (i.e. if they just want OpenBSD to be secure) or ego. [...]

A third option: you feel the upstream folks are incompetent and don't want to bother with trying to get them to see your way.

I think it's a bit of #1 and #3.

Re:Backport\Upstream? Seems unlikely

[Anonymous Coward]

Surely some (back)porting will take place if those patches are useful for the original branch as well. The pursuit of code clarity(tm) is good when things get muddy and hearts are bleeding.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Theo has been critical?

[Anonymous Coward]

Doesn't matter, it's still his project. Donations to OpenSSL need to be donations to OpenBSD. Theo has ultimate responsibility for everything that happens with OpenSSL, including Heartbleed.

It's good that he's ordering a cleanup.

At the same time, the state of this critical infrastructure project under his control demonstrates how good at security he is far better than a thousand rants.

Re:Theo has been critical?

[Kalriath]

What are you rambling about? OpenSSL is not produced by the OpenBSD Foundation, it's produced by the OpenSSL foundation, a completely separate entity for which OpenBSD has no involvement at all. Sounds like you just saw the word "Open" and assumed they were connected... hint: they're not - an de Raadt has precisely no responsibility for whatever happens with the OpenSSL base tree.

Re:Theo has been critical?

[Anonymous Coward]

That's why he said forking in-house.

Where is reading comprehension hiding these days?

Re:Theo has been critical?

[Anonymous Coward]

So parent post was hiddin in the filter. Saw GP and Yours. Just wanted to apologize for being abrasive. I'm the ass.

Re:Theo has been critical?

[the_B0fh]

Are you even aware of the article you are reading? OpenBSD is forking OpenSSL and calling it LibreSSL.

OpenBSD is responsible for LibreSSL. Which will be in base for OpenBSD 5.6

Re:Theo has been critical?

[Kalriath]

Are you even aware of the post I was responding to? (Hint: the answer is clearly no. I suggest reading up before shooting off).

Assertion from post I replied to: "Theo has ultimate responsibility for everything that happens with OpenSSL, including Heartbleed"
Response from my post: "OpenBSD has nothing to do with OpenSSL, and [Theo] de Raadt has no responsibility for whatever happens with the OpenSSL base tree"

Give OpenSSH its own foundation then

[Anonymous Coward]

it's ridiculous to be forced to donate to OpenBSD if you want to support OpenSSH. OpenBSD is irrelevant, while OpenSSH is critical infrastructure.

We've been having this argument on Slashdot for over a decade.

By now, Theo has demonstrated through the state of the OpenSSH code that he is incompetent and can not be trusted to run the OpenSSH foundation.

Re:Give OpenSSH its own foundation then

[Kalriath]

What's wrong with the OpenSSH code? Are you foolishly conflating OpenSSH and OpenSSL, and claiming that de Raadt is somehow responsible for OpenSSL?

Re:Backport\Upstream? Seems unlikely

[s_p_oneil]

If they end up stripping it down to a minimal library with the core functionality, cleaning up the public interface (e.g. exported functions), and making it easy to create your own OS-specific wrapper around it, then they are actually doing something that should have been done in the first place. If they do it right, it will become much more popular (and most likely more light-weight and secure) than the current OpenSSL project.

Re:And they've already stopped

[Anonymous Coward]

Actions have consequences.

I follow the OpenBSD mailing lists on and off, and OpenBSD project members are raging assholes a lot of the time; this trickles down to users, as well (whether it's because they seek to emulate the project, or because non-assholes are driven away, I'm not sure).

This is a toxic environment that I have no desire to be part of, nor do I want to support it. I use OpenSSH frequently, but because there are such jerks associated with the project, I'd rather give money elsewhere. Someone else will pick up OpenSSH if OpenBSD dies.

In short: there are a lot of projects worth donating to. I have to sort them somehow, and OpenBSD helps me do that by slotting themselves near the bottom.

It's about time.

[Anonymous Coward]

They should clean up all the "Open" projects like OpenOffice and OpenWindows.

Theo de Raadt redeems himself

[jgotts]

I've not liked some of the things I've heard from Mr. de Raadt in the past because they seemed to be less fact than emotion, but in this case Theo has redeemed himself in a big way.

Like it or not, OpenSSL is now one of the most important pieces of software in the world. OpenSSL protects people's bank account numbers, credit card numbers, medical records, and employment records. OpenSSL protects corporate and government secrets (hopefully in combination with other defensive tactics). OpenSSL is not used for all encrypted network sockets, but it is widespread, to say the least.

de Raadt and his team are stripping OpenSSL down to its bare minimum. That is exactly what we all need. When someone's device creates an encrypted HTTP connection to another device, you want that functionality to work perfectly. That is the vast majority of use cases, and that most important use of OpenSSL failed in a spectacular fashion.

You don't care about being able to build OpenSSL on anything right now except OpenBSD. That is the platform de Raadt's team will be using for testing. You don't care about high-performance wrappers. Computers are lightning fast now, have gigantic amounts of memory, and network speeds are phenomenal compared to the requirements of using an HTTPS connection. OpenSSL today does not want for any system resource, even on a telephone or an embedded platform.

You don't need a platform on which to perform experiments in cryptography. OpenSSL was being used by scientists and mathematicians and the NSA to test new ideas. That is not an appropriate use for the mainline OpenSSL distribution.

Once de Raadt's team is finished, one or more of the hundreds of thousands of Windows programmers can spend a few weeks re-adding their build architecture and necessary wrappers for the latest versions of Windows and some Linux people can do the minor porting on that platform.

Perhaps the original OpenSSL can be relegated back to the laboratory. If you've ever used the OpenSSL command line programs, it feels like you're working with test tubes and bunsen burners. From what I've read of the code, it is no better.

Rights and Wrongs of good code.

[SuperTechnoNerd]

For starters I am by no means an expert in programming. I know enough to be dangerous, and to serve my own personal projects.
A while back a programmer friend of mine was guiding me in programming. Back then I wrote some C code, and in a error handling routine, I used the dreaded GOTO statement.
Boy did this unleash his complete wrath. He could talk about nothing else afterwards.
I was berated, screamed at, told I will never be a good programmer. I should give up now. GOTO's are the tools of a lazy ignorant and bad programmers. I am the worst programmer ever.. On and On. Any programmer that uses GOTO is a bad bad lazy programmer.
I then grepped through Linux kernel sources, and showed him that I found over 200 uses of GOTO's. He of course said they are not real programmers and they are just hacks, are lazy and stupid..... On and On...
So out of curiosity about the OpenSSL bug the other day, I looked at the sources, and low and behold, GOTO's everywhere.
I was shocked. Was this very important software written by hacks? Lazy, bad programmers? No wonder the serious security flaw..
Is GOTO the gold standard of a bad lazy programmer?
So I must ask you guys.. What's the deal? (needless to say I don't use them anymore :) )

Re:Rights and Wrongs of good code.

[thejynxed]

If you are using GOTOs and it isn't for a BASIC program running on old hardware (or in an emulator) for shits and giggles, yes, it's bad.

GOTOs are how you end up with endless loops (and other nasties). Do you want endless loops? Because that is how you get them.

Re:Rights and Wrongs of good code.

[petermgreen]

Your friend sounds like he has some serious anger management issues.

goto used sparingly can be a useful tool for breaking out of multiple layers of structures and going to an error handling block when an error happens in an inner loop and avoids adding loads of boilerplate to every layer of the nesting just to deal with error conditions. This is especially true in a language like C which does not have exceptions.

However care is needed to avoid jumping over things you didn't mean to jump over (like cleanup code) and over-use of goto can result in seriously unreadable spaghetti code. This makes some programmers anti-goto.

Re:Rights and Wrongs of good code.

[Xtifr]

Your friend is ignorant. Goto is a powerful-but-dangerous tool that should be used with extreme caution, if at all. However, to say that it's the mark of a bad programmer is insanely ignorant. It is often the mark of a bad programmer, but it can also be the mark of an exceptionally good one. The key is in knowing when you use it and when not to.

If your friend thinks he's a better programmer than Donald Knuth, then he's almost certainly suffering from the Dunning-Kruger effect. If he hasn't read Knuth's "Structured Programming with Gotos" (a direct response to Wirth's original "Goto Considered Harmful" paper), then he's not qualified to opine on the subject.

That said, probably 90% of the time (if not more), your friend will be correct. In the last over-a-decade, I've used goto once. And that lone case was after nearly a dozen attempts to find a way to around it that wasn't worse. I don't like gotos, and feel a little dirty that I ended up using it even that once. (If I'd been working in C++ or Java or Python, I would have used an exception, but I was writing in C.) A goto usually makes your code more difficult to read, and more fragile, and you should never use one unless you can prove the alternatives are worse. Which probably takes a lot more expertise than it sounds like you currently have, so avoiding them completely is probably the best plan for now. For you.

Re:Rights and Wrongs of good code.

[SuperTechnoNerd]

Your friend sounds like he has some serious anger management issues.

He does. He also considers himself the best programmer in the world, everyone one else are just insects to him. (no kidding).

Re:Rights and Wrongs of good code.

[Anonymous Coward]

how to avoid a goto

do
{
        DoStuff();
        if (error)
                break;
        return SUCCESS;
} while (0);
CleanUp();
return FAIL;

Re:Rights and Wrongs of good code.

[david_thornley]

GOTOs are tricky, and should only be used with strict discipline. A GOTO going to the end of a routine is fine, but one that goes backwards is likely to be confusing. If there's over 200 of them in the Linux kernel, that's few enough so they're likely well used. If the OpenSSL code has them everywhere, that's a bad sign.

Re:Rights and Wrongs of good code.

[Anonymous Coward]

This is an ironic suggestion. A "break" is nothing but a "goto" with a different name. If you have to choose between this obnoxious and hacky nonsense and a goto, then use a goto. The code and intent will be much clearer.

Re:Rights and Wrongs of good code.

[iggymanz]

wrong, goto can be used properly, the most secure and competent code on the planet has goto's. look at the source code of openssh, dozens of them

Re:And they've already stopped

[shallot]

You shouldn't really put OpenSSH and OpenNTPD in the same sentence... 2k http://qa.debian.org/popcon.ph... vs. 65k http://qa.debian.org/popcon.ph...

Re:And they've already stopped

[thoth]

Targeted donations are great and all, but I think corporations that NEED this security layer should step up. Banks for example - oh hell, the clearly don't give a crap if they can cry to Congress for a bailout.

If I were Zuckerburg, I'd go big and throw in 50 million for a rewrite effort. The publicity alone would be gold. Facebook could brag for years how they take their user's information and privacy seriously enough to pay. God, they already spent billions on a photo sharing app and VR glasses, 50 million would be round off in comparison.

Re:Backport\Upstream? Seems unlikely

[fuzzyfuzzyfungus]

I agree that ripping out platforms they don't care about is not the maximally altruistic path; but is the delta between the altruistic path and the more altruistic path really 'selfishness'? That just seems to strain the definition a bit...

Re:Backport\Upstream? Seems unlikely

[fuzzyfuzzyfungus]

They also just don't have much in the way of resources, so even things that are doable from a software engineering standpoint may well be impractical from an available man-hours standpoint, and pretty much anything is probably taking time away from some other aspect of OpenBSD development.

Absolute Rubbish

[Anonymous Coward]

You said: Here's the thing: OpenBSD is a hobby OS. Ha Ha.

That's funny. Some of the most prestigious companies and organizations on the planet use OpenBSD for a number of tasks. I've worked for three myself where OpenBSD figures prominently. Of the three I've worked for, one is the largest ISP in the US, another an IT consulting firm with a very specialized IT security knowledge whose clients demand only the very best, whose own infrastructure must be protected at all costs. OpenBSD is no joke, no hobbyist OS. BSD in general, while not getting anything near the popularity or mention of Linux, is far and away a better server choice than Linux in most areas, even more recently moving into the embedded space, especially OpenBSD and NetBSD. BSD is freaking stable. Short of a hardware failure, I've never had a BSD server go down for anything other than routine maintenance, and even this is infrequent.

OpenBSD isn't fancy, it's not pretty, it gets no real limelight, but it does an incredible job as a firewall, Webserver, gateway, you name it. Were I to run my own company, it would be BSD in the server room and Linux on the desktop. I've been working with and around BSD for the better part of 20 years. There is nothing hobby-like about it.

Re:Backport\Upstream? Seems unlikely

[Anonymous Coward]

Well, there's also nothing stopping OpenSSL from pulling in the changes made in OpenBSD. And they'd certainly better if any of them have any smarts at all.

Re:And they've already stopped

[mysidia]

$30,949 is how much the OpenBSD Foundation received in donations in 2013.

And yet... I heard OpenSSL itself gets at most $2000 in a typical year. Despite tens of thousands of banks, retailers, hardware manufacturers, software manufacturers, all relying on their code in a security critical fashion to support their business activities. The MOST the OpenSSL project gets in contributions is a mere shilling?

And no real support for high quality code review, maintenance, and release management. Just support for adding feature bloat.

Re:Backport\Upstream? Seems unlikely

[Anonymous Coward]

Because of supporting so many screwy platforms, they couldn't even rely on having malloc() work well. That means they had their own malloc implementation working from internal memory pools. Had they not, they would have benefited from the modern mmap() based implementations and you'd have got a segfault rather than a dump of the process memory.

At the very least they should have looked for a third-party one that's used at many other places (e.g., tcmalloc, jemalloc).

It's hard to be good at everything in the modern world: the OpenSSL folks should focus on security, and leverage the work of virtual memory experts where needed.

creating another OpenSSH?

[Anonymous Coward]

BSDs are estimated to be about 1.0% of all servers on the Internet (as of February 2014, sorry don't have current numbers), OpenBSD a portion of that, FreeBSD a bigger portion.

Hmm, how many folks are running Juniper? (They're running FreeBSD-based system.) Also: EMC Isilon and NetApp. Spectrum Logic? Who's running Force 10 (i.e., NetBSD)?

How many folks are running OpenSSH? How about using bcrypt?

If no one ends up using "OpenOpenSSL": oh well. But if the OpenBSD folks can fork OpenSSL (like they did with SSH) and turn it into another OpenSSH, then I say it's worth some encouragement.

Re:Backport\Upstream? Seems unlikely

[Anonymous Coward]

They didn't remove any current platforms, only obsolete ones, or code specific to some platform.

Re:Backport\Upstream? Seems unlikely

[Anonymous Coward]

> It's a fork specifically for OpenBSD. Why would they keep support for other OSes?

I don't think it is an OpenBSD fork. It is a cleanup, the resulting library will be available on every current system, like, say OpenSSH.

I expect the upstream library to die, and everyone will use the OpenBSD version.

Re:Backport\Upstream? Seems unlikely

[AmiMoJo]

The problem is that it isn't clear from Theo's statement if they are dropping support just for old platforms, or if they are dropping Win32/64 and MacOS support as well.

Re: valgrind

[cant_get_a_good_nick]

My tough guess here is something like valgrind would have helped. Yeah, even though you have the limits of true brk() allocation bundles, valgrind operates more at a byte level. Valgrind in this case would have been useless, because of the custom allocator code.

if you write code that requires a "caching" allocator so much that you break with normal malloc()/free(), you're doing something wrong. If you're doing it in high impact security code, you really should stop everything else and fix what you're doing wrong.

change is the constant

[mevets]

And thus another decade long slashdot argument turns out to be an elementary lexical oversight.

Re: Theo has a bad temper?

[DTentilhao]

"Yes, Theo has a bad temper and is not filtering carefully enough what he says, but his heart is in the right place, and he's a fucking great leader. I don't mind one bit his bad temper, because it usually hits those that really deserve it. And on the other hand, he's one of the most effective open source leaders."

That's called damning with faint praise :)

Rewrite it

[Anonymous Coward]

Seriously, just start over:

1. coherent API
2. modular code
3. discard obsolete / deprecated junk
4. profit!

Benefit for all

[manu0601]

When OpenBSD forked from NetBSD, they fixed many bugs, and fixes were backported in NetBSD. Fixing OpenSSL bugs will benefit everyone, if OpenSSL people are reasonable enough to tick the fixes.

Re:Backport\Upstream? Seems unlikely

[jrumney]

It's not remotely about petty OS wars. Complexity is bad for security, mmkay? If you want a newer version of openssl for OS/2, netware, or pre OSX MacOS, I'd really like to know what exactly you are doing. Dropping those platforms is the right thing.

You conveniently skipped Windows there.

I don't know the specifics of what was removed. Maybe it was only to support Windows 9x/ME, or NT 3.x or even Win16. But if it was needed for modern versions of Windows, then this is remotely about petty OS wars.

Re:And they've already stopped

[jrumney]

Banks don't use OpenSSL. They use FIPS certified alternatives. Look at the lists that have been produced of potentially compromised servers, and try to find a bank in there.

Re:Backport\Upstream? Seems unlikely

[Anonymous Coward]

It's easy to make petty comments while others are busy doing the work.

Re:Backport\Upstream? Seems unlikely

[chriscappuccio]

OpenSSL folks have recently said they are maxed out. And they have security problems sitting in their bug tracker for YEARS. What is the point?

Re:Backport\Upstream? Seems unlikely

[chriscappuccio]

It's a fork. And it will be usable by any modern unix variant, not just OpenBSD

Re:Backport\Upstream? Seems unlikely

[chriscappuccio]

The stuff that is being cut out isn't just for "other platforms". It's absolutely fucking ancient, and in many cases, probably hasn't even been _compiled_ any time in the last decade.

Re:And they've already stopped

[chriscappuccio]

Or about $900,000 less than OpenSSL receives in paid development work each year.

Re:And they've already stopped

[chriscappuccio]

And if they were using a FIPS certified version of OpenSSL, they would still be compromised. FIPS means....nothing in this context.

Just because no bank was on the list does NOT mean that they were not vulnerable, just that they have too much to lose by admitting it.

Re:And they've already stopped

[jrumney]

And if they were using a FIPS certified version of OpenSSL, they would still be compromised. FIPS means....nothing in this context.

OpenSSL is not FIPS certified. Most banks are using NSS, which is.

What the fuck?

[Sanians]

If your language runtime has a bug instead, it's much more likely to be a very indirect one, because now not only do you likely have to cause a specific behavior in the program itself, but that behavior has to trip up the runtime in a way that causes that bug to lead to something bad.

Yeah and? Has that stopped all the exploits of the Flash runtime and the Sun/Oracle JVM? Nope. In fact, those two are among the most exploited pieces of userspace software on the OS.

How the fuck can everyone misunderstand this? Every time this topic comes up, almost everyone fails to get it.

If you were writing programs in Flash or Java and those programs received data from the internet, those programs would be less exploitable because they were written in a high-level language. However, that's not what people usually do with Flash and Java. They use Flash and Java to run programs they've downloaded from the internet, which means they're left to the security of Flash and Java which are written in C.

Honestly, I don't know why I'm even trying. I'm 100% certain that everyone is going to entirely misunderstand what I've just said.

Look, people. Try to understand: These are two different concepts:

1. It's hard to exploit programs written in high-level languages like Flash and Java.
2. It's easy to exploit high-level language interpreters written in low-level languages like C.

I shall now prepare to be down-modded as a troll, as that seems to be the usual response to someone saying something that everyone else is so incapable of understanding that they assume they must simply be trying to cause an argument.

Re: valgrind

[bluefoxlucid]

Frama-C found it.

The caching allocator was irrelevant to the heartbleed bug.

Re:And they've already stopped

[TechnoJoe]

The community that depends on OpenSSH, OpenNTPD and the like needs to figure out how to support these projects.

Switch OpenBSD from the BSD license to GNU GPL v3. Make BSD licensing for donors only, with - of course - a restrictive clause that you can only use BSD licensing if you've donated. I'll admit it's an on-your-honor system, but it will scare most corporations.

GNU GPL v3 is free-enough for most people, and those who need free-er terms can pony up.

Re:Backport\Upstream? Seems unlikely

[david_thornley]

I'm perfectly cool with dropping MacOS support. If they make it not work on MacOSX, I'll be annoyed. There's a difference there, although it may not be obvious.

Re:Backport\Upstream? Seems unlikely

[hobarrera]

Dropping support for these platforms means getting rid of a lot of files/code/ifs/etc. Less code is easier to review. Better reviewed code has more chances of bugs being caught in time.

Re:Backport\Upstream? Seems unlikely

[hobarrera]

Looking at the diffs in tech@, is seems they're dropping DOS, WIN16 and WIN32. I've no idea if there was any WIN64 specific code, but yes, it seem's windows in general is being stripped.

Re:And they've already stopped

[iggymanz]

yes we can, they are both projects of The OpenBSD Project:

http://en.wikipedia.org/wiki/O...

Re: Theo has a bad temper?

[the_B0fh]

I don't see that as damning at all. I see that as a great leader.