
The Government Uses Zero Days for “Offense” - DiabloD3
https://www.eff.org/deeplinks/2015/11/its-no-secret-government-uses-zero-days-offense
======
drham
91% could also pretty misleading because not all vulnerabilities are equal.
It's easy to let 9 potential segfaults or memory corruption issues get
disclosed if you get to hold on to the 1 iOS Zero Day/Shellshock type
attack/etc...

~~~
nickpsecurity
You beat me to it, haha. I was going to make the point that the vast majority
of bugs found don't do anything significant for a hacker. A program crash or
corruption at worst. It wouldn't surprise me if NSA just discloses the ones
that hurt availability while weaponizing the few hitting confidentiality or
integrity.

------
onewaystreet
Does the EFF really expect the NSA to publicly detail every time they've used
an exploit offensively?

~~~
facetube
Against Americans? Yes. The rule of law demands it.

~~~
acdha
That point is so important that I hesitated to add a distraction but I think
it's also worth remembering that the NSA has a defensive role, too.

It's been much neglected in recent decades but the entire country would be
better off if the NSA helped patch things. They're hoping some suspected bad
guy doesn't get patched but odds are high that many Americans, particularly
important IP-heavy businesses, are going to get exploited as well — and given
all the reports about how e.g. bin Laden preferred to send messages using
trusted couriers, that trade off doesn't seem very good.

~~~
peteretep
Are you seriously suggesting you don't think the security services have
decades of experience in weighing the pros and cons of information release?

~~~
frozenport
Whats good for one agency may be bad for another, for example the State
Department might like Tor because it facilitates anonymous informants while
the NSA might not like it because they can't read your email.

I am not even sure if the NSA's mission extends to defending civilians.

~~~
Ankaios
I'm not even sure it extends to defending the _government_.

At least not fully enough, given the OPM breach.

------
Animats
Now the question is, are vendors deliberately putting in security flaws at
NSA's instigation?

Intel's "system management mode" and code need to be viewed with extreme
suspicion. So do network controllers which accept management commands from the
network side. It would be so easy to add some system management passwords to a
network controller that don't show up when you list them. (In fact, if you're
willing to have them show up in a list that nobody ever checks, you can insert
a backdoor in a motherboard if you can get hold of it anywhere in the supply
chain, hook it up to power and Ethernet, and talk to it briefly.)[1]

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

~~~
eliteraspberrie
I doubt the NSA needs to instigate much. There is so much bad code in the
world, and it just keeps growing, they would be in business forever just
sitting on their thumbs.

~~~
davidgerard
The Onion: China Unable To Recruit Hackers Fast Enough To Keep Up With
Vulnerabilities In U.S. Security Systems
[http://www.theonion.com/article/china-unable-recruit-
hackers...](http://www.theonion.com/article/china-unable-recruit-hackers-fast-
enough-keep-vuln-51719)

------
nickpsecurity
It's good news to me. The NSA's mission means they're going to have to get in
_somehow_. FBI, too. Bulk collection and subversion have huge issues. Targeted
collection with 0-days in endpoints that we know are insecure is much closer
to Constitution than most of what they do. If people want that to go away,
they could always apply methods for building secure systems from ground up.
I've posted plenty here and elsewhere about high assurance security along with
tons of Comp Sci and case studies existing.

If not, they've chosen to accept that risk from NSA and others hunting 0-days.
Most choose that. Most platforms have tons of risk and attack surface. So, I'm
all for them collecting 0-days for focused attacks and relying on it rather
than pushing subversion or L.I. harder.

Anyone worrying about this should be focusing on the organizations creating
0-days with known-insecure development practices rather than those exploiting
them. They're the problem and the demand side (users/customers) that doesn't
give a shit. Excerpt from a counterpoint to Bruce Schneier on why
users/customers, not manufacturers, were the problem in terms of security of
our devices and services:

"Why does this problem (insecure everything) exist? Because manufacturers
don't focus on building secure systems. Why don't they build secure systems?
_BECAUSE USERS DON 'T BUY THEM_!

Most users want the risk management paradigm where they buy insecure systems
that are fast, pretty and cheap, then occasionally deal with a data loss or
system fix. The segment of people willing to pay significantly more for
quality is always very small and there are vendors that target that market
(e.g. TIS, GD, Boeing and Integrity Global Security come to mind).

So, if users demand the opposite of security, aren't capitalist system
producers supposed to give them what they want? It's basic economics Bruce.
They do what's good for the bottom line. The only time they started building
secure PC's en masse was when the government mandated them. Some corporations,
part of the quality segment, even ordered them to protect I.P. at incubation
firms and reduce insider risks at banks. When the government killed that &
demand went low again, they all started producing insecure systems again. So,
if user demand is required and they don't demand it, who is at fault again?
The user. They always were and always will be.

On the bright side, those same users are the reason I can send photo's to
friends on a thin, beautiful smartphone. They also gave us short-lived 1TB
hard disks whose low cost made the short-lived part tolerable. They are also
probably why I have a full-featured, fast, cheap wireless router at the home.
So, at least some good comes from the users choices of demand. But, they
definitely don't accept the tradeoffs of real security, they don't demand it,
it doesn't pay to produce it, & that's why it's their fault. "

~~~
grecy
And you're cool with them doing it to _you_?

~~~
nickpsecurity
Yeah. If I used insecure crap, I've already decided that it will be destroyed
by opponents. If I want something safe, I use very secure methods to protect
it. That field is called high assurance or high robustness security. Quite a
few things in it stopped NSA pentesters. Very few of us left in that field but
one can learn from what's published as I did. Build your security strong,
obfuscated, and with tamper detection to give them real headaches. Otherwise,
you're enabling your enemy by your choice of systems, software, and methods.
It's your own fault given what you know of the world you live in.

Examples of high assurance thinking another comment:

[https://news.ycombinator.com/item?id=10529676](https://news.ycombinator.com/item?id=10529676)

Have fun with that rabbit hole. :)

------
xenadu02
Let's just keep writing operating systems and security-sensitive code in C.

I'm sure _this_ time we'll have even _better_ development practices. This time
we'll do better code reviews. This time the static analysis tools will catch
more problems.

If we all close our eyes and wish _really_ hard we can avoid inconveniencing a
few programmers, save a few CPU cycles, and keep using C. After all, the
performance is totally worth a few heartbleeds now and again ya?

~~~
notacoward
The issue is not _writing_ such software in some other language. The issue is
_re_ writing such software in some other language. That's a very very large
pile of functionality to implement all over again. In the process new bugs
will be introduced, including new security bugs. While it's easy enough to
write a toy system in some other language and get a paper published, a more
fruitful approach for making a _real world_ system secure is to do so
incrementally. Look at the L4 family of microkernels for an example.

------
graycat
Time for software vendors to plug the zero day holes.

More generally, need some assurances.

In addition, need some good zero day detection means.

