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!

How To Prevent the Next Heartbleed

timothy posted about 4 months ago | from the leave-your-comment-in-the-form-of-an-exploit dept.

Security 231

dwheeler (321049) writes "Heartbleed was bad vulnerability in OpenSSL. My article How to Prevent the next Heartbleed explains why so many tools missed it... and what could be done to prevent the next one. Are there other ways to detect these vulnerabilities ahead-of-time? What did I miss?"

cancel ×

231 comments

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

How about (-1)

Anonymous Coward | about 4 months ago | (#46910949)

How about "Don't be stupid, you moron".

Re:How about (4, Informative)

zr (19885) | about 4 months ago | (#46910965)

about as effective as sunshine and puppies.

Re:How about (2)

DrPBacon (3044515) | about 4 months ago | (#46911733)

it's super effective.

Re:How about (1)

Anonymous Coward | about 4 months ago | (#46910975)

If someone is a moron, they can't help but be stupid.

Re:How about (2, Insightful)

gnupun (752725) | about 4 months ago | (#46911071)

Don't use C and its variants like C++. C is an extremely unsafe, low-level language that is just one step above assembly language. This makes it great for low-level, performance sensitive programs like OSes, compilers, etc. but the low-levelness also increases bug count for general purpose applications.

Instead use safer languages like Pascal, Eiffel (design by contract), Ada, etc. These languages guard against buffer overflows and don't have the slowness and bloat associated with garbage collected languages like Java and .NET, but are much safer than C. The problem usually is, few people know these languages and they are not portable from one platform to another.

Re:How about (0)

Anonymous Coward | about 4 months ago | (#46911109)

Instead use safer languages like Pascal, Eiffel (design by contract), Ada, etc.

Yes, I agree. And as mentioned in the article, Rust [rust-lang.org] is a good choice here too, or will be once it gets to version 1.0. I think the plan is for Rust to get version 1.0 this year.

Re:How about (2, Insightful)

Anonymous Coward | about 4 months ago | (#46911165)

Yeah, we'll just rewrite the Internet in Pascal.

Libraries like OpenSSL are built in C in no small part because C can easily be linked into just about any other language out there. Nothing is going to change that.

And idiots can write bad code in any language. It might not be a buffer overflow, but they could still have screwed up in many other ways.

Re:How about (0)

Anonymous Coward | about 4 months ago | (#46911267)

Yeah, we'll just rewrite the Internet in Pascal.

It can be done, regardless of naysayers like you. GNU rewrote Unix, the Internet can be rewritten too. Better get started.

Re:How about (0)

Anonymous Coward | about 4 months ago | (#46911413)

GNU rewrote Unix

In C. Not Pascal.

Re:How about (2, Insightful)

Anonymous Coward | about 4 months ago | (#46911177)

Or you just learn how to code properly. This particular vulnerability wasn't because there was a mistake, it was because they opted to bypass a function that was meant to keep people safe. It's a bit like bolting the fire escapes closed then wondering why everybody died after the fire.

It's astonishing to me that somebody would put code into a production environment that asked for a certain length of response without bothering to do any validation.

Re:How about (2)

gnupun (752725) | about 4 months ago | (#46911205)

Or you just learn how to code properly.

If that really worked, there would be no QA dept. for software. Unless you can formally prove your software is correct, you should assume there are bugs. And no one has the time, money or ability to formally prove hundreds of millions of lines of code.

It's astonishing to me that somebody would put code into a production environment that asked for a certain length of response without bothering to do any validation.

And even more astonishing the head maintainer and merger did not review this change and ask the developer to fix it.

Re:How about (2, Insightful)

socode (703891) | about 4 months ago | (#46911343)

> If that really worked, there would be no QA dept. for software.
No, that's just poor reasoning.

Quality must be built-in, not added-on. QA expectations and improvement scope are largely imposed on any QA department, therefore the level of 'quality' reached can never be an absolute bar.

Developers in general need to minimise the vector product of bug count/severity that could be exposed before it gets to QA. This allows the bar to be raised, and focus to be spent on where it should be rather than catching obvious mistakes, or dealing with unnecessary performance/cognitive/configuration complexity.

Re:How about (1)

ComputersKai (3499237) | about 4 months ago | (#46911351)

Keep in mind that this is an Open Source project, and the developers don't have access to all of the resources that corporations tout around.

Re:How about (1)

Jeremi (14640) | about 4 months ago | (#46911199)

Instead use safer languages like Pascal, Eiffel (design by contract), Ada, etc. [...] The problem usually is, few people know these languages and they are not portable from one platform to another.

Agreed regarding both the solution and the problem with the solution.

It's probably reasonable to use [insert-super-secure-machine-verifiable-language-here] to develop libraries that are as security-critical as OpenSSL. However, it's unlikely that such libraries will be widely used if they aren't easily callable from the more popular languages (C/C++/ObjectiveC/etc).

Given that, I wonder how difficult it would be to write a library in (e.g.) Ada, but have the Ada compiler compile the code in such a way that the outputs is a C library file and C header files for the library's public API? That could give us a way to have our cake and eat it, too.

Re: How about (1)

Anonymous Coward | about 4 months ago | (#46911217)

Eiffel compiles to C. Pascal can compile to C (I think k that Linux Pascal 'compiler' is just a translator to C and gcc)

Re:How about (2)

gnupun (752725) | about 4 months ago | (#46911257)

I'm not sure you can auto-generate a C header file but you can create a library (.dll or .o) file from Ada source and call it from C. You have to hand generate the C header file.

Create DLL library in Ada [stackoverflow.com]

Re:How about (1)

Anonymous Coward | about 4 months ago | (#46911293)

It is a process problem, and your solution is to ban the use of screws, replacing:
1 "make a critical library written defensively and correctly, removing any cruft, and adhering to good processes"
with
2 "build an entire cross-platform compiler/runtime with no flaws that does that for you"

Re:How about (4, Funny)

Kazoo the Clown (644526) | about 4 months ago | (#46911307)

Yes, I think it's clear the next gen of CPUs really needs to have the machine language removed entirely. What a security hole!

Re:How about (1)

Anonymous Coward | about 4 months ago | (#46911535)

Going forward, all CPUs shall be required to execute Java bytecode natively.

Re:How about (1)

ColdGrits (204506) | about 4 months ago | (#46911679)

Going forward, all CPUs shall be required to execute Java bytecode natively.

Well there was the PicoJava [wikipedia.org] from Sun.
Or the MAJC [wikipedia.org] from Sun

Both of which did exactly that.

Alas none are around any more...

Re: How about (0)

Anonymous Coward | about 4 months ago | (#46911331)

How can you write general purpose libraries in c#? It will only run on windows. Java runs on more things. But what about their interpreters what are they written in?

Re:How about (4, Informative)

Dahamma (304068) | about 4 months ago | (#46911389)

I have personally ported OpenSSL to at least 6 embedded systems, one of which was so proprietary they wrote their own C/C++ compiler. Good luck finding an Ada compiler for that.

his makes it great for low-level, performance sensitive programs like OSes, compilers,

Aaand... performance sensitive like, say... crypto? There isn't much code more performance sensitive than crypto libraries, which is one of OpenSSL's main uses. In fact, there are a whole bunch of native assembler implementations for x86, MIPS, ARM, PPC, etc to achieve that low level performance. Clearly you have never actually looked at the OpenSSL code base...

Re:How about (0)

Anonymous Coward | about 4 months ago | (#46911747)

I have personally ported OpenSSL to at least 6 embedded systems, one of which was so proprietary they wrote their own C/C++ compiler. Good luck finding an Ada compiler for that.

his makes it great for low-level, performance sensitive programs like OSes, compilers,

Aaand... performance sensitive like, say... crypto? There isn't much code more performance sensitive than crypto libraries, which is one of OpenSSL's main uses. In fact, there are a whole bunch of native assembler implementations for x86, MIPS, ARM, PPC, etc to achieve that low level performance. Clearly you have never actually looked at the OpenSSL code base...

Performance sensitive? really? most crypto is NOT performance sensitive at all and you could easily sacrifice some performance for more secure/reviewed code. I would imagine there are very few mostly fringe cases where the performance is more critical in which cases they should be uses modified versions not having hacks put into the main code stream.

Re:How about (3, Interesting)

Artifakt (700173) | about 4 months ago | (#46911401)

The US Army will swear that I was once, many moons ago, officially certified in Ada, whether that means anything or not. I never liked it much, even though I did turn in successful code a few times, and I really have a problem with Ada for open source applications - Yes, in theory, Ada has some very strong security functions by design, but it's definitely not going to result in the 'many eyes make all bugs shallow' effect. I actually read your post as deliberately tongue in cheek at first, what with phrases such as 'extremely unsafe'.
        But as I think more about it, one of the problems revealed by Heartbleed is open sourcing the target code didn't result in a lot of properly trained eyes passing over that code. I never thought I'd encourage anyone to learn Ada after I got out of the service (just as I never thought I'd encourage anyone to start a cult worshipping many-tentacled, eldritch, blasphemous horrors from beyond space-time as we delusionally try to limit our conceptions of it to preserve our fundamental human sanity, and for much the same reasons), but I have to admit, you may have a damned good argument for Ada there.I don't know if the extensive compile time checking of Ada 2012 could have automatically caught the bug that made Heartbleed possible - the last version of Ada I've really used is 95, but I'd be really interested to hear from someone who's current if they think Ada is just about totally bulletproof against this sort of bug, because even the older versions I recall had some features that would have made it hard to make this sort of mistake.

Re:How about (0)

Anonymous Coward | about 4 months ago | (#46911547)

I really have a problem with Ada for open source applications - Yes, in theory, Ada has some very strong security functions by design, but it's definitely not going to result in the 'many eyes make all bugs shallow' effect.

No one ever reads open source code. It's just some free stuff that naive neckbeards wrote for you, that you can compile and use for free, because it's free!! If no one ever reads the code, who cares what language it's written in?

Re:How about (2)

phantomfive (622387) | about 4 months ago | (#46911633)

But as I think more about it, one of the problems revealed by Heartbleed is open sourcing the target code didn't result in a lot of properly trained eyes passing over that code.

My experience is that reading code isn't a very good way to catch bugs, mainly because reviewers tend not to read it as carefully as the person who wrote it. If you want to find bugs, it's more effective to do white/black box testing of some sort.

Re:How about (2)

phantomfive (622387) | about 4 months ago | (#46911625)

My experience is that people who trust in their language to keep their code bug free inevitably have more bugs in their code. It's amazing how many memory leaks I've found in Java, by programmers who swore such things were impossible. Another entertaining situation is people who manage to get around deadlock detection by creating live-locks.

I think it's clear to everyone who's actually looked at the situation that the problem here wasn't the language, it was the people who were using the language. They would have written bad code in any language.

Re:How about (0)

Anonymous Coward | about 4 months ago | (#46911649)

Don't use C and its variants like C++. C is an extremely unsafe, low-level language that is just one step above assembly language.

That's like saying we shouldn't use nuts and bolts to build things and instead only use Legos, since they're "safer".

The problem wasn't the language, it was the fact that there were less than a half dozen people actually working on the software, and only one of them could even remotely be classified as a full-time worker. It's incredibly common to miss your own mistakes, especially when the code works properly when tested and widely used.
What is needed are more eyes actually reviewing the project and performing QA and testing on it, instead of just assuming that it was working properly. Part of the problem is that Crypto is Hard, and many people have a tendency to assume that the bits of code which seem wrong or out of place are actually working properly, and that it's their own understanding which is in error.

Re: How about (0)

Anonymous Coward | about 4 months ago | (#46911743)

I am surprised that D language was not mentioned.

http://dlang.org/

Static analysis (3, Insightful)

Anonymous Coward | about 4 months ago | (#46910963)

It could have been discovered with static analysis if anyone had the foresight to implement a specific check ahead of time (although it's unknown whether anyone could have thought of checking this specific case before Heartbleed was discovered):

http://blog.trailofbits.com/2014/04/27/using-static-analysis-and-clang-to-find-heartbleed/

Re:Static analysis (4, Informative)

Krishnoid (984597) | about 4 months ago | (#46911359)

Coverity has a blog post [coverity.com] describing the problem and why their static analysis methods currently can't detect it.

Re:Static analysis (3, Interesting)

arth1 (260657) | about 4 months ago | (#46911391)

OpenSSL was static analyzed with Coverity. However, Coverity did not discover this, as is a parametric bug, which depends on variable content.

The reaction from Coverity was to issue a patch to find this kind of problem, but in my opinion, the "fix" throws the baby out with the bath water. The fix causes all byte swaps to mark the content as tainted. Which surely would have detected this bug, but it also leads to an enormous amount of false positives for development where swabs are common, like cross- or multi-platform development.
And while it finds "defects" this way, it's not the real problem it finds.
So in my opinion, 0 out of 10 points to Coverity for this knee-jerk reaction.

In my opinion, what's wrong here is someone with a high level language background submitting patches in a lower level language than what he's used to. The problems that can cause are never going to be 100% (or even 50%) caught by static analysis. Lower level languages does give you enough rope to hang yourself with. It's the nature of the beast. In return, you have more control over the details of what you do. That you're allowed to do something stupid also means you are allowed to do something brilliant.
But it requires far more discipline - you cannot make assumptions, but have to actually understand what is done to variables at a low level.
Unit tests and fuzzing helps. But even that is no substitute for thinking low level when using a low level language.

Re:Static analysis (1)

Z00L00K (682162) | about 4 months ago | (#46911595)

There are also other statical analysis tools like splint [splint.org] . The catch is that it produces a large volume of data which is tedious to sift through, but once done you will have found the majority of the bugs in your code.

However the root cause is that the language itself permits illegal and bad constructs. It's of course a performance trade-off, but by coding part of the code in a high level language and leave the performance critical parts to a low level may lower the exposure and force focus on the problems to a certain limited area.

A secondary cause is that if you write code - write it as clean as possible and broken down into pieces. If coding C there's always the option of declaring a function as "static inline" to tell the compiler that what you do is going to get right into the execution flow because you know that it will improve performance.

Dynamic analysis is also good - like Valgrind [valgrind.org] , but they have shortcomings. Just be aware that fuzzing can confuse dynamic analysis tools as well producing inconsistent results, which means that for the initial tests you need to be able to turn off fuzzing to get rid of the consistent problems.

Re:Static analysis (0)

Anonymous Coward | about 4 months ago | (#46911685)

However the root cause is that the language itself permits illegal and bad constructs. It's of course a performance trade-off, but by coding part of the code in a high level language and leave the performance critical parts to a low level may lower the exposure and force focus on the problems to a certain limited area.

I have two points. Modern processors tend to be unsafe, though some features have been grudgingly, like adding non execute flags for stacks. So at some point, you're going to transition from your nice safe higher level language to unsafe binary code. Also you can write a security hole in any language. Can you think of any way to prevent cache timing attacks in JavaScript? Didn't think so. You can in C.

Second point, in safety critical industries there is a rule, you need to have at least two, sometimes three things 'go wrong' before someone dies. In the case of heart bleed the maintainers intentionally disabled the bounds checking in fucking malloc(3) that is designed specifically to prevent this shit. That is the root cause of heart bleed. It's like the maintenance guy 'fixing' a breaker that 'always blows' but installing a bigger one, then blaming the tard that plugged a heater, coffee pot and a hair drier into the same circuit for the building catching fire. And unlike the buffer 'over read' the maintainers knew their bastard version of malloc was unsafe.

Aw, come on. (0)

cephalien (529516) | about 4 months ago | (#46910983)

Did anyone edit this? 'was bad vulnerability'?

Jeebus. Have some integrity.

Re:Aw, come on. (0)

Anonymous Coward | about 4 months ago | (#46911007)

Are yew knew hear? Slashdot does knot halve any sew called (editors)

Re:Aw, come on. (0)

Anonymous Coward | about 4 months ago | (#46911079)

I'm pretty sure they intended "waz bad 'nerbility". But Lolcat is a dying language, so you must applaud even poor attempts.

Re:Aw, come on. (1)

cephalien (529516) | about 4 months ago | (#46911195)

My ID is hardly 'new', but this place has surely gone downhill. :(

Re:Aw, come on. (1)

jones_supa (887896) | about 4 months ago | (#46911643)

I think that sometimes too, but when I actually go back and browse the old articles, it's mostly the same stuff.

How about psychics? (1)

Anonymous Coward | about 4 months ago | (#46911039)

Or remote viewing? Or, more scientific, maybe put a bounty on big bugs that we'll pay time travelers from the future to tell us about?

In the US: force the NSA to disclose them (1, Interesting)

Anonymous Coward | about 4 months ago | (#46911055)

If you want to find the next one and are in the US, force your broken government to disclose the ones they're already using on civilian targets (both in the US and abroad).

Re:In the US: force the NSA to disclose them (0)

Anonymous Coward | about 4 months ago | (#46911259)

Good luck with that. You sound like a liberal heart-bleeder.

Re:In the US: force the NSA to disclose them (0, Funny)

Anonymous Coward | about 4 months ago | (#46911283)

Exactly. The Republicans that create these bugs will never allow them to be disclosed by the government. There's a reason Republicans still push so hard for C and only C to be used for projects.

Re: Republicans (2)

Fwipp (1473271) | about 4 months ago | (#46911319)

I have no idea why you're maintaining that "Republicans" create these bugs, and I'm, like, a socialist.

Re:In the US: force the NSA to disclose them (1)

ComputersKai (3499237) | about 4 months ago | (#46911365)

First of all, what do Republicans have to do with C, the language UNIX was originally written in, and next, the problem was that the NSA would have thrown up some half-baked excuse in doublespeak about how they wouldn't be able to gather "intelligence" properly. That being said, the NSA has made several good contributions to computer security, but it still probably isn't that much of a good idea to trust the agency doing crypto-breaking with overseeing security standards.

Picard and his cute blanket (-1)

Anonymous Coward | about 4 months ago | (#46911061)

need to get over the "cult of macho programming" (3, Insightful)

Anonymous Coward | about 4 months ago | (#46911063)

Every industry goes through this. At one point it was aviation, and the "hot shot pilot" was the Real Deal. But then they figured out that even the Hottest Shot pilots are human and sometimes forget something critical and people die, so now, pilots use checklists all the time for safety. No matter how awesome they might be, they can have a bad day, etc. And this is also why we have two pilots in commercial aviation, to cross check each other.

In programming something as critical as SSL it's long past time for "macho programming culture" to die. First off, it needs many eyes checking. Second, there needs to be an emphasis on using languages that are not susceptible to buffer overrunning. This isn't 1975 any more. No matter how macho the programmer thinks s/he is, s/he is only human and WILL make mistakes like this. We need better tools and technologies to move the industry forward.

Last, in other engineering professions there is licensing and engineers are held accountable for mistakes they make. Maybe we don't need that for some $2 phone app, but for critical infrastructure it is also past time, and programmers need to start being held accountable for the quality of their work.

It's things the "brogrammer" culture will complain BITTERLY about, their precious playground being held to professional standards. But it's the only way forward. It isn't the wild west any more. The world depends on technology and we need to improve the quality and the processes behind it.

Yes, I'm prepared to be modded down by those cowboy programmers who don't want to be accountable for the results of their poor techniques... But that is exactly the way of thinking that our industry needs to shed.

engineering professions have power over PHB's (0)

Joe_Dragon (2206452) | about 4 months ago | (#46911133)

issues

like lack of QA / testing

deadline that lead to cut corners.

having sales people over promise and more.

can be put on the PHB and without some kind professions there is licensing system they can say you can do it or we can find an H1b who can (at least on paper)

Re:need to get over the "cult of macho programming (5, Insightful)

MoonlessNights (3526789) | about 4 months ago | (#46911143)

The problem has more to do with the "hey, this is free so lets just take it" attitude of the downstream consumers not willing to pay for anyone to look at the code or pay anyone to write it.

Why would you want the OpenSSL people to be held accountable for something they basically just wrote on their own time since nobody else bothered?

Striking out to solve a problem should NOT be punished (that culture of legal punishment for being useful is part of why knowledge industries are leaving North America).

This problem was caused by a simple missed parameter check, nothing more. Stop acting like the cultural problem is with the developers when it is with the leaches who consumer their work.

Re:need to get over the "cult of macho programming (0)

Anonymous Coward | about 4 months ago | (#46911207)

This was not a "hangman" game, this was a critical security package. If you can't be bothered to check parameters you shouldn't be working on security projects.

Re:need to get over the "cult of macho programming (0)

Anonymous Coward | about 4 months ago | (#46911387)

Clearly there weren't any programmers of that quality bothering to work on OpenSSL for free.

That's why many people use alternatives to OpenSSL.

Re: need to get over the "cult of macho programmin (0)

Anonymous Coward | about 4 months ago | (#46911399)

Don't you mean if it not a hangman app don't get free code from the Internet?
That is not the answer or there would be no FOSS.
It is the issue of who works on the boring stuff.

Re:need to get over the "cult of macho programming (1)

MouseTheLuckyDog (2752443) | about 4 months ago | (#46911523)

If you are worried about security don't use software written by people who can't be bothered to check parameters.

Re:need to get over the "cult of macho programming (1)

BiIl_the_Engineer (3618863) | about 4 months ago | (#46911745)

Don't use software at all, then.

Re:need to get over the "cult of macho programming (0)

Anonymous Coward | about 4 months ago | (#46911681)

This was not a "hangman" game, this was a critical security package. If you can't be bothered to check parameters you shouldn't be working on security projects.

No, it was a free piece of software with no guarantees which was not tested nor rated as acceptable for high-risk use. Others chose to use that software as part of various critical security applications, but completely failed to validate that the software they used was in reality up to the task.

This wasn't a company paying people to write secure code. It was a few volunteers, only one of which was even what you could consider 'full-time'. Meanwhile, thousands of high-profit companies couldn't be bothered to help them out with the project, so if you've got anyone to bitch at, go bitch at every for-profit company who used it and utterly failed to give anything back.

Re:need to get over the "cult of macho programming (2)

Ckwop (707653) | about 4 months ago | (#46911721)

I actually agree with both of you. The Open SSL guys gave out their work for free for anybody to use. Anybody should be free to do that without repercussions. Code is a kind of literature and thus should be protected by free speech laws.

However, if you pay peanuts (or nothing at all) then likewise you shouldn't expect anything other than monkeys. The real fault here is big business using unverified (in the sense of correctness!) source for security critical components of their system.

If regulation is needed anywhere, it is there. People who develop safety and security critical stuff should be certified and businesses with a turn over $x million dollars should be required to use software developed only by the approved organisations.

There is nothing in this definition that prevents an open source implementation. In fact, there's an argument to say that any such verified implementation must be open source precisely so it can be inspected. But it is quite a lot of work and people need to be paid to do that work. You can't expect to get this level of quality assurance for free.

Re:need to get over the "cult of macho programming (0)

Anonymous Coward | about 4 months ago | (#46911179)

The only problem with doing this is you'd have to convince congress to actually punish companies that don't hold up to professional standards when applications get broken into for simple stuff. As is with our government, the Brooklyn bridge could cave into the bay killing 10,000+ people, and everyone would point to each other and it'd be the "system" that would be broken warranting new wonderful scummy laws that funnel billions out of your and my pockets into some ass hat politicians back pocket.

Re:need to get over the "cult of macho programming (0)

Anonymous Coward | about 4 months ago | (#46911181)

"Yes, I'm prepared to be modded down"

as you wish! wtf is with these insecure posts?

i'll burn karma (lots of karma given) posting this. hey, aww you guys!

i'll be modded down for this

posts don't need this useless ego driven filler.

Re:need to get over the "cult of macho programming (1)

blue trane (110704) | about 4 months ago | (#46911295)

It was reverse psychology.

Re:need to get over the "cult of macho programming (1)

jones_supa (887896) | about 4 months ago | (#46911647)

Yep. It's a thing you include to guarantee your post to be modded up. ;)

Re:need to get over the "cult of macho programming (0)

Anonymous Coward | about 4 months ago | (#46911231)

No. I will agree, however, that any software that is to be used in critical operations by an organization should be verified by that organisation. If the organisation are responsible for maintaining and operating a system that integrates with others outside their control the method and criteria for validation should be public.

There is no need to certify programmers for this. It is the USE of an implementation that should be validated not the CREATION of that which is implemented.

Pilots verify that their tools and equipment function as advertised and show values within tolerance levels. They do not verify that the engineers who built the plane where certified.

Re:need to get over the "cult of macho programming (1)

jhol13 (1087781) | about 4 months ago | (#46911303)

You forgot NIH. OpenSSL used its own allocator, the most positive thing I can say about that is "totally idiotic". AFAIK nobody is removing it ...

Furthermore, C is insufficient language for a security software (C++ when properly used barely acceptable, managed languages much better).

Re:need to get over the "cult of macho programming (0)

Anonymous Coward | about 4 months ago | (#46911309)

You don't know what you're talking about. Do you have any idea how much money was invested in OpenSSL last year? $2k [google.com] . That's not a typo, they received two hundred dollars. If the volunteers responsible for openSSL, a world-class product, were held accountable for bugs they would have no choice but to ditch the project. You want accountability, you pay for it. No, $2k won't cut it.

Get down your high horse, they're not your slaves. People work for free and you think you can tell them how they're supposed to do it. Either do better or shut up and let others work in peace. The OpenBSD guys have the right attitude. They saw OpenSSL sucked and got their hands dirty to fix it. What have you done to address the problem?

Re:need to get over the "cult of macho programming (1)

Anonymous Coward | about 4 months ago | (#46911363)

$2k [google.com] . That's not a typo, they received two hundred dollars.

DOES NOT COMPUTE

Re:need to get over the "cult of macho programming (0)

Anonymous Coward | about 4 months ago | (#46911577)

$2k [google.com] . That's not a typo, they received two hundred dollars.

DOES NOT COMPUTE

Obviously shoddy work, not enough "eyes" looking at it from a QA perspective.

Re:need to get over the "cult of macho programming (2)

Mike Sheen (1155353) | about 4 months ago | (#46911683)

I saw that a week ago, so I donated $50 USD to the OpenSSL Software Foundation. I figured I would either whine about the problem, or do something. I chose the latter.

Re:need to get over the "cult of macho programming (0)

Alomex (148003) | about 4 months ago | (#46911311)

Second, there needs to be an emphasis on using languages that are not susceptible to buffer overrunning. This isn't 1975 any more.

This. It is high time that by default C compilers did buffer overrun check. Maybe deep inside some kernel routine we cannot afford the 0.5nanosecond it takes to check the buffer size, and we can always have a pragma that disables the checking for that piece of code. All other usages should be subject to buffer overrun check.

Re:need to get over the "cult of macho programming (0)

Anonymous Coward | about 4 months ago | (#46911437)

How do you propose that the compiler performs this check when it has no idea as to the size of the buffer?

The problem is with the language, not with any given implementation.

Re:need to get over the "cult of macho programming (1)

jones_supa (887896) | about 4 months ago | (#46911653)

Then we have to go one step further and store the size of the buffer.

In general, a "hardened C" programming language would be an excellent idea in my opinion.

Re:need to get over the "cult of macho programming (1)

mitzampt (2002856) | about 4 months ago | (#46911533)

Unless you are trying to switch to pascal-style strings instead of null-terminated ones you have limited ways to automatically check buffer overruns, just as you have limited ways to do garbage collecting or, for that matter, almost anything automagical with pointers. The compiler alone cannot enforce that policy, one could try to enforce it in the standard library or a framework. The difference between low and middle level languages and high level languages is the magic that happens behind the language. C has almost no magic, it just gives you the building blocks to do whatever you please.

Re: need to get over the "cult of macho programmin (0)

Anonymous Coward | about 4 months ago | (#46911597)

Nothing in the C language precludes checking array bounds. There are plenty of implementations that used tagged pointers, or instrument code to lookup the bounds of an automatic array or malloc pointer.

But few people use them because they're slower.

Re: need to get over the "cult of macho programmin (1)

jones_supa (887896) | about 4 months ago | (#46911659)

We have fast computers. Why not sacrifice some of it to security? I mean, we are still probably not talking about 50-time slowdowns, like when you run a program under Valgrind.

Re: need to get over the "cult of macho programmi (0)

Anonymous Coward | about 4 months ago | (#46911707)

We're moving in that direction. Intel is adding bounds checking instructions to the Skylake ISA called MPX. The compiler will keep some shadow memory populated with the bounds of pointers and arrays, and insert MPX instructions to check loads and stores.

Clang and GCC now both have AddressSanitizer, which does the same thing in pure software.

So there's nothing inherently unsafe about C. Its just that most implementations haven't bothered to deal with the problem.

Also, the Heartbleed over-read could have happened in Java. Plenty of high-performance Java projects use buffer pools that look identical to what OpenSSL was doing. They do it to cut down on garbage churn.

Re: need to get over the "cult of macho programmin (0)

Anonymous Coward | about 4 months ago | (#46911723)

We have fast computers. Why not sacrifice some of it to security? I mean, we are still probably not talking about 50-time slowdowns, like when you run a program under Valgrind.

The irony is that you're already sacrificing it to security in C if you're doing it right; every bounds check that you have to add manually slows things down _at least as much_ as the bounds checking done in higher-level languages.

C/C++ aren't magical speed-demons, they get their speed through a trade-off and a horrible one at that. The sooner people realize this the better.

Re:need to get over the "cult of macho programming (0)

Anonymous Coward | about 4 months ago | (#46911769)

If you want a language that checks for buffer overruns you use a language that checks for buffer overruns. Or when you want to fly somewhere you strap wings on your car instead of taking a plane?

Re:need to get over the "cult of macho programming (0)

Anonymous Coward | about 4 months ago | (#46911325)

Do you think any brogrammers work on SSL? Do you think they're actively warding off peer review? In short: do you have evidence that the engineering culture behind openSSL caused the failure, rather than the obvious complete lack of revenue, funding and active contributors?

And if so, does this same culture simultanesously affect gnuTLS, LibreSSL, and Apple?

Re:need to get over the "cult of macho programming (2)

socode (703891) | about 4 months ago | (#46911357)

> programmers need to start being held accountable for the quality of their work.
They are.

But I guess you mean that people who aren't paying for your work, and companies which aren't paying for the processes and professional services necessary for some level of quality, should hold programmers who don't have any kind of engineering or financial relationship with them accountable.

Re:need to get over the "cult of macho programming (1)

phantomfive (622387) | about 4 months ago | (#46911397)

In programming something as critical as SSL it's long past time for "macho programming culture" to die.

Yeah, but it's kind of going the other way, with more and more companies going to continuous deployment. Facebook is just pit of bugs.

programmers need to start being held accountable for the quality of their work.

OK, I'm with you that quality needs to improve, but if I have a choice between working where I get punished for my bugs and where I don't; I'm working for a place where I don't get punished for my bugs. I test my code carefully but sometimes they slip through anyway.

Re:need to get over the "cult of macho programming (0)

Anonymous Coward | about 4 months ago | (#46911467)

all well and good.... and i agree to some extent, but you know what it was the gung ho ones that pioneered it and the wusses looking for a reliable paycheck that regulated the living hell out of it..... at which point innovation completely dies.

Re:need to get over the "cult of macho programming (0)

Anonymous Coward | about 4 months ago | (#46911505)

In programming something as critical as SSL it's long past time for "macho programming culture" to die. First off, it needs many eyes checking. Second, there needs to be an emphasis on using languages that are not susceptible to buffer overrunning. This isn't 1975 any more. No matter how macho the programmer thinks s/he is, s/he is only human and WILL make mistakes like this. We need better tools and technologies to move the industry forward.

Your post should be modded down, it is a repetitive theme...But that's not your fault, how many articles is /. going to post that are repetitive? Your comment was already posted once in a /. story and yet they keep posting echo articles from programmers/critics who somehow think their geniuses for pointing out the obvious problems with open source projects.

Wheres Linus Torvalds in all this? I was hoping to read or hear his thoughts over this, would be even better if he did video self-interviews .. The guy is brilliant and priceless!

Not really (3, Insightful)

NapalmV (1934294) | about 4 months ago | (#46911097)

Let's remember the good old bug that plagued (and probably still does) many libraries that read graphic files such as TIFF. The classic scenario was that the programmer was reading the expected image size from the TIFF file header, allocated memory for this size, then read the reminder of the file into said buffer, until end of file. Instead of reading as many bytes as he has allocated. Now for a correct file this would work, however if the file is maliciously crafted to indicate one size in the header while having a much larger real size, you would do a classic buffer overrun. This is pretty much similar to what the SSL programmer did. And no tools were ever able to predict this type of errors, whether TIFF or SSL.

BTW the last famous one with TIFF files was pretty recent:
http://threatpost.com/microsoft-to-patch-tiff-zero-day-wait-til-next-year-for-xp-zero-day-fix/103117

Re:Not really (1)

MoonlessNights (3526789) | about 4 months ago | (#46911149)

This is EXACTLY the way to look at this!

Relying on static analysis to solve parameter validation bugs is asking technology to solve a human problem, akin to asking the computer "do what I want, not what I said".

Static analysis and defensive programming techniques are good ideas but there is always a chance for something to go wrong.

Re:Not really (1)

perpenso (1613749) | about 4 months ago | (#46911453)

Fuzzing may catch an erroneously stated buffer size type bug.

An automated tool that was probing the binary on a live system is was what discovered heartbleed.

Easy (2, Informative)

kamapuaa (555446) | about 4 months ago | (#46911185)

What did I miss?

An article before the word "bad."

I'm so tired of this... (0, Flamebait)

arfonrg (81735) | about 4 months ago | (#46911263)

I want to punch everyone in the head who is using Heartbleed as an example of why NOT to use open source. It actually proves that open source development works well. Once the bug was found, the fix was released very quickly. I can guarantee you that if this was a closed source commercial product, the bug would exist a long time and the bug's existence would have been denied for a long time.

If anyone thinks this is an example of open source failure, they are idiots.

Re:I'm so tired of this... (1)

jones_supa (887896) | about 4 months ago | (#46911675)

The Heartbleed vulnerability existed for a long time, then it was fixed quickly when finally discovered.

The recent Internet Explorer vulnerability existed for a long time, then it was fixed quickly when finally discovered.

Multiple implementations. (1)

Anonymous Coward | about 4 months ago | (#46911329)

As with any population, _variation_ is the best defence against attack and disease. The best defence against the next heartbleed? Have more than one implementation.

Too much reliance upon testing tools (0)

Anonymous Coward | about 4 months ago | (#46911379)

The blog posting spent 80+% of it's time focusing on automated testing tools. They are fine and all, but cannot make up for a lack of basic good design practices. Ones which were present in the Heartbleed episode.

What would really have helped prevent Heartbleed?

1). Initialize all allocated memory. Routinely and automatically. And stop complaining that it "takes too much time." That's an excuse;

2). For Heartbleed particularly, I fail to understand why the echo word didn't self-define it's own length. Why did the programmer require this as a separate parameter? I'm a programmer and this is a glaringly obvious location for logic holes. The strongest defence against the possibility of conflicting parameters is not better parameter checking code. The strongest defence is to redesign the parameters to eliminate the possibility of the conflicts in the first place. Parameter error check code is good; error avoidance is better. This is programming 101 here!

I realize that I'm asssuming certain things here. However that's the best information I have for the moment and that's my take away.

Re:Too much reliance upon testing tools (0)

Anonymous Coward | about 4 months ago | (#46911475)

#1. Wouldn't have helped. As i understand it, the allocated memory was filled with the 'ping' data, the problem was reading past the allocated memory and sending happened to be in memory after it... combined with storing important data like encryption keys in any old random piece of allocated memory.

#2. I believe the spec requires length and content as separate fields. A retarded spec often leads to retarded code.

Re:Too much reliance upon testing tools (0)

Anonymous Coward | about 4 months ago | (#46911559)

The retarded code and the retarded spec were written by the same person... part of why people wonder if it was an accident.

this paper is an epic fail (0)

iggymanz (596061) | about 4 months ago | (#46911439)

actually a couple more *bad* vulnerabilities were found in openssl, but the author of this paper didn't find them. arm waving ivory tower bullshit, that's how we got into this pickle in the first place

Re:this paper is an epic fail (0)

Anonymous Coward | about 4 months ago | (#46911573)

I second that.
These university types are way out of touch with the realities and challenges of the software security field. But man, can they preach!

It's a good essay; some other thoughts. (0)

Anonymous Coward | about 4 months ago | (#46911477)

- Simplify the code, and the protocol. LibreSSL's simplifying OpenSSL, but also, we didn't need heartbeats built into a crypto protocol in the first place.

- Lots of code needs more review. Other open-source frameworks and servers are in OpenSSL's same nasty spot of being widely used but not corporate-supported and well-vetted.

- Non-security code can cause critical security bugs, too; remember the zlib bug. We can give widely-used non-security libraries more fuzzing/review, and/or figure out ways to better contain software faults with finer-than-process-level precision.

- C(++) is certainly a playground full of buzzsaws, but we're also addicted to it; maybe augment w/things like bounds-checked array access where we can afford it and standardized formatting and linting to catch some bugs (if not this one).

- If we only consider bugs like Heartbleed, we're stuck fighting the last war. We should think about those CAs and providers we trust, or the way we rely on passwords, or how to change servers' default configs and libraries to make it more natural to deploy secure services than it is today.

Did I hear anybody said "Gödel?" (1)

fluido (9095) | about 4 months ago | (#46911527)

One of the many eye-openers that reading Douglas Hofstadter's "Gödel, Escher, Bach" book has provided me, all those years ago, is that, no matter how much we humans may try, we may *never* be sure to have removed all errors or imperfections from anything that's even marginally worth of our interest. In a nutshell, if you can prove that something has reached perfection, at the same you prove that it is not interesting anymore.

We cannot write complex bug-free software. PERIOD. OpenSSL is not windows. Headlines about OpenSSL bugs are not such a common occurrence. One bug happened at the wrong time, wrong place. This could have happened even if the world had opted for a proprietary library for this critical role. The only difference is that there would have been somebody to sue. Big consolation.

New theories come out of IT faculties around the world at regular intervals, that promise, if strictly followed, the holy grail of bug-free software. All of them eventually prove non-effective.

The only concrete effect of all these tactics is that the job of the programmer becomes more tedious, less interesting. One thing I can tell you from direct experience is that, the lowest the level of interest of the programmer, the higher the possibility will be that bugs may slip into his or her code.

So, the question is wrong. We cannot prevent the next Heartbleed. What the world needs to (re)learn instead is how to cope with unexpected events without reaching for your phone and calling your lawyer.

Many thanks go to all free software contributors, including OpenSSL ones, for what they do!

Re:Did I hear anybody said "Gödel?" (1)

RR (64484) | about 4 months ago | (#46911709)

We cannot write complex bug-free software. PERIOD. OpenSSL is not windows. Headlines about OpenSSL bugs are not such a common occurrence. One bug happened at the wrong time, wrong place. This could have happened even if the world had opted for a proprietary library for this critical role. The only difference is that there would have been somebody to sue. Big consolation.

New theories come out of IT faculties around the world at regular intervals, that promise, if strictly followed, the holy grail of bug-free software. All of them eventually prove non-effective.

The only concrete effect of all these tactics is that the job of the programmer becomes more tedious, less interesting. One thing I can tell you from direct experience is that, the lowest the level of interest of the programmer, the higher the possibility will be that bugs may slip into his or her code.

Actually, it's possible to remove all errors and imperfections, if you would be satisfied with being boring. That's one thing I got from Douglas Crockford's Programming Style and Your Brain. [youtube.com] Sometimes, especially for security-related software, "boring" is exactly what you want.

Unfortunately, SSL is anything but boring. It's barely standardized, and it's prone to getting new features. But just because the standard is exciting, doesn't mean the code has to be exciting. The OpenSSL developers may have received $2,000 in donations last year, but they make money by consulting on OpenSSL. They have a perverse incentive to keep OpenSSL confusing and buggy. The efforts for the LibreSSL project [opensslrampage.org] show just how needlessly exciting the OpenSSL code base is.

To prevent the next Heartbleed, it's more productive to donate to LibreSSL. [libressl.org]

Thanks for this article (2)

godrik (1287354) | about 4 months ago | (#46911543)

Hi dwheeler,

This is a great article. It covers many common software development and testing techniques. But also some "on live system" techniques. It was a pleasure to read, I'll recommend it to various places.

Re:Thanks for this article (2)

jones_supa (887896) | about 4 months ago | (#46911677)

Agree, that's a fine article.

hmmm... (0)

Anonymous Coward | about 4 months ago | (#46911609)

dollars and able bodies... simple enough, the project before this incident had neither sufficient budget nor sufficient numbers of people working on it.. considering the number of huge, profitable companies, institutions and governments that rely upon the project for day-to-day operations, simply NO EXCUSE.

Re:hmmm... (0)

Anonymous Coward | about 4 months ago | (#46911689)

The free software movement has succeeded in reducing the market value of software to zero. You wouldn't expect huge, profitable companies, institutions and governments to pay more than market value for software, would you?

And what if (0)

Anonymous Coward | about 4 months ago | (#46911619)

If we look how was treated the disclosure of DES vulnerability, and if we compare with the status regarding RSA, we can expect that the next hearthbleed vulnerability will not be in the implémentations but in the foundations.

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>