Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OpenBSD Team Cleaning Up OpenSSL

timothy posted about 5 months ago | from the devil-you-say dept.

Security 304

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."

cancel ×

304 comments

Sorry! There are no comments related to the filter you selected.

de Raadt (4, Insightful)

Anonymous Coward | about 5 months ago | (#46757899)

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.

Backport\Upstream? Seems unlikely (4, Informative)

Anonymous Coward | about 5 months ago | (#46758121)

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.

"Ancient." "Cruft." (5, Insightful)

jabberw0k (62554) | about 5 months ago | (#46758363)

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." (4, Funny)

Razgorov Prikazka (1699498) | about 5 months ago | (#46758761)

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é)

While it may sound like that... (5, Insightful)

Anonymous Coward | about 5 months ago | (#46758381)

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 (4, Insightful)

gman003 (1693318) | about 5 months ago | (#46758403)

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 (2, Insightful)

jeffmeden (135043) | about 5 months ago | (#46758737)

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 (2)

MrBingoBoingo (3481277) | about 5 months ago | (#46759171)

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 (5, Insightful)

serviscope_minor (664417) | about 5 months ago | (#46759243)

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.

Re:Backport\Upstream? Seems unlikely (2, Insightful)

Anonymous Coward | about 5 months ago | (#46758409)

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 (2)

gweihir (88907) | about 5 months ago | (#46758607)

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.

Re:Backport\Upstream? Seems unlikely (1)

Anonymous Coward | about 5 months ago | (#46758503)

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 (4, Insightful)

dirtyhippie (259852) | about 5 months ago | (#46758525)

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 (1)

DMUTPeregrine (612791) | about 5 months ago | (#46758755)

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:Backport\Upstream? Seems unlikely (0)

Anonymous Coward | about 5 months ago | (#46758811)

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:Backport\Upstream? Seems unlikely (1)

MightyMartian (840721) | about 5 months ago | (#46759015)

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.

Re:de Raadt (5, Interesting)

bluefoxlucid (723572) | about 5 months ago | (#46758835)

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

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 [wikipedia.org] 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 (5, Informative)

EvanED (569694) | about 5 months ago | (#46758971)

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.

I'd love to hear his /. beta rant (0)

Anonymous Coward | about 5 months ago | (#46759073)

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?

I just donated (4, Funny)

Anonymous Coward | about 5 months ago | (#46757943)

I think my CC number got stolen.

Re:I just donated (-1)

Anonymous Coward | about 5 months ago | (#46758145)

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 (5, Funny)

Anonymous Coward | about 5 months ago | (#46758163)

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

Okay, Go! (0, Redundant)

xdor (1218206) | about 5 months ago | (#46757953)

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! (5, Informative)

Rigel47 (2991727) | about 5 months ago | (#46758019)

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! (4, Informative)

buchner.johannes (1139593) | about 5 months ago | (#46758047)

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 [openbsd.org]

Re:Okay, Go! (0)

LWATCDR (28044) | about 5 months ago | (#46758103)

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! (2)

Lunix Nutcase (1092239) | about 5 months ago | (#46758171)

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! (1)

Lunix Nutcase (1092239) | about 5 months ago | (#46758205)

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

Re:Okay, Go! (3, Informative)

xdor (1218206) | about 5 months ago | (#46758291)

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! (3, Interesting)

chill (34294) | about 5 months ago | (#46758181)

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 [openssh.com]

More power to them.

Re: Not 0.9.8 (1)

Anonymous Coward | about 5 months ago | (#46758659)

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.

Anyone know if there are regression tests? (2)

QilessQi (2044624) | about 5 months ago | (#46757957)

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? (0)

Anonymous Coward | about 5 months ago | (#46758147)

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? (4, Informative)

Em Adespoton (792954) | about 5 months ago | (#46758351)

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? (1)

Walter White (1573805) | about 5 months ago | (#46758247)

... 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? (1)

QilessQi (2044624) | about 5 months ago | (#46758583)

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? (1)

Zero__Kelvin (151819) | about 5 months ago | (#46758991)

"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 (4, Interesting)

bill_mcgonigle (4333) | about 5 months ago | (#46757985)

$30,949 is how much the OpenBSD Foundation received in donations in 2013. [openbsdfoundation.org] 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.

Re:And they've already stopped (4, Informative)

Anonymous Coward | about 5 months ago | (#46758285)

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 (3, Interesting)

Anonymous Coward | about 5 months ago | (#46758357)

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.

Re:And they've already stopped (1)

Anonymous Coward | about 5 months ago | (#46758775)

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:And they've already stopped (1)

Minwee (522556) | about 5 months ago | (#46758967)

$30,949 is how much the OpenBSD Foundation received in donations in 2013. [openbsdfoundation.org]

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.

What about a re-implementation... (-1, Troll)

FunkyELF (609131) | about 5 months ago | (#46757995)

... 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... (4, Insightful)

xfizik (3491039) | about 5 months ago | (#46758079)

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... (1, Insightful)

Anonymous Coward | about 5 months ago | (#46758275)

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... (5, Insightful)

Lunix Nutcase (1092239) | about 5 months ago | (#46758331)

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... (2)

EvanED (569694) | about 5 months ago | (#46758571)

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... (4, Insightful)

Lunix Nutcase (1092239) | about 5 months ago | (#46758655)

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... (2)

EvanED (569694) | about 5 months ago | (#46758789)

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... (1)

EvanED (569694) | about 5 months ago | (#46758917)

(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... (1)

Anonymous Coward | about 5 months ago | (#46758953)

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... (1)

ADRA (37398) | about 5 months ago | (#46759003)

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... (0)

Anonymous Coward | about 5 months ago | (#46759055)

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... (1)

Anonymous Coward | about 5 months ago | (#46759163)

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... (1, Troll)

Nutria (679911) | about 5 months ago | (#46758349)

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... (2)

Lunix Nutcase (1092239) | about 5 months ago | (#46758405)

And yet you'll trust languages implemented in it?

Re:What about a re-implementation... (-1)

Anonymous Coward | about 5 months ago | (#46758603)

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... (3, Informative)

Lunix Nutcase (1092239) | about 5 months ago | (#46758673)

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... (1)

Anonymous Coward | about 5 months ago | (#46758831)

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... (1)

gweihir (88907) | about 5 months ago | (#46758507)

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

Re:What about a re-implementation... (1)

Nutria (679911) | about 5 months ago | (#46759143)

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... (1)

dirtyhippie (259852) | about 5 months ago | (#46758559)

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... (1)

Desler (1608317) | about 5 months ago | (#46758127)

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... (1)

FunkyELF (609131) | about 5 months ago | (#46759251)

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... (1)

Anonymous Coward | about 5 months ago | (#46758143)

... 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... (0)

Anonymous Coward | about 5 months ago | (#46758155)

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

Re:What about a re-implementation... (0)

Anonymous Coward | about 5 months ago | (#46758157)

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... (4, Interesting)

cpghost (719344) | about 5 months ago | (#46758187)

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... (2)

Lunix Nutcase (1092239) | about 5 months ago | (#46758243)

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

Re:What about a re-implementation... (1)

Anonymous Coward | about 5 months ago | (#46758729)

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

Re:What about a re-implementation... (0)

Anonymous Coward | about 5 months ago | (#46758191)

How about Ada?

Re:What about a re-implementation... (1)

AnotherBlackHat (265897) | about 5 months ago | (#46758347)

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... (1)

EvanED (569694) | about 5 months ago | (#46758663)

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... (2)

gweihir (88907) | about 5 months ago | (#46758491)

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... (1)

EvanED (569694) | about 5 months ago | (#46758721)

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... (1)

Zero__Kelvin (151819) | about 5 months ago | (#46759103)

"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... (1)

bluefoxlucid (723572) | about 5 months ago | (#46758869)

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... (1)

QilessQi (2044624) | about 5 months ago | (#46758627)

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

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

Re:What about a re-implementation... (4, Informative)

QilessQi (2044624) | about 5 months ago | (#46758877)

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.

Wonderful! (1, Insightful)

cold fjord (826450) | about 5 months ago | (#46758017)

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

"Please Put OpenSSL Out of Its Misery" (5, Informative)

Anonymous Coward | about 5 months ago | (#46758023)

We also have a comment from the FreeBSD developer Poul-Henning Kamp [acm.org] .

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" (1)

Anonymous Coward | about 5 months ago | (#46758411)

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" (5, Informative)

Anonymous Coward | about 5 months ago | (#46758597)

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...

Right on. (4, Interesting)

PhrostyMcByte (589271) | about 5 months ago | (#46759259)

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:"Please Put OpenSSL Out of Its Misery" (2, Interesting)

Anonymous Coward | about 5 months ago | (#46758771)

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" (0)

Anonymous Coward | about 5 months ago | (#46758963)

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)?

Ted Unangst's article (4, Informative)

grub (11606) | about 5 months ago | (#46758065)


Ted Unangst wrote a good article called "analysis of openssl freelist reuse" [tedunangst.com]

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 (1)

grub (11606) | about 5 months ago | (#46758295)

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

Re:Ted Unangst's article (0)

Anonymous Coward | about 5 months ago | (#46759099)

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

Re:Ted Unangst's article (1)

MozeeToby (1163751) | about 5 months ago | (#46758929)

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.

Thanks! (-1)

Anonymous Coward | about 5 months ago | (#46758167)

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

Sent from my Windows 8 Phone.

Re:Thanks! (2)

the_povinator (936048) | about 5 months ago | (#46758399)

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

Re:Thanks! (0)

Anonymous Coward | about 5 months ago | (#46758705)

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! (5, Interesting)

TechyImmigrant (175943) | about 5 months ago | (#46758837)

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! (2)

Zero__Kelvin (151819) | about 5 months ago | (#46759245)

" 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! (1)

gweihir (88907) | about 5 months ago | (#46758569)

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! (0)

Anonymous Coward | about 5 months ago | (#46759157)

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).

Run! (1)

digitalPhant0m (1424687) | about 5 months ago | (#46758625)

The OpenBSD has started

The OpenBSD cometh.

OpenSSL OR... (3, Interesting)

higuita (129722) | about 5 months ago | (#46758643)

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... (-1)

Anonymous Coward | about 5 months ago | (#46759013)

The biggest problem is "GNU" in the name, scaring companies away.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>