Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I might be a contrarian, but I think it makes sense for the NSA to hoard 0-days. They should disclose only after they burn them.


You're only a contrarian on message boards. The economics of CNE SIGINT are so clear --- you'd be paying integer multiples just in health benefits for the extra staff you'd need if you replaced it --- that vulnerabilities could get 10x, maybe 100x more expensive and the only thing that would change would be how lucrative it was to be a competitive vuln developer.

A lot of things can be understood better through the lens of "what reduces truck rolls".


Any 0-day found by an NSA employee can and will be found by someone else, and then sold or used.


In theory, I agree. In practice, how do you explain how NSO Group kept the secret for the 0-day exploit for WhatsApp remote execute for its Pegasus product? Or do I misunderstand Pegasus? Maybe it isn't a one trick pony, but a platform to continuously deliver 0-day exploits.


The VEP is literally based on that premise.


Right, I think we agree?


Well, I'm just saying: the preceding comment believed themselves to be a contrarian for thinking it was OK for NSA to have these vulns, and it looked like you were rebutting them. But your rebuttal, if that's what it is, restates a premise NSA shares.


The meaning I took from that comment is that the NSA should always keep any 0-day it finds indefinitely until it uses them. That's what I think "hoard" and "disclose only after they burn" means. It's a mindset of keeping everything you find secret because you might want to use it someday.

My understanding of VEP is that the default is supposed to be to disclose immediately unless an agency has a really good reason not to, presumably because they want to use it soon. Don't hoard, only keep things that you're actually going to use.


For clarity: the word "hoard" to me signals the idea that NSA keeps dozens of duplicative exploit chains around. The public policy rationale for them doing that is to me clear, but my understanding is that the practical incentives for them to do that aren't clear at all.

When I say "burn", I mean that something has happened to increase the likelihood that an exploit chain is detectable. That could be them being done with it, it could be independent discovery, it could be changes in runtime protections. It's not "we use it a couple times and then deliberately burn it", though.

We should stop talking about "NSA", because this is basically a universal LE/IC practice (throughout Europe as well).


The NSAs charter should be to secure this country and not attack others.


That organization exists, and it is called the FBI.


I mean, NSA has a directorate for it too, but it's not the agency's chartered purpose.


That is literally the opposite of why NSA exists.


I think "literally the opposite" is incorrect.

Their charter was to take over COMINT from the military into a new joint administrative agency. Their work includes securing communications between allies as much as it does breaking communications from our belligerents. This work necessarily provides them with the types of knowledge and experience that would be highly valuable in securing infrastructure against similar attacks.

Likewise they've involved themselves in both improving and harming civilian cryptography systems and research for years. They're a complex agency and the value of COMINT can be realized under many different root paradigms. It's absurd to think otherwise.


NSA was chartered to break the codes of foreign powers.


That's one aspect of COMINT. I use this term because NSA's charter, such that it exists, uses this term.


Their primary mission is intrinsically offensive and always has been.


You can't actually hoard them, though. They aren't objects, they are knowledge.

A 0-day is present in every instance of the software it can exploit.


This is a meaningless distinction imo

You hoard knowledge by writing it down somewhere and then hoarding the places it's written down. Whether that's books, microfilm, hard drives, what have you


You can't stop someone else from writing it down.

When you hoard something, your possession of that thing effectively takes access to that thing away from everyone else.

You can't keep access to a vulnerability away from anyone!



That's definitely the downside in the trade-off, yeah. If you're going to hoard you better also protect or you just get the worst of all worlds. Still, I am generally hopeful about our intelligence agencies' ability to prevent leaks, even if fuckups have occurred.


That's not the real downside. If it were, you'd be seeing mini-"shadow brokers" leaks every month, because the practice we're talking about here is extremely widespread: the economics of being a zero-day broker hinge on being able to sell the same exploit chain many, many times to the same country, and to get recurring revenue each such sale.

The real downsides here are probably economic and have to do with how this shifts incentives for everybody in the industry. But, at the same time, every big tech company with a desktop/mobile footprint has invested mightily on staff to counter LE/IC/foreign CNE, which is something that might not have happened otherwise, so it's all complicated.

People write as if the disclosure of a bunch of IC zero days is like some kind of movie-plot "Broken Arrow" situation, but it's really mostly news for message boards. Organizations that need to be resilient against CNE are already in a state of hypervigilance about zero-days; adversaries absolutely have them, no matter what "NSA" does.


Yeah, because intelligence is famously a discipline where nothing ever goes wrong.


OK, hoarding discovered zero-days might not be the best strategy, BUT if we actually create a backdoor and don't tell anyone about it, then this should be safer right? right? /s

https://www.wired.com/2015/12/researchers-solve-the-juniper-...

https://en.wikipedia.org/wiki/Dual_EC_DRBG

https://en.wikipedia.org/wiki/Juniper_Networks#ScreenOS_Back...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: