
NSA Said to Have Used Heartbleed Bug for at Least Two Years (2014) - ColanR
https://www.bloomberg.com/news/articles/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers
======
hannob
This was never confirmed with any evidence and bloomberg only cites anonymous
sources. Given Bloomberg's bad track record on infosec stories I say I have my
doubts.

Of course I don't know whether or not the NSA knew about Heartbleed. But
nothing that would even remotely qualify as evidence has ever been presented.

~~~
monocasa
As someone who has designed shipping HDL including more SPI masters than I can
count, and now works as a security researcher (among a couple other hats I
wear aty current job), I really think Bloomberg got dragged through the mud.

Everything they said about the BMC was plausible. It was bizzare hearing about
how such a scheme would literally break the laws of physics, when by accident
(read shitty, undebugged HDL) I've caused exactly what they were claiming.

~~~
mindslight
The problem with what Bloomberg reported was not that it was _implausible_ ,
but rather that it was _unsubstantiated_ as to whether the attack actually
occurred. If Bloomberg had narrated the article as "this _could_ happen",
attempting to explain a _possible_ attack vector, that would have been
fantastic.

I do agree there was a lot of "but SPI requires 6 wires and the slave can only
respond when talked to" (treating SPI with the assumptions of a design
engineer rather than an attacker), but that was ultimately just noise.

~~~
segfaultbuserr
Agree.

Remember BadBIOS?

* [https://en.wikipedia.org/wiki/BadBIOS](https://en.wikipedia.org/wiki/BadBIOS)

Same problem. EVERYTHING that Dragos Ruiu claimed is plausible, and it could
be a great cyberpunk plot written by Neal Stephenson. But there is ZERO
evidence that the malware actually exists.

And finding an actual incident in real life is much more important than
theoretical possibilities. For example, almost everyone knows that it's very
possible for semiconductor vendors to include a silicon-level backdoor since
the 1980s, but finding an actual Intel/AMD chip with such backdoor (not ME,
something like a secret instructions) is another matter.

~~~
Sephr
ME has a debug mode that might be possible to enable with a signal sent
through the 3.5mm jack on some laptops[1]. I'd be pretty concerned about ME
bugs and backdoors disguised as ME bugs.

1\. [https://youtu.be/xUJQps2-VWk?t=301](https://youtu.be/xUJQps2-VWk?t=301)

~~~
segfaultbuserr
I meant, finding a backdoor in its full form on the main system would be a
much more significant find, and its impact and newsworthiness is greater than
any hypothetical or baseless speculations, such as Bloomberg's BMC affair.

The impact of the BMC affair, if true, is showing real evidence and real
demonstration that such an attack has happened, has been used in the wild,
rather than showing that the attack is possible (we all know). Unfortunately,
bad journalism at work.

P.S: I'm not saying that the ME subsystem, or buggy speculation (pun not
intended) isn't a threat, just to make a point.

> _I 'd be pretty concerned about ME bugs and backdoors disguised as ME bugs._

Same consequences. I'd say they're effectively the same thing.

------
ngneer
This is 2019 and the security community has yet to deliver a proper solution
to prevent the existence of such bugs. The mismatch between programmer intent
and code behavior is appalling. Sure, super smart coders can avoid the bugs,
much like super safe drivers can avoid the shoulder, but rumble strips are
there for a reason. The bug would not have arisen if the language supported
dependent typing. See Agda, for example. One day...

[https://en.wikipedia.org/wiki/Dependent_type](https://en.wikipedia.org/wiki/Dependent_type)

~~~
cjbprime
> security community has yet to deliver a proper solution

What do you want them to do? I think their solution is "use memory-safe
languages like Golang or Rust (or even JavaScript/TypeScript) for new
projects, not C or C++" and "use extensive fuzzing on legacy C code that
hasn't been replaced yet".

Fuzzing was capable of finding Heartbleed, and it's advanced massively (and
been set up at scale to continuously test open source projects) since then.

~~~
z3phyr
Rust is pretty useful against memory based bugs, and it is prudent that new
projects take advantage of it. But this in no way fixes the headache of
security, because (1) almost all of the existing infrastructure code depends
on C (2) New classes of bugs will eventually emmerge, some partly unfixable by
software solution.

~~~
carlmr
>New classes of bugs will eventually emmerge, some partly unfixable by
software solution.

Sure Rust, ADA and such don't remove all classes of bugs, but they can reduce
the attack surface considerably, giving you more time to focus on the
remaining security bugs.

And maybe people will invent software solutions that reduce the attack surface
even more.

Assembly is a fast car with no security features. C is a sportscar with a
seatbelt. Rust is a sportscar with a seatbelt, airbags, ABS, ESC and emergency
breaking.

Of course you can still crash and die, it's just that you're less likely to do
so.

~~~
braindeath
> Assembly is a fast car with no security features. C is a sportscar with a
> seatbelt.

Given the ways you can trigger UB there is no difference between Assembly and
C with regards to safety.

~~~
eigenloss
Just type "undefined behavior" here. I'm sure you have the time.

------
ENOTTY
> The NSA has issued a statement denying the report. In an email to Ars, NSA
> spokesperson Vanee VInes provided this official statement: “NSA was not
> aware of the recently identified vulnerability in OpenSSL, the so-called
> Heartbleed vulnerability, until it was made public in a private-sector
> cybersecurity report. Reports that say otherwise are wrong.”

[https://arstechnica.com/information-
technology/2014/04/nsa-u...](https://arstechnica.com/information-
technology/2014/04/nsa-used-heartbleed-nearly-from-the-start-report-claims/)

~~~
burtonator
What's the legality of using a vulnerability to monitor someone if you have a
warrant?

Seems like it would still be illegal.

~~~
cm2187
Secret services are in the business of exactly doing illegal things on behalf
of the state. I think there is pretty much nothing in the daily business of
the CIA or the NSA that wouldn’t land an ordinary citizen in jail. Whether it
is to convince foreign officials to leak information, or bribe them, or plot a
coup, or assassinate enemies of the state, or intercept some communications,
etc. This is no different from any other secret service in the world.

The NSA is no more guilty than a fox in the henhouse is guilty of being a fox.

------
jokoon
So far the state of the computer industry is pretty simple, if you're using
american products, you're under american surveillance. Governments will always
seize the monopoly of security, that's how civilization works.

And even if you're using open source, I'm sure the NSA has written tools that
can scan source code to find vulnerabilities, and maybe generate exploit if
they sprinkled some ML on it.

To be honest I'd rather have a government body have the monopoly of security
than witness a cybersecurity chaos, which would quickly destroy the internet.
The problem is that only the US does it well.

~~~
mk89
> The problem is that only the US does it well.

The main difference with other countries is that we all know about NSA thanks
to what happened to people like Snowden, otherwise it would not be any
different from other countries -> pure speculation. And why would the US do it
better than countries like China, Russia or France?

~~~
jokoon
Because the US has the silicon valley, historically it invented the internet
and modern computers, the US holds most of the core tech companies (intel,
AMD, microsoft, google).

The US just have much more expertise and engineers, which is essential if you
want the NSA to recruit and be the best at what it does. It has many aspects,
I guess cerebral and technical capital are important notions.

Even if other countries can compete with the US on cybersecurity, the US is
holding most of the data but also is writing most of the software and
designing everything around computers, so it makes it trivial for them to turn
those products against other countries who buy them.

Except linux, I really don't see any computer product that doesn't have
critical parts or system made in the US. And as I said I'm certain the NSA can
exploit open source very easily since it's a problem with solutions: Torvalds
said "given enough eyeballs, all bugs are shallow". That is true, but if NSA
is supplying eyeballs to find vulnerabilities and use them at their advantage,
linux will be an asset for the US.

~~~
kelnos
> _The US just have much more expertise and engineers_

That's a pretty extraordinary claim that requires some evidence. I don't think
that's true at all.

------
harshvladha
If someone is not able to read article because Bloomberg asks for premium
fees, then don't miss out to check out their HTML ;)

------
OrgNet
I thought that we knew that they don't report bugs that they know about
(because they don't care about the greater good).

------
emmelaich
The weird thing to me is that heartbleed depended on a feature in TLS that
required the _server_ to _receive_ a request from the client specifying a
size.

Is there any other similar TLS feature?

Even if this is not the only one, wouldn't you audit the shit out of that?

------
paulcarroty
I don't fully trust Bloomberg, but there's funny thing: nobody hit them hard
in court. So, logically, it means a part of their materials are true and
evidences exists.

------
Railsify
Excellent, US government putting my money to work!

------
java-man
To this day I think it was a deliberately placed vulnerability. I don't have
any data to back it up, of course.

~~~
robocat
Your problem is that absolutely anything can be explained by a conspiracy.

This case was a few guys writing software in their free time - 100% likely it
was an honest mistake. See [https://www.buzzfeed.com/chrisstokelwalker/the-
internet-is-b...](https://www.buzzfeed.com/chrisstokelwalker/the-internet-is-
being-protected-by-two-guys-named-st)

~~~
nickpsecurity
What's funny about what you linked is a government demand led to the
vulnerability at a point when owners or main people were thinking of walking
away. A conspiracy around that would be more believable than most. Let's
ignore that, though.

The thing is, they add vulnerabilities in a number of ways. They can do it
directly with code. They can do it indirectly with standards hard to code
correctly w/out vulnerabilities or side channels. There's lots of options.
Whatever they do will usually look like a helpful contribution or useful
requirement that went wrong in a way that leads to an attack. The better ones
are those that look like common or inevitable errors. That's because obvious
backdoors make folks run away from a project or supplier maybe forever on top
of question who put it there. So, it's usually these flaws that look like
obvious errors that still get the job done with everyone around defending the
person that put them there.

And I'm not saying it was an NSA job. I have no idea. They've been doing too
good of a job on most things for me to know. Could've been an accident. Even
probability supports it's an accident just like it did all the times it was a
subversion. At $200+ mil a year budget for backdoors/hacking, you bet there
were a _lot_ of accidents that, in non-TS version, had nothing to do with the
NSA. ;)

Edit: There's lots of questionable things in this article. My favorite is
this:

"And this group are the best of the best of the best."

The OpenBSD team doing LibreSSL had all kinds of summaries, live updates, and
even presentations of what they found. It was about as far from that quote as
you could imagine. Although my memory sucks, I think at one point they said
there was even code that checked to see if endianness changed while it was
operating. They at least had _that_ covered. There were so many oddities about
that codebase.

~~~
peter_d_sherman
LibreSSL: More Than 30 Days Later
[https://www.openbsd.org/papers/eurobsdcon2014-libressl.html](https://www.openbsd.org/papers/eurobsdcon2014-libressl.html)

Not pretty to read from a security perspective...

But, on the other hand, quite eye opening, if you want to have your eyes
opened...

~~~
nickpsecurity
Thanks! I'll add it to book.arks for next time this comes up.

