Slashdot Mirror


NSA Allegedly Exploited Heartbleed

squiggleslash writes: "One question arose almost immediately upon the exposure of Heartbleed, the now-infamous OpenSSL exploit that can leak confidential information and even private keys to the Internet: Did the NSA know about it, and did they exploit if so? The answer, according to Bloomberg, is 'Yes.' 'The agency found the Heartbeat glitch shortly after its introduction, according to one of the people familiar with the matter, and it became a basic part of the agency's toolkit for stealing account passwords and other common tasks.'" The NSA has denied this report. Nobody will believe them, but it's still a good idea to take it with a grain of salt until actual evidence is provided. CloudFlare did some testing and found it extremely difficult to extract private SSL keys. In fact, they weren't able to do it, though they stop short of claiming it's impossible. Dan Kaminsky has a post explaining the circumstances that led to Heartbleed, and today's xkcd has the "for dummies" depiction of how it works. Reader Goonie argues that the whole situation was a failure of risk analysis by the OpenSSL developers.

149 comments

  1. Conflict of interest by benjfowler · · Score: 5, Insightful

    Why even have the same agency responsible for foreign electronic intelligence and put them in charge of "cyberdefence" (how I hate that term..).

    It's a massive conflict of interest. You're virtually begging them to find and then sit on dangerous exploits.

    1. Re:Conflict of interest by grumpy_old_grandpa · · Score: 1

      > You're virtually begging them to find and then sit on dangerous exploits.

      That was their mandate in the first place. Nobody begged - It was an order.

    2. Re:Conflict of interest by timeOday · · Score: 2

      How do you propose to separate them? Offense and defense are not really two separate things; if you can do one, you can do the other.

    3. Re:Conflict of interest by Anonymous Coward · · Score: 0

      It doesn't work like that in the virtual world though; the techniques used for defence of a network or software environment have little crossover with those used to attack the same system. In both cases you need to know about an exploit to be able to protect against or abuse it, but you can't defend a network by DDOSing another.

    4. Re:Conflict of interest by AHuxley · · Score: 2

      Re How do you propose to separate them? Offense and defense are not really two separate things; if you can do one, you can do the other.
      Think back to past presidents views on parts of the the US intelligence community.
      JKF had is views on the CIA after the Bay of pigs.
      Rockefeller Commission, Church Committee, Pike Committee, Murphy Commission, the Select Committee on Intelligence and the Directorate of Operations events in 1977. The domestic activities, human experimentation issues and need for a ban on assassinations all became public. The CIA changed to technical collection removing a lot of staff.
      Then you had joys of the Iran-Contra Affair then onto Intelligence Authorization Act.
      The NSA could face the same path due to the loud, public domestic activities around U.S. citizens and persons with U.S. permanent residence. A return to its classic quiet support role around the world vs its new emerging need to play a role or say in offensive direct action roles.
      The GCHQ had it right - stay hidden, build a vast tech, political and staff foundation going back generations and never comment on very much.
      Recall the end of the Clipper conversations the US gov had with the public over role of US code experts and US exports?
      In the end it seemed you could have any crypto you wanted at any price or for free....
      The "separate" has to come back to protecting U.S. citizens from a vast life long domestic spying program and global junk US crypto standards.

      --
      Domestic spying is now "Benign Information Gathering"
    5. Re:Conflict of interest by thoth · · Score: 1

      Why even have the same agency responsible for foreign electronic intelligence and put them in charge of "cyberdefence" (how I hate that term..).

      It's a massive conflict of interest. You're virtually begging them to find and then sit on dangerous exploits.

      Their "cyberdefence" mission is to defend DoD systems, not the entire world's computers.

      If you don't like it, gripe that NIST and DHS aren't doing their jobs (they are the agencies actually over commercial internet security and non-DoD government sites) or transfer/alter their authority. Everybody thinking the NSA is there to protect their banking and email all have the wrong idea of what they do.

    6. Re:Conflict of interest by Anonymous Coward · · Score: 0

      Offense and defense are not really two separate things

      That is a statement that needs clarification or proof.

      In this case you have the kind of "mostly just offensive" offense that have managed to piss a lot of people worldwide off.
      Creating enemies is the exact opposite of defense. Getting friends while not pissing anyone off is a great defense.

      NSA appears to me to be an offensive tool only, and an ineffective one at that.
      All it has done so far has been to make everyone consider us an enemy.

    7. Re:Conflict of interest by leonardluen · · Score: 1

      part of defending a network is understanding how it can be attacked. so you can develop countermeasures to mitigate the attacks.

      so it helps when defending a network if you are also good at attacking one.

  2. Obligatory xk..... by Anonymous Coward · · Score: 5, Funny

    YOU SON OF A BITCH

  3. Re:It's not a bug by Moheeheeko · · Score: 2

    The only bug here is that it wasnt hidden deeply enough.

  4. They have a stash of 0-days by Anonymous Coward · · Score: 0

    They're not just exploits, they're "offensive capabilities."

    Must have been nontrivial to make patches for their own exploits without being the actual developer.

  5. This seems plausable by capedgirardeau · · Score: 3, Insightful

    I can understand this happening. It would make sense that the NSA would have someone or multiple people review every patch and check-in for a package as important as OpenSSH, just looking for exploitable mistakes.

    I would not be surprised if they review a great deal of FOSS software they deem important to national security.

    --
    Wax on, wax off baby!
    1. Re:This seems plausable by Anonymous Coward · · Score: 1, Insightful

      This is the dark side of the "with enough eyeballs, all bugs are shallow" theory. The eyeballs don't have to tell anyone else.

      The full source code is conveniently carried to NSA without them needing to bully any company. Then it is analyzed by genius hackers who are paid top dollar for the job. They probably already have a good stock of other OSS exploits too, which are unknown to the rest of the world.

    2. Re:This seems plausable by JDG1980 · · Score: 3, Interesting

      Then it is analyzed by genius hackers who are paid top dollar for the job.

      "Top dollar"? This is a government agency. They pay based on the GS scale. Even if the NSA's security hackers were classified at GS-15 (the highest rate), that's about $120K a year to begin – if they really are "geniuses" then they could do better in Silicon Valley, and probably feel better about their jobs as well.

      In general, the GS scale pays somewhat more than typical private-sector rate for low-end jobs, but considerably less for high-end jobs.

      Government contractors rake in the dough, but that money goes to politically-connected businessmen, not rank-and-file employees.

    3. Re:This seems plausable by Anonymous Coward · · Score: 0

      They don't really need to "bully" any companies to get access to source code, companies bring it to them willingly. To get software installed on government computers, sources has to be audited, so companies readily show it to security agencies to get those sweet government contracts.

      So yeah, they've got a good stock of OSS exploits and they've got a good stock of proprietary exploits. They're probably aching to try out some of those XP vulns they had stashed, now that they don't have to worry about them getting patched.

    4. Re:This seems plausable by Smallpond · · Score: 3, Interesting

      This patch was submitted at 7pm on Dec 31st, 2011, so the only people looking at it were the ones expecting it. I guess they were not disappointed.

      http://git.openssl.org/gitweb/...

    5. Re:This seems plausable by koan · · Score: 1

      But this presents an interesting challenge, how do you evade someone that has control of the network? Is it possible?

      --
      "If any question why we died, Tell them because our fathers lied."
    6. Re:This seems plausable by Anonymous Coward · · Score: 0

      Actually, when you look at the all-in cost of a GS employee, it far exceeds the cost of MOST DoD contracts... Contractors rarely have a pension program, much less essentailly guarenteed job security. Do you know how hard it is to fire a career GS employee?

    7. Re:This seems plausable by neoform · · Score: 1

      You would think if the government was doing this, they would at least tell their fellow government agencies about the flaws, so that they would not be vulnerable to foreign hackers...

      --
      MABASPLOOM!
    8. Re:This seems plausable by jhol13 · · Score: 1

      I challenge anybody to review it and find (or notice) the bug.
      My point, once again, is: C should not be used for security sensitive programs, we should start using managed languages.
      I know, won't happen, because people are lazy and won't learn. Yet again we will think that this fix solves everything, that now OpenSSL is fixed. Which it most likely is not; I would be really surprised if there are no holes KNOWN (to some russian, chinese, israeli, usa, ... agency, or mafia).

    9. Re:This seems plausable by Urkki · · Score: 2

      I challenge anybody to review it and find (or notice) the bug.

      Wasn't this a plain and simple using un-sanitized data from packet received from the adversary (for code review purposes, all network data comes from an adversary)? Anybody doing serious code review should know to check for this and study code until sure all such values are handled safely, or reject change if code is too obfuscated to be sure. Anybody missing this should not be given any code to review responsibility without more experienced supervision.

    10. Re:This seems plausable by Anonymous Coward · · Score: 0

      They don't really need to "bully" any companies to get access to source code, companies bring it to them willingly.

      There's still a higher threshold to get access to closed source. You have to actually ask, and the company will now know that you are snooping around. With OSS, you can just download the freely available source code.

    11. Re:This seems plausable by Anonymous Coward · · Score: 0

      a package as important as OpenSSH

      Just to clarify: the "heartbleed" bug is in OpenSSL. OpenSSH is a different package.

    12. Re:This seems plausable by squiggleslash · · Score: 1

      Yeah. It's a big patch. I started looking through it when it came out and while I noticed bugs (there's a "convert integer to string" call in there that uses a variable - fortunately the integer involved - that hasn't been initialized yet - "n2s(p, payload);") nothing I saw before realizing it was way more work than I'd expected jumped out at me as the actual security flaw here.

      --
      You are not alone. This is not normal. None of this is normal.
  6. I am totally surprised by this by Dega704 · · Score: 1

    Said no one ever.

  7. This sounds likely by gurps_npc · · Score: 4, Insightful

    The basic fact is, if they did not exploit it, then someone working for them is thinking "DAMN, I wish I thought of using that!"

    --
    excitingthingstodo.blogspot.com
    1. Re:This sounds likely by Anubis+IV · · Score: 1

      They definitely didn't exploit it. How do I know? Because they said so, so it must be true. Right? They wouldn't lie to us, would they?

  8. I don't understand by Krojack · · Score: 1

    Why can we not start a class action lawsuit against the Government, NSA and those that allow snooping around in personal data without probable cause?

    1. Re:I don't understand by raydobbs · · Score: 1

      One cannot simply sue a branch of the government without asking permission from the government to allow it to be sued - guess how often THAT happens? Plus is NSA has a built-in out; its in the interests of national security. Its bullshit - we all know it - but it a legal out, its the reason they can deny your FOIA request for information about Area 51, the Roswell incident, as well as the intelligence records on Jimmy Hoffa or J. Edgar Hoover.

    2. Re:I don't understand by radarskiy · · Score: 1

      You need to have enough evidence of *something* possibly happening to show that you have standing to bring the case.

    3. Re:I don't understand by Vintermann · · Score: 1

      That's a good idea, because the least accountable branch of government is surely on your side! /s

      The judicial branch and the supreme court serve much the same purpose as the Tsar in old Russia. No matter how bad it gets, it's not the Tsar's fault. It's the noblemen's fault. The Tsar just has bad advisers. If only we could get past them and talk to him and make him understand, it'd all be OK.

      --
      xkcd is not in the sudoers file. This incident will be reported.
    4. Re:I don't understand by the+eric+conspiracy · · Score: 1

      To start with, because of sovereign immunity.

    5. Re:I don't understand by Anonymous Coward · · Score: 0

      Sure, why don't we do that? Go ahead and call around for attorneys and I'll wait to hear back from you. *twiddle* Still sitting there? *twiddle*

      It's called apathy.

      As much as folks groan and complain about everything on here, that's all it will ever be. Just Slashdot users wondering why no one does X or Z.

  9. Allegedly? by Anonymous Coward · · Score: 0

    It's a hugely used cryptographic library, and the NSA has resources galore. Even without having the manpower to manually go through the source (which they totally have) it's a simple enough problem that automated testing would show it up. From their perspective it would have almost been negligent of them to have not known about it since day one

    1. Re:Allegedly? by Anonymous Coward · · Score: 0

      While I agree with you that is the case, the question is, how did nobody else find out about this until now? With it being open source and used by so many companies world-wide that focus on being secure, why did none of them bother to make sure it didn't have a gaping hole in it?

    2. Re:Allegedly? by AHuxley · · Score: 2

      Re how did nobody else find out about this until now?
      The same reason NATO and other US allies did not understand the NSA Martin and Mitchell defection http://en.wikipedia.org/wiki/M... in 1960 with the press conference saying:
      "As we know from our previous experience working at N.S.A., the United States successfully reads the secure communications of more than forty nations, including its own allies."
      Embassies, govs and firms went on using the same junk standard crypto hardware over decades of revisions. Some even got to re read their own secure embassy communications 'leaked' to the Western press.
      There seems to be something missing on the story of gov, staff and developers when it comes to crypto products.
      Skilled EU gov experts handing their own political leaders broken crypto that 5++ other nations can break seems too good to be true over generations.
      Junk in the hardware decades, junk in the software decades all for speed, interoperability and after a good sales pitch?
      Or a lot of skilled people around the world know and just tell their respective govs to bait the junk communications networks until US political leaders speak out.

      --
      Domestic spying is now "Benign Information Gathering"
  10. Anonymous also used this flaw? by Anonymous Coward · · Score: 0

    Anonymous likely also exploited this flaw to attack servers in the past including public facing government websites.

    1. Re:Anonymous also used this flaw? by Anonymous Coward · · Score: 0

      Do you have a source for this or just sensationalistic speculation?

  11. Re:It's not a bug by fustakrakich · · Score: 1

    Really man! And nothing confirms this story like an official denial. (I think that's how it goes)

    --
    “He’s not deformed, he’s just drunk!”
  12. Do it enough times by HermMunster · · Score: 1

    If you know about it and have access to virtually unlimited resources you can afford to attach to your target and do it as many times as you want in order to get what you want.

    And, frankly, I don't believe the guy that claims responsibility for the bug.

    As well, if something this simple could cause such an issue then clearly it is an issue for lots of other important security programs.

    --
    You can lead a man with reason but you can't make him think.
    1. Re:Do it enough times by TapeCutter · · Score: 2

      As well, if something this simple could cause such an issue then clearly it is an issue for lots of other important security programs.

      Yes, it's one of the most common memory handling bugs and is known as a buffer overflow, generally buffer overflows are difficult to exploit which can be seen in the fact that nobody has actually demonstrated extracting a key using this particular bug, just that it is "possible" to do so. Winning the lottery is also "possible".

      There's all sorts of complete bullshit about this bug in the press, to paraphrase what I read today in the WSJ that "It turns out that just 4 European developers and some guy in the US are responsible for the code that secures the internet", utter drivel!

      attach to your target and do it as many times as you want

      There's almost certainly more than one layer of security for anything juicy, for example, the delay enforced on posts from the same Slashdot account makes it difficult (but not impossible) to spam Slashdot comments.

      --
      And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
    2. Re:Do it enough times by PhunkySchtuff · · Score: 1

      Private key grabbed. Game over.
      One successful attempt took >2.5M requests over a day. Second successful attempt was something like 100k requests.

      http://blog.cloudflare.com/the...

      It's all in the luck of the draw. When you don't have any logging of this, you've got no idea how long people have been poking at this and literally no idea what anyone has made off with.

  13. Not the last we'll hear about OpenSSL? by jphamlore · · Score: 2

    And what are the odds there aren't at least a half dozen other bugs as serious still to be found in the OpenSSL source code ...

  14. NSA put the bug there, of course they exploited it by EmagGeek · · Score: 1

    We need to find out if the author of this bug is or was on the NSA payroll. It would not be surprising to find out he was paid to put it there.

  15. Re:It's not a bug by NoKaOi · · Score: 5, Insightful

    it's a (NSA) feature...

    Even if it's not an NSA feature...of course the knew about it! They would have to be even more incompetent than we think not to. They are HUGE, with something like 40,000 employees. At least of few of those employees must be dedicated to code review of OSS looking for vulnerabilities, and more in general looking for vulnerabilities in any widely used software. And if that's the case, then you'd think OpenSSL would be one of the first things they'd look at. The fact that they didn't tell anyone though shows that the S is NSA is bullshit. They cared more about being able to exploit the vulnerability themselves than making their country's computers more secure. If they cared one shit about their country's security then they'd have big teams dedicated to finding software vulnerabilities and working with vendors to fix them.

  16. Re:NSA put the bug there, of course they exploited by 93+Escort+Wagon · · Score: 4, Informative

    The author of this bug and the reviewer of the commit have both been very forthcoming about the mistake. There's little reason to suspect malicious intent in this particular instance.

    That doesn't mean the NSA didn't know about it or exploit it, though.

    --
    #DeleteChrome
  17. You don't understand, yep! by rjh · · Score: 5, Informative

    One cannot simply sue a branch of the government without asking permission from the government to allow it to be sued - guess how often THAT happens?

    Glad you asked: it happens all the time, ever since the Tort Claims Act of 1948 substantially waived the sovereign immunity doctrine. You can read more about it at Wikipedia.

    People sue the government all the time. It's literally an everyday occurrence.

    1. Re:You don't understand, yep! by cold+fjord · · Score: 1

      That doesn't provide an opened ended unlimited right to sue. I very much doubt you'd have an allowable claim for injury on this.

      --
      much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
    2. Re:You don't understand, yep! by raydobbs · · Score: 2

      ...and I learn something new every day. Thank you for sharing that without calling me a moron. I knew it had been a few years since my last political science class, now I have something new to read up on.

    3. Re:You don't understand, yep! by rjh · · Score: 3

      I'm not weighing in on that one. I'm only correcting the original poster, who said the U.S. rarely waives sovereign immunity. In fact, the opposite is true: it rarely invokes it. Tens of thousands of tort claims against the U.S. government are underway even as we speak, all of them with waived sovereign immunity.

  18. It's time we own up to this one by Bruce+Perens · · Score: 4, Insightful

    OK guys. We've promoted Open Source for decades. We have to own up to our own problems.

    This was a failure in the Open Source process. It is just as likely to happen to closed source software, and more likely to go unrevealed if it does, which is why we aren't already having our heads handed to us.

    But we need to look at whether Open Source projects should be providing the world's security without any significant funding to do so.

    1. Re:It's time we own up to this one by Anonymous Coward · · Score: 5, Insightful

      The problem with open source when it comes to things like this is that there are so few people who are even qualified to implement protocols like this, and even fewer of them who are willing to work for nothing. The community needs to pony up some cash to have important projects audited like what they are trying to do with TrueCrypt right now.

    2. Re:It's time we own up to this one by Anonymous Coward · · Score: 0

      SSL is a much worse problem in itself. Relying on some "trustworthy" certificate authority sounds like a good idea, huh? It's a completely broken idea, especially in this age when the worst enemy is the own government.

    3. Re:It's time we own up to this one by hawguy · · Score: 1

      OK guys. We've promoted Open Source for decades. We have to own up to our own problems.

      This was a failure in the Open Source process. It is just as likely to happen to closed source software, and more likely to go unrevealed if it does, which is why we aren't already having our heads handed to us.

      But we need to look at whether Open Source projects should be providing the world's security without any significant funding to do so.

      If it's just as likely to happen to closed source software, then why is it a failure of the Open Source process? It was discovered and fixed so quickly *because* it's open source - there may be similar holes in closed source software that are being exploited today, yet no white hats have discovered them yet.

    4. Re:It's time we own up to this one by Bruce+Perens · · Score: 3, Informative

      I'd say more than just the "community". We have a great many companies that incorporate this software and generate billions from the sales of applications or services incorporating it, without returning anything to its maintenance.I think it's a sensible thing to ask Intuit, for example: "What did you pay to help maintain OpenSSL?". And then go down the list of companies.

    5. Re:It's time we own up to this one by Bruce+Perens · · Score: 2

      Sure. We're better. But we need to be even better than that.

    6. Re:It's time we own up to this one by MarcoAtWork · · Score: 2

      this does not have anything to do with open source and all to do with the software development process (or lack of) used here: something like this could've happened in a closed source library just as easily, the only difference would be that rather than source analysis you'd have used other tools to find the vulnerability: if a new addition to a protocol comes in and you have bad intentions of course the first thing you do is to see what happens if you feed it invalid data, if you did that here you'd have found this extremely quickly (and probably faster than if you were trying to do source analysis).

      The main issue here is that you should not be able to commit anything to something like OpenSSL with only one reviewer looking at it, period. The secondary issue is that for anything this important there should be a LOT of unit tests for everything and that absolutely everything everywhere should be tested with invalid input to make sure the library is solid: QA-ing a crypto library is a job as important as writing it in the first place and should be funded just as much, there unfortunately does seem to be a bias against QA being as important as development among developers, until this bias is removed this kind of issue will keep happening.

      QA and development are two faces of the same coin for critical software, some people are better at writing something, others at finding issues with things other people developed: there should be no stigma for people preferring focusing more on QA, but in a lot of companies QA is seen as much less prestigious than development and the first thing to outsource, which leads to substandard testing, which creates more problems (because the tests are not good but give you the false impression that your software is ok).

      --
      -- the cake is a lie
    7. Re:It's time we own up to this one by Bruce+Perens · · Score: 4, Interesting

      I have to say I'm even less confident in the plan to couple it to DNSSEC.

    8. Re:It's time we own up to this one by MarcoAtWork · · Score: 1

      and btw, funding is good, but funding does not buy you a good software development process: for that you need to actually focus on finding a good process first, and use the funding to achieve what you are planning without forgetting that if it's a critical piece of infrastructure nowadays it will be attacked by adversaries with much larger pockets than yours no matter how large yours are, so the process has to take into account that any development is done in a completely hostile environment, where a-priori you cannot trust ANYTHING, you can't trust your compiler, you can't trust your system libraries, you can't trust your fellow developers and you can't trust the repository you are using.

      How do you deal with this? That is definitely a question you would need some of that funding to answer correctly, but it probably would include a lot of redundancy and testing: the advantage of the OSS model is that you can actually do this out in the open where everybody can see what you are doing and vet it every step of the way (a lot of those eyes are unskilled in your particular domain, but still it's a lot better than not having those eyes available at all).

      --
      -- the cake is a lie
    9. Re:It's time we own up to this one by Anonymous Coward · · Score: 1

      It was discovered and fixed so quickly *because* it's open source

      For crikessakes, the heartbleed vulnerability existed for over 2 years before being discovered and fixed!

    10. Re:It's time we own up to this one by oldhack · · Score: 1

      Bugs happen. We should assume there are more bugs of similar nature and have a plan on how to proceed when the next one is discovered. It's particularly important for OpenSSL as it may affect not only SSL encryption keys but whole chains of SSL certs.

      --
      Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
    11. Re:It's time we own up to this one by bill_mcgonigle · · Score: 4, Insightful

      This was a failure in the Open Source process.

      Indeed. People have been saying for years that the OpenSSL code leaves much to be desired but nobody dares fix it because it might break something (needed: comprehensive unit tests).

      There's been a bug filed for years saying that the code won't build with the system malloc, which in turn prevents code analysis tools from finding use-after-free conditions. The need here is less clear - leadership of the project has not made such a thing a priority. It's not clear that funding was the sole gating factor - commit by commit the code stopped working with the system malloc and nobody knew or cared.

      Sure, a pile of money would help pick up the pieces, but lack of testing, continuous integration, blame culture, etc. might well have prevented it in the first place.

      We still have sites like Sourceforge that are solving 1997 problems, like offering download space and mailing lists when what we need today is to be able to have continuous integration systems, the ability to deploy a vm with a complex project already configured and running for somebody to hack on, etc.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    12. Re:It's time we own up to this one by hawguy · · Score: 3, Interesting

      It was discovered and fixed so quickly *because* it's open source

      For crikessakes, the heartbleed vulnerability existed for over 2 years before being discovered and fixed!

      Sorry my bad, that sentence was confusing -- I meant the fix was fast, not finding the bug.

      An exact timeline for Hearthbleed is hard to find, but it looks like there was some responsible disclosure of the bug to some large parties about a week before public disclosure and release of the fixed SSL library.

      In contract, Apple learned of its SSL vulnerability over a month before they released an IOS patch and even after public disclosure of the bug, it was about a week before they released the OSX patch. And just like the OpenSSL bug, Apple's vulnerability was believed to have been in the wild for about 2 years before detection. (of course, since the library code was opensourced by Apple, several unofficial patches were released before Apple's official patch).

    13. Re:It's time we own up to this one by Bruce+Perens · · Score: 1

      I think we need to take a serious look at the "many eyes" theory because of this. Apparently, there were no eyes on the part of parties that did not wish to exploit the bug for close to two years. And wasn't there just a professional audit by Red Hat that caught another bug, but not this one?

    14. Re:It's time we own up to this one by AHuxley · · Score: 3, Informative

      Re even qualified to implement protocols like this. Thats a very interesting point. How many have their tools of the trade via a top university settings and a security clearance option and dependant funding.
      Once you start down the math path the classes get smaller and fewer stay for needed years vs lure of private sector telco or unrelated software work.
      Most nations really do produce very few with the skills and keep them very happy.
      Trips, low level staff to help, good funding, guidance, friendships all just seem to fall into place.
      Bringing work home and helping open source could be seen as been an issue later vs students or team members who did open source games or made apps.

      --
      Domestic spying is now "Benign Information Gathering"
    15. Re:It's time we own up to this one by l0n3s0m3phr34k · · Score: 4, Insightful

      Exactly! Everyone can get to the source, the whole point of OSS is that the companies themselves can (and should, from a risk-analysis point) be reviewing all the code too before implementation...it's along the lines "you get what you pay for" yet at least here everyone is given the chance to see exactly what's being run (as opposed to pre-compiled apps). IMHO, this really isn't an OpenSSL issue as much as a failing of due diligence by all the companies using it. The admin's excuse of "well, we don't actually know what the code says" fails here, and anyone over the past two years could have reviewed it themselves and fixed this! Maybe this will spur corps to actually review code of critical infrastructure when it's avalible as part of corp policy from now on, perhaps the insurance companies who do "Errors and Omissions" policies will start forcing corps to do that; kinda surprised that this isn't already a standard policy, as code review of OSS is one of it's main strengths and if your company doesn't do it then their missing out on one of the biggest assets of using OSS.

    16. Re:It's time we own up to this one by l0n3s0m3phr34k · · Score: 1

      There was another person who looked at it before the commit, apparently they also missed it. So apparently a better code reviewing policy is also needed here.

    17. Re:It's time we own up to this one by MikeBabcock · · Score: 2

      I hate to disagree with you, but this has nothing to do with Open Source, it has to do with software engineering.

      This same bug could have been introduced in closed-source software just as easily. The problem is making sure that software is securely reviewed before its disseminated, much like the OpenBSD people have been touting all these years, instead of just throwing things together however they work.

      The only part F/OSS played in this is that we *found* the bug and can identify exactly when and how it occurred. All the bad parts of this situation are not unique to F/OSS.

      --
      - Michael T. Babcock (Yes, I blog)
    18. Re:It's time we own up to this one by jhol13 · · Score: 0

      "less clear"?

      Less clear my ass! I'd say there is no leadership in the project, unless "FUD" (fear of it breaking something) is called "leadership". But then as you say, "nobody cares".
      If the code is as you describe, the whole shebang should be rewritten from scratch using higher level managed language. Any managed language would have prevented the information leak although probably not the unchecked value.

    19. Re:It's time we own up to this one by mpe · · Score: 3, Insightful

      SSL is a much worse problem in itself. Relying on some "trustworthy" certificate authority sounds like a good idea, huh?

      This might be more an issue of how it is being used. Not everything using SSL also uses "certificate authorities". Theres also no reason why software which odes can't give a warning if the CA were to unexpectedly change.

      It's a completely broken idea, especially in this age when the worst enemy is the own government.

      Has there been a time, at least within modern history, where this has not really been the case?

    20. Re:It's time we own up to this one by phantomfive · · Score: 2
      In some ways it shows the success of open source software; the bug was only found by Google engineers because it is open source.

      But we need to look at whether Open Source projects should be providing the world's security without any significant funding to do so.

      I'm in favor of more funding for open source, but in this case I would still trust the security of the internet on open source long before I would trust it to closed source. I've seen what too much closed source looks like, and it scares me.

      --
      "First they came for the slanderers and i said nothing."
    21. Re:It's time we own up to this one by phantomfive · · Score: 2

      I think we need to take a serious look at the "many eyes" theory because of this. Apparently, there were no eyes on the part of parties that did not wish to exploit the bug for close to two years. And wasn't there just a professional audit by Red Hat that caught another bug, but not this one?

      I'm going to say this calls into question the value of professional audits.

      My experience is that visual inspection of code does little to remove all the bugs. It's just really hard to muster the concentration needed to verify that the code is good with your eyes.

      --
      "First they came for the slanderers and i said nothing."
    22. Re:It's time we own up to this one by Anonymous Coward · · Score: 0

      Or, perhaps, "many eyes makes bugs shallow" works less well than test-driven development, modern languages with more complicated type systems, Address Sanitizer, and marshallers as a native language feature like json or a code generator like protobufs, not written as adhoc 'char *p' loops and hand-written memcpy's.

      I don't think open source is currently able to apply the pressure toward code quality that some proprietary software mines do because the initial implementation is usually one guy's unsupervised passion project, and we've been shrugging off that problem with "many eyes make bugs shallow," along with useless reductionist C apologists claiming the answer is "try harder" but saying it with more words.

    23. Re:It's time we own up to this one by ceoyoyo · · Score: 1

      Three years is quick?

    24. Re:It's time we own up to this one by Dutch+Gun · · Score: 1

      In the process of rewriting, it's inevitable that a ton of brand-new bugs will be introduced in the new codebase, and you'll have lost all the time and effort hardening the library and fixing all of the thousands of previously exploitable issues.

      I think talk of scrapping or rewriting the library is a bit of an overreaction caused by the scale and scope of the issue, and is certainly not plausible in the short term anyhow. I'd say the proper thing to do is to halt development of new features for a time and investigate the viability of addressing some of the underlying issues that have been pointed out which may have contributed to this bug: Remove the custom memory allocator, or ensure it's off by default. Start writing and using a proper unit test and fuzz testing framework. Document and clean up source with proper variable names and comments to make things easier for those reviewing/auditing code. Make sure the library compiles cleanly. Pay more attention to code that dynamically allocates memory or accepts data from user. Create a better review process. Etc, etc.

      Every time I make a programming mistake or introduce a bug, I ask myself "What could I have done that would have prevented this from happening in the first place? What can I realistically do now to make sure it doesn't happen again?" The OpenSSL team really needs to be asking themselves these questions right now.

      Note that questions like these have to be addressed in a realistic manner as well. "It needs to be thrown out and rewritten from scratch" or "we shouldn't be using C in the first place" are not realistic solutions. Whatever merits Ada has as a language (as one example I've heard), it's simply not going to replace C as a low-level systems and library language anytime in the near future. Language choice is also impacted by issues such as efficiency, programmer availability, interoperability, shared libraries and sample/test code availability, and so on.

      I don't think this is the time to throw hyperbolic accusations or wildly impractical "solutions" around. It's a great time for some serious introspection and development process review, however, not only for the OpenSSL team, but for any sort of project like theirs with similar responsibilities. Even conservative fields of study such as civil engineering have had their spectacular disasters/failures. The thing to do is to assess the situation, learn from your mistakes, and then rigorously apply what you've learned so that you don't make those same mistakes again. It often takes a serious catalyst for that to happen, so in some ways, perhaps we should be glad that this happened sooner rather than later.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    25. Re:It's time we own up to this one by OdinOdin_ · · Score: 1

      Use git as the primary repository for OpenSSL and then implement a system that all incoming patches via gerrit after public review.
      Now everyone and anyone can review every patch, those that complain there are not enough helpers on the project, this is why you did not update the process to let the help arrive, things are pushed through mailing list and RT tracker (some obsolete ticket system).

      Setup a points system under gerrit that requires at least 2 official committers and 2 independent parties on the internet to review every patch.

      Make it a rule that every new feature must have a unit test associated with it to exercise it, or at least the built in applications updated to enable/disable/utilise it.

      Fix that archaic PhD boffin coding convention the project uses, take a look at the Linux kernel source and use this style as a starting point, the OpenSSL coding style doe not lean towards conventions that reduce mistakes.
      Relegate all style gymnastics that are there to allow a compile that is over 10 year old to build the project, move this to another project as a compatibility layer.
      Take a look at seeing of LLVM can instrument the C code during compile to provide code coverage tests, then write tests that utilize all the existing applications, then work on new applications that can exercise the major areas not touched.

    26. Re:It's time we own up to this one by OdinOdin_ · · Score: 1

      No you confuse SSL the protocol with the way that it is used in browsers for HTTPS.

      This (the way the browse makes use of SSL) can always be changed without affecting SSL and without using something other than X.509 certificates. Just change the validation mechanism of the X.509, you don't have to rip up what already exists to make it better.

    27. Re:It's time we own up to this one by OdinOdin_ · · Score: 1

      You can augment custom malloc implementations to notify your memory testing tool of choice.

      What memory testing tool does not have a mechanism to do this ? Someone just needs to setup a C language macro on the exit of the custom malloc() and on entry to the custom free() that passes the argument. Then your tool of choice can do stuff at this point.

    28. Re:It's time we own up to this one by gpoul · · Score: 1

      I guess in the security advisory there will be a neat list of affected companies. This is already a good first step to get this funding and process issue addressed... it's just a matter of someone taking it from there. But I'm not holding my breath.

  19. Fix is here by Anonymous Coward · · Score: 0, Funny

    Fix is here http://www.iis.net/

    1. Re:Fix is here by fishbowl · · Score: 1

      Or here: https://f5.com/

      --
      -fb Everything not expressly forbidden is now mandatory.
    2. Re:Fix is here by Anonymous Coward · · Score: 0

      Except they are vulnerable, too..

      (enable javascipt temproarily to enjoy the fun...)

      http://lmgtfy.com/?q=site%3Af5.com+sol15159&l=1

  20. A failure of risk analysis, sure, but by Anonymous Coward · · Score: 0

    A "failure of risk analysis" by the OpenSSL team I can buy, but does that really have any bearing on whether the NSA would secretly exploit that failure?

    Oh, wait, the NSA has denied it. They always tell the truth.

    ---

    The US Constitution isn't perfect but it's better that what we've got.

  21. North Korea and USA track people by Anonymous Coward · · Score: 0

    It is a common behaviour in communist countries like North Korea or USA. Spying and tracking citizens daily lives is far more important than security.
    Who visited USA lately will notice growing Bolshevism. It starts with fingerprinting at airport, stupid questions and shock when tourist enters downtowns of popular cities.
    Security forces are everywhere. Not only on street but in school and preschool, grocery stores and movie theatres.

    It is terrifying how much in power are now comrades in USA.

  22. Fork it. by grub · · Score: 4, Funny


    Theo de Raadt should fork OpenSSL. He could call it OpenOpenSSL.

    .

    --
    Trolling is a art,
    1. Re:Fork it. by Anonymous Coward · · Score: 0

      about 250-500k into the coffers of the foundation and this might just happen.

    2. Re:Fork it. by Anonymous Coward · · Score: 0

      Knowing Theo da Rat, he'd call it OpenSSL, and he'd be his impervious self whenever people pointed out how confusing and idiotic it is having different projects with the same name.

      What OpenSSL needs is multiple independant line by line code audits of the paid variety, by teams of competent people. It may be an open source piece of software, but considering the countless billions of dollars at stake, there shouldn't be any fucking issue finding the money to make this shit happen.

    3. Re:Fork it. by gman003 · · Score: 1

      What OpenSSL needs is multiple independant line by line code audits of the paid variety, by teams of competent people. It may be an open source piece of software, but considering the countless billions of dollars at stake, there shouldn't be any fucking issue finding the money to make this shit happen.

      What major corporations use SSL? Cisco? IBM? Anybody else like that? We could probably get them to foot most of the bill.

    4. Re:Fork it. by Anonymous Coward · · Score: 0

      or FreeSSL

    5. Re:Fork it. by Anonymous Coward · · Score: 0

      Yeah, lots of things use java and with all the money that went into that its been incredibly secure.

    6. Re:Fork it. by Anonymous Coward · · Score: 0

      Sure, you need to be competent, but not some kind of genius to write unit tests.

  23. Re:It's not a bug by Jeremiah+Cornelius · · Score: 1

    I think that NSA has good coverage and analysis tools. They probably knew of Heartbleed, and they probably know of dozens more flaws like this.

    I will be glad, when they cease to exist.

    --
    "Flyin' in just a sweet place,
    Never been known to fail..."
  24. Does the "fix" include scrubbing? by Animats · · Score: 2

    When this was supposedly "fixed" in OpenSSL, did the fix just fix this one known bug? A real fix includes fixing the storage allocator to overwrite all released blocks, so no other old-data-in-buffer exploit would work.

    1. Re:Does the "fix" include scrubbing? by radarskiy · · Score: 2

      A real fix includes not rolling their own malloc, then fixing the bugs that were hidden by their badly written freelist which prevented people from reverting to a normal malloc.

    2. Re:Does the "fix" include scrubbing? by OdinOdin_ · · Score: 1

      Ignoring the performance hit with this (that many application won't take)

      Often the kernel pages are allocated in 4Kb chunks, this means maybe you covered to the end of the current 4Kb page (that is managed by OPENSSL's custom allocator).

      But the system (libc) allocator is not overwriting released block, and the next 60+ Kb should be managed by this, which is not overwirting all released blocks.

    3. Re:Does the "fix" include scrubbing? by Animats · · Score: 1

      Ignoring the performance hit with this (that many application won't take)

      Clearing recently used memory is cheap, because it's in the cache. Clearing memory in general is cheap on modern CPUs, because the superscalar features do it really well. MOV is 35% of instructions, so CPUs are designed to do it efficiently.

      It's security code. You have to scrub memory.

  25. Re:NSA put the bug there, of course they exploited by hawguy · · Score: 1

    We need to find out if the author of this bug is or was on the NSA payroll. It would not be surprising to find out he was paid to put it there.

    The author responsible for the bug has already admitted that it was a mistake (and it's not like buffer overflows are unheard of, so it really is plausible). Sure, it's possible that the NSA secretly paid him (or ever coerced him by holding some incriminating evidence over his head), but it would likely take someone with the resources of the NSA to uncover such a secret NSA payout. Something of that nature probably wouldn't even be available in Snowden's document archive.

  26. Re:It's not a bug by Anonymous Coward · · Score: 0

    Does it matter?, its reported the NSA have been using it but who else has who didnt get their fingers caught in the cookie jar has?

  27. We fixed the glitch. by mythosaz · · Score: 1

    Bob Porter: We always like to avoid confrontation, whenever possible. Problem is solved from your end.

  28. Re:It's not a bug by Anonymous Coward · · Score: 0

    Hi NSA!! get the fuck OUT OF MY COMPUTER. kthnxbai.

  29. According to who? by radarskiy · · Score: 3, Insightful

    Bloomberg is the reporting organization, so they can't bee the source. They name no sources, just "two people familiar with the matter", which could mean they asked me twice.

    1. Re:According to who? by Anonymous Coward · · Score: 0

      "people familiar with the matter". That's standard language for anonymous sources.

  30. Re:It's not a bug by Arker · · Score: 3, Interesting

    Maybe, of course we cannot just believe them after seeing them repeatedly lying to Congress, but it strikes me likely in this particular case they are telling the truth. This bug, unless I am misunderstanding, essentially lets you read from a small contiguous pseudo-random block of memory. That's obviously not acceptable from a defender point of view - it could potentially expose any and all information so it's a severe flaw - but from an attackers point of view it seems less impressive.

    You could probably try this thousands of times without actually obtaining any information of value. Sure, you might luck out and get the keys to the kingdom, but it seems like a crapshoot. From an attackers point of view, this might be better than nothing, but unless they have pretty near nothing to start from, it does not seem exciting.

    And we know they have a lot more than nothing to start from. With Total Surveillance in effect on the net, with rootkits and zero-day exploits to deliver them, it's just really hard to see how this would add anything substantial to their toolkit.

    No, I suspect this is exactly what it appears to be - a critical bug resulting from too much emphasis on fast and not enough on good. That's hardly unique to OpenSSL, it's a chronic problem across the industry as a whole.

    --
    =-=-=-=-=-=-=-=-=-=-=-=-=-=-
    Friends don't let friends enable ecmascript.
  31. I feel the NSA can do some good. by Anonymous Coward · · Score: 0

    I imagine we could do that if we stopped with domestic and allied spying. By that I mean searching for vulnerabilities in the software we use and alert the proper companies in order to fix them.

    1. Re:I feel the NSA can do some good. by ComputersKai · · Score: 1

      The problem is, they will keep using the "National Security" excuse to justify their actions, as well as wording their responses to the general public in meaningless doublespeak. At the current stage, they seem to be utterly brainwashed in their own sewage, and the government unfortunately seems to be drinking in more of their trash everyday.

  32. Re:It's not a bug by bob_super · · Score: 1

    National Spying agency...

    They do provide the right companies with expertise on security for securing important technology, and justifying compliance to said recommendation for sale of sensitive products. I don't know how many of the 40000 employees do that, but that's one "Security" feature that they _do_ offer.

  33. Re:It's not a bug by the+eric+conspiracy · · Score: 1

    When the NSA ceases to exist, it will be because they are adsorbed by something bigger and more powerful.

    Look at the KGB. They were adsorbed by the Russian Oligarchy.

  34. Highly likely that NSA knew early on by JKAbrams · · Score: 3, Interesting

    Actually I wrote this yesterday but was unable to publish it:
    ...
    I have not yet grasped the full scope of the implications of this bug, but if you take the stance that things that could have been done also has been done (imho the only safe assumption), is this a good characterization? Or are there any limiting factors that makes this impossible? Like for example the amount of memory that could be leaked while the application is running (as servers aren't restarted often) is certain information that is stored statically in memory potentially not reachable?

    During the last two years:
    1. Any/all certificates used by servers running openssl 1.0.1 might have been compromized and should be revoked (the big cert-reset of 2014?)
    2. Because of 1, any/all data sent over a connection to such servers might now be know by a bad MITM (i.e. for large scale: the various security services/hostile ISPs, local scale/targeted attacks: depends on who else happened to know, and this person/organization happened to be your adversary, looks unlikely, but who knows...)
    3. Any/all data stored in SSL-based client applications might have been compromised.

    From a users perspective - change all passwords/keys that has been used on applications based on openSSL-1.0.1? How to know what services? To be safe, change them all? Consider private data potentially sent over SSL to be open and readable by the security services?

    Thinking about the large-scale:
    For how long has the NSA been picking up information leaked by Heartbleed (assuming that they have at least since late evening the 7:th or early morning the 8:th seems a given)?
    -Not in the Snowden documents that has been revealed so far (absence of proof != proof of absence, but language might give a hint)
    -No report of unusual heartbeat streams being spotted in the wild (was anyone looking?)

    Let's assume for the sake of argument the NSA does not have people actually writing the OpenSSL code in the first place.
    When did they know about it's existence?

    time_to_find_bug = budget * complexity_of_bug / size_of_sourcecode * complexity_of_sourcecode * intention_to_find_bugs

    Where
    budget = manpower * skillset
    and
    time_to_find_bug < inf.
    when
    skillset >= complexity_of_bug

    Heartbeat bug:
    complexity_of_bug = low

    OpenSSL:
    size_of_sourcecode = 376409 lines of code (1.0.1 beta1)
    complexity_of_sourcecode = high

    NSA:
    intention_to_find_bugs = 1
    budget = $20 * 10^9 ?
        => manpower = 30k ?
           skillset = high

    Guesstimate: one to a few months -> early 2012 to go through the changes made to 1.0.1 building on earlier work already done on the 0.8.9 branch...
    ...
    Or to say it another way, I think it is safe to assume that, given the simplicity of the bug, NSA knew about Heartbleed in early on. The anonymous comments to Bloomberg gives nice confirmation of this.

    1. Re:Highly likely that NSA knew early on by JKAbrams · · Score: 1

      Typo, meant the 0.9.8 branch of SSL of course.

    2. Re:Highly likely that NSA knew early on by l0n3s0m3phr34k · · Score: 1

      I know that at my company we don't "restart servers" as much as re-deploy another VM instance, switch all trafrfic to that, then kill the old VM. Yet sometimes it is over a year between reboots of the actual ESX servers themselves, as they are sometimes hosting dozens of VM's on a single box.

    3. Re:Highly likely that NSA knew early on by Anonymous Coward · · Score: 0

      for the purposes of this exploit, re-deploy vm = restart

  35. Re:NSA put the bug there, of course they exploited by rmdingler · · Score: 1
    You are probably correct. Still.

    Heinlein's but don't rule out malice still applies.

    Look. I get that the NSA has these incredible resources (thousands of personnel, alone), but they're still all working for the government: the king of big company bullshit with a side of no incentive to work hard. I'll kiss a pimple on your ass if there aren't many hundreds of others' disenfranchised like Snowden who lack either the luxury of being able to leave or the courage to do so.... these folks commitment is plausibly not legendary.

    If they can buy a guy in on the production side of the coding, it just saves a lot of work.

    --
    Happiness in intelligent people is the rarest thing I know.

    Ernest Hemingway

  36. NSA.gov gets an F by Anonymous Coward · · Score: 0

    They can't even pass basic SSL security tests on their websites. Nor can FBI.gov, FDIC.gov, IRS.gov, VISA.com, MASTERCARD.com or PCISECURITYSTANDARDS.org

    Absolutely amazing that something as basic as their public facing websites all fail with an F

  37. Cisco and IBM by Anonymous Coward · · Score: 0

    I would expect that Cisco and IBM work hand in hand with the NSA, embedding crypto backdoors and wiretapping capabilities in their products.

  38. Re:NSA put the bug there, of course they exploited by Anonymous Coward · · Score: 0

    What is to say the author wasn't offered $10 million to "accidently" put the bug in the code similiar to what happened at RSA? The NSA probably even coached him on what to say when the bug gets discovered.

  39. Re:It's not a bug by Johann+Lau · · Score: 2

    Yeah, empires never fade, and always get replaced by bigger ones.

    So don't look at dinosaurs, and the tiny mammals that survived them, and surely not at entropy, which is breaking everything down to energy and then smearing that around, slowly, patiently, irreversibly. Do not realize that the universe is a joke at the cost of anyone who likes (to keep) power, that having lots of materials and commanding people around or killing them does not constitute power more than a fart constitutes a solid object, and is but a compensation price born out of delusion. Ignore that a chain binds the master more than the slave, and while it kills the master in an instant, it kills the slave much later or never.

    The KGB, the NSA, the Russian Oligarchy, and so on -- all of them already lost, they are but empty husks propped up by smaller empty husks, all life and all reward is taking place in the blind spots, in the wrinkles and niches. The all seeing eye is utterly blind, it does not see the wood for the trees. It will take up last to the joke, and until then it attracts greedy, sadistic, and impotent people, acting as a sinkhole for the weakest humanity has to offer. It's always been thus. Powermongers never experience greatness themselves, but sometimes force their subjects into it. It's a joke at their expense on more than one level.

  40. Gomes is looking for consulting work by Anonymous Coward · · Score: 0

    I'll raise his tinfoil hat concern about "oh no, it's open people might see the open window" with my tinfoil hat concern of "it's hidden in a dark alley, no one will see the crack den in the basement because no one else can see the doors or windows".

  41. Re:NSA put the bug there, of course they exploited by davidhoude · · Score: 1

    The bug seems quite obvious. I would expect they could be a little more clever if they were to write the bug itself. This is failure of the OpenSSL project, period.

  42. Re:It's not a bug by hereschenes · · Score: 1

    The fact that they didn't tell anyone though shows that the S is NSA is bullshit.

    Wouldn't that be the NBA? Interesting mashup there.

    LeBron James: athlete, sycophant, spy.

    --
    More like... nerdular nerdence!
  43. Re:It's not a bug by arobatino · · Score: 1

    The fact that they didn't tell anyone though shows that the S is NSA is bullshit. They cared more about being able to exploit the vulnerability themselves than making their country's computers more secure.

    It's a basic conflict of interest with police/defense/intelligence agencies. They gain power from the existence of threats, so it's in their self interest to favor policies that perpetuate them while pretending to do the opposite. The War on Drugs, Cuban Embargo, etc.

  44. Re:It's not a bug by thoth · · Score: 0

    The fact that they didn't tell anyone though shows that the S is NSA is bullshit. They cared more about being able to exploit the vulnerability themselves than making their country's computers more secure. If they cared one shit about their country's security then they'd have big teams dedicated to finding software vulnerabilities and working with vendors to fix them.

    You are confused as to what NSA's "defensive" mission is. They aren't there to be the defenders of the internet. They aren't there to be corporate America's QA department. They aren't there to review open source and provide fixes. They aren't there to "make the country's computers more secure".

    They are there to protect DoD classified systems. That's the defensive mission, as an agency under the DoD umbrella. Protect DoD classified systems and anything that deals with military activities. All this extraneous whining - none of it is their mission.

    It's a simple calculation on their side as far as the defensive mission - does "vulnerability X" involve classified DoD systems or ones that have military information? No? NOT THEIR PROBLEM.

    Don't like it? Well too bad, you don't get to gripe when they don't follow their mandate and also gripe when they do.

    If you want to complain, take that up with congress or the president to alter their mandate/directive. Or, take it up to congress to provide more funding for the agencies that are actually supposed to be looking out for commercial internet use and regular gov sites - NIST and DHS. Or, lobby congress to create a fully civilian non-DoD agency that's there to provide an extra security layer for the world at large. And in that last case, don't bitch about the government spending money when clearly the free market is failing to provide a solution, since it appears greedy for-profit corporations are happy to use but not contribute any resources towards this critical software infrastructure.

    With the constant complaining about them and government in general from all the anti-government libertarian neck beards here, why would they even bother producing a fix? Who would trust code they released? This would not be like the selinux release, which is optional and provided new capabilities - if they produced a fixed openssl nobody would use it until code reviewing for years. They'd spend more time with PR and a ton of bullshit than doing nothing at all which is free from their perspective. If they disclosed the bug, they don't have any power to compel "the internet" to upgrade to a fixed version, so they'd be blamed for exploits and vulnerabilities during the time servers were slowly upgraded.

    Whatever they do, somebody would gripe and given it ISN'T THEIR JOB in the first place, doing nothing looks like the game-theory resulting best call.

  45. I don't know how i fell, by Anonymous Coward · · Score: 0

    As a tax paying sheep I fell it's their Job to use everything at their dispose,

  46. CloudFlare are experts at marketing by Anonymous Coward · · Score: 0

    In the report they published, it really just says that when trying to exploit Hearbleed on their OWN infrastructure with openssl + modified nginx they could not obtain public keys. That's all.

  47. Heartbleed Challenge Over by xvx · · Score: 5, Interesting

    Welp, that didn't take long. Looks like someone solved CloudFlare's Heartbleed Challenge and got their private server key...

    1. Re:Heartbleed Challenge Over by Anonymous Coward · · Score: 0

      It is now time to kill all certificates which were issued before Heartbleed. Browsers in particular should be patched to reject all certificates issued before a cut-off date, let's say 2014-04-20, from one week after that date onward. Don't wait until everybody has voluntarily revoked their certificates. Many won't, and certificate revokation is still badly broken. And make PFS mandatory, FFS.

    2. Re:Heartbleed Challenge Over by PhunkySchtuff · · Score: 1

      For some reason I can't get to that page (DDOS'd? Taken offline?)

      Here's the results on their blog:
      http://blog.cloudflare.com/the...

  48. Re:NSA put the bug there, of course they exploited by l0n3s0m3phr34k · · Score: 2

    lol...Maybe he was sent a stack of cash with a USB flashdrive and a note "You know what needs to be done. Love, NSA"

  49. Re:NSA put the bug there, of course they exploited by l0n3s0m3phr34k · · Score: 1

    some clues might be buried in there somewhere, but until Snowden's "cache" is publicly released we'll never actually know...but I'm guessing The Guardian et al are currently combing through the archive looking for some references.

  50. Why has it not crashed the servers? by Cacadril · · Score: 2

    If the heartbeat message is stored in memory allocated near the top of the heap, then if the bug is being exploited, the server should be reading data beyond the top of the heap. If this bug has been extensively exploited, why have we not seen servers crashing every now and then? Or have we seen it?

    --
    There is no substitute for common sense. Especially, no body of rules will do.
  51. NSA Mandate by Anonymous Coward · · Score: 0

    The National Security Agency was created to:

    1) engage in Espionage,
    The Espionage will be used by the President of the United States and or a Department on His Behalf.

    2) engage in Blackmail,
    The Espionage will be used to Blackmail National and Foreign Governmental and Non-Governmental Persons at the Pleasure of the President
    of the United States of America or HIS departmental representatives for the expansion of the United States of America and the Expansion of the wealth of the President of the United States of America.

    Sig Heil

    Sig Heil

    Sig Heil

  52. Re:It's not a bug by Anonymous Coward · · Score: 0

    The first thing I did when I read this story was email my congress person. Not that it will help do anything but let the NSA know where I am...

  53. Failure of risk analysis by more than OpenSSL devs by Goonie · · Score: 4, Informative

    Just a minor correction - my piece does indeed suggest that the OpenSSL developers have some strange priorities. However, it lays the larger blame at the companies that used OpenSSL, when all the information necessary to suggest that this kind of thing could happen was already available, and the potential consequences for larger companies of a breach are easily enough to justify throwing a little money at the problem (which could have been used any number of ways to help prevent this).

    --

    Any sufficiently advanced technology is indistinguishable from a rigged demo
    --Andy Finkel (J. Klass?)
  54. Obfuscated Variable Names by Sanians · · Score: 3, Informative

    I challenge anybody to review it and find (or notice) the bug.

    It's actually kind of easy to see. I just use the same trick I use when trying to read almost anyone's code: I assume that some jackass obfuscated all of his variable names and so I rename them as I figure out what they actually represent so that the new names actually describe the variable. Once that's complete, I'm left with "memcpy(pointer_to_the_response_packet_we_are_constructing, pointer_to_some_bytes_in_the_packet_we_received, some_number_we_read_out_of_the_packet_we_received)" and it immediately raises a red flag.

    ...but more seriously, the code in that check-in is why I hate to let anyone work on any programming projects with me. Worthless variable names create code that's as worthless as English text that refers to everything as "that stuff" and "those things." It's just a step away from choosing purposefully obfuscated variable names. If the variable is named "payload" then not only should it be the actual payload data, rather than just its size, but it should also be the only payload in existence such that no distinction needs to be made between "received_payload" and "payload_to_be_sent." ...and then there's the single-letter variables, some of which are incremented at times so that they don't even consistently refer to the same thing over time, creating a variable that not only doesn't indicate what it refers to, but one which actually might refer to anything.

    I've read that the reason there's a packet length sent from the remote host is because this data is sent with random padding bytes added to each packet and so the packets need to indicate how much of the data is actually valid. So why isn't the packet size figured out closer to when the data first enters the program? First thing I would do when receiving a packet is read out this packet size, verify that the actual size of received packet is large enough to contain it, and toss the packet if it wasn't large enough since it was obviously corrupted (or malicious). Then I'd write the size into a structure for the packet's meta-data, along with any other data we find in every packet (like a packet type number), and every other part of the entire program would read the data from that structure. That's how you do these things. Everything received is "tainted" and, once you verify it isn't poisonous, you move it out into a data structure that the rest of your program trusts. Otherwise you have every piece of code that needs that data having to verify it every time it accesses it which just creates enormous opportunity for error.

    So when you come across code like this which pulls data out of the packet and just uses it, it isn't just wrong, but it doesn't even resemble anything that might be correct. Thus, the poor variable naming just might be why this wasn't noticed. Since the data pulled out of the packet is stored into a variable named "payload" it's easy to imagine it's simply payload data, which doesn't have to be checked as it won't ever be used for anything other than being returned to the remote host, and so the absence of code that checks the validity of that data might be expected. If it were named even something as ambiguous as "payload_size" then you have to immediately wonder if it's a size that needs to be checked against anything when you see it being pulled out of a buffer of untrusted data. ...but then, you don't see that either, since the pointer is named "p" which doesn't scream "this is untrusted data" and, even if you look above to see that "p" was assigned from "&s->s3->rrec.data[0]" you're still left wondering what the fuck that might be. Maybe "rrec" refers to some sort of received record? Fuck, who knows.

    I mean, right after the memcpy I see "RAND_pseudo_bytes(p, padding)." Is this even putting the padding bytes in the correct place? Well, "p" could be a pointer to anything so it's pretty easy to assume it could be correct. Hel

    1. Re:Obfuscated Variable Names by phantomfive · · Score: 1

      I just use it because I hate everything else even more.

      So true

      ...but more seriously, the code in that check-in is why I hate to let anyone work on any programming projects with me.

      You can teach them how to do better.

      --
      "First they came for the slanderers and i said nothing."
  55. Private key compromise is indeed possible by pop+ebp · · Score: 4, Informative

    CloudFlare has retracted their statement that private key compromise is very hard. They started a challenge and at least 2 people successfully got private keys from their Heartbleed-enabled server with as few as 100K requests. (I am sure that with some optimization, the number could be even lower.)

  56. So the keys leak too by Anonymous Coward · · Score: 0

    Sort of related. Seems like multiple independent sources have verified the key leakage. There seems to be article here.

    So what does this mean? Assuming NSA has been collecting traffic from teh internet, and meanwhile been harvesting private keys from affected services since 2 years a go, then all that data is readable to them as in there had been no encryption to begin with (assuming no PFS etc). And meanwhile the sites are waiting to get new certs, they still can. And they can set up intercepting proxies with 'real' keys from the website they are masquerading as.

    What all this is saying -- heed the warnings. Revoke and update your certs, have users change password. Carry on.

  57. Snowden by kyrsjo · · Score: 1

    Has there been any cases where the leaked information has been usefull in pointing out flaws which lead to patching security holes?

  58. Lots of truth but also some wishful thinking by Paul+Fernhout · · Score: 1

    As I'm too often involved in myself sometimes: :-)
    http://www.pdfernhout.net/on-d...
    "This approximately 60 page document is a ramble about ways to ensure the CIA (as well as other big organizations) remains (or becomes) accountable to human needs and the needs of healthy, prosperous, joyful, secure, educated communities. The primarily suggestion is to encourage a paradigm shift away from scarcity thinking & competition thinking towards abundance thinking & cooperation thinking within the CIA and other organizations. I suggest that shift could be encouraged in part by providing publicly accessible free "intelligence" tools and other publicly accessible free information that all people (including in the CIA and elsewhere) can, if they want, use to better connect the dots about global issues and see those issues from multiple perspectives, to provide a better context for providing broad policy advice. It links that effort to bigger efforts to transform our global society into a place that works well for (almost) everyone that millions of people are engaged in. A central Haudenosaunee story-related theme is the transformation of Tadodaho through the efforts of the Peacemaker from someone who was evil and hurtful to someone who was good and helpful."

    But more seriously, there are a lot of fine dedicated well-meaning people who work at three letter agencies. There are no doubt a lot of not-so-fine ones too. Any big bureaucracy has complex and often self-perpetuating social dynamics. If such places are to improve, IMHO one needs to support and encourage the fine people there and hope their actions can outweigh the not-so-fine ones. For example, IMHO Tom Armour was one of the finer ones:
    http://pcast.ideascale.com/a/d...

    Saying the KGB, the NSA, the Russian Oligarchy and so on are empty husks is a bit like saying capitalism is full of contradictions and unfairness and so it will fall apart on its own. I've said such things myself sometimes:
    http://www.pdfernhout.net/post...
    "Wikipedia. GNU/Linux. WordNet. Google. These things were not on the visible horizon to most of us even as little as twenty years ago. Now they have remade huge aspects of how we live. Are these free-to-the-user informational products and services all there is to be on the internet or are they the tip of a metaphorical iceberg of free stuff and free services that is heading our way? Or even, via projects like the RepRap 3D printer under development, are free physical objects someday heading into our homes? If a "post-scarcity" iceberg is coming, are our older scarcity-oriented social institutions prepared to survive it? Or like the Titanic, will these social institutions sink once the full force of the iceberg contacts them? And will they start taking on water even if just dinged by little chunks of sea ice like the cheap $100 laptops that are ahead of the main iceberg?"

    Yet capitalism is still here and seemingly stringer than ever (as far as control of the US political machinery). And may well be for some time as the underlying power system morphs into new forms. Ancient China went hundreds of years at a stretch with peasants suffering all sorts of things, especially famine, and not much changing. Yet, something like a "basic income" might be a step towards improving capitalism even if it would not fix everything about it (the worst of consumerism, addictions, waste, short--term planning, systemic risks, externalities, etc.).

    Short-term power in human societies also translates itself into sexual access and the spread of genes (e.g. Bill Clinton, theoretically). The best we can perhaps due as a society is structure how the competition for mates plays out in our society, as in what is valued. James P. Hogan wrote about that in his sc

    --
    A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
  59. Finally! by Toad-san · · Score: 1

    "and today's xkcd has the "for dummies" depiction of how it works."

    Thank you, thank you, thank you! At last I get it. So simple. So fiendishly simple.

  60. Re:NSA put the bug there, of course they exploited by Anonymous Coward · · Score: 0

    The "forthcomingness" of the bug's author is the thing that makes me the most suspicious. It almost feels like he's gloating, "whoever slipped in such a plausible human mistake as a backdoor must've been brilliant, but hrrhrr I wasn't on the BND's payroll until much later, so it couldn't have been me, could it?"

  61. "two people familiar with the matter" by Anonymous Coward · · Score: 0

    Bloomberg says, "two people familiar with the matter" and we all buy it? Common, this isn't "proof" of anything.

    So let me get this straight. Let's assume the NSA discovered the bug two years ago and has actively been exploiting it. They've also made a decision to "keep quiet" about it, due to "National Security" interests. There are several issues with this theory.

    For one, this would mean that they knowingly left US assets vulnerable. That is, the FBI, DOE, CIA (?), State/Local Policy, Military, US companies, infrastructure computer systems, etc. would have been vulnerable to this attack. However, the NSA found the flaw so awesome, that they decided it would be better to just leave the bug out there and _hope_ that nobody discovers it.

    The second issue, the NSA found it and _knows_ we're just as vulnerable as anyone else. They now gamble that nobody else is as smart as them to discover it as well. We are all aware that other countries have intelligent agencies, right? The NSA just "hopes" that the Russians doesn't figure it out.

    Then a small Finnish security firm discovers the bug.

    It is very possible that the NSA might have been exploiting this flaw. However, gut feelings and handwaving about the NSA every single time a software flaw comes up doesn't help the issue. "Two people familiar with the matter" is crap. That just about describes everyone on Slashdot. It's complete nonsense. There is no context for how these "two people" are "familiar with the matter". This is not even journalism.

    If the article stated that someone found a packet capture (pcap) PRIOR to Apr 2014, that _WOULD_ be alarming. That would _show_ that some one (criminals? NSA?) had been exploiting the flaw. If the NSA admitted to it, that would be interesting.

    In the mean time, keep your "two people familiar with the matter" bullshit to yourselves until you have proof.
     

    1. Re:"two people familiar with the matter" by sharknado · · Score: 1

      I have it on good authority that those two people are Santa Claus and Jesus.

  62. Re:NSA put the bug there, of course they exploited by ceoyoyo · · Score: 1

    The author of the bug probably introduced it accidentally. It's easy to do. The author of the special wrapper code in openSSL that purposely prevents newer versions of malloc from doing memory checking that would have revealed this bug a little more suspicious.

  63. Re:It's not a bug by DedTV · · Score: 1

    Of course they're telling the truth. They just aren't telling the whole story.

    "No, we didn't exploit the Heartbleed bug. You're accusing us of stealing a Ford Focus when we've got garages full of Ferraris and F-16s. Puh-lease! Why would we bother exploiting something that gives such rudimentary and fleeting access to data and could just as easily be used by the Chinese or Russians when we have the espionage skills and resources available to us to install our own secure backdoors that only we can use and give ourselves full, unrestricted access to everything on any system we want access to?"

  64. Re:It's not a bug by the+eric+conspiracy · · Score: 1

    Since the dawn of man the size of political units has always been increasing.

    Family
    Band
    Tribe
    City
    State
    Nation
    World Government(?) (If we don't have nuclear war first)

  65. But the NSA continues on by ComputersKai · · Score: 1

    The thing is, while there is much outrage, not much is being done about those violations either. Just like in 1984, instead of choosing to fight for their rights, the masses instead chose to make the best of things. This is a disappointing path we are taking in our growth as a nation.