Let's not forget that Sabu, while an informant for the FBI, supplied Jeremy Hammond with the 0day that he used to hack Stratfor et al.
No 0day, no Stratfor hack.
No FBI, no Stratfor hack.
Sometimes I wonder if penetrating other agencies and corporations was part of their gameplan. The FBI were entirely behind the formation of antisec.
Aside: Other interesting observation... The FBI and Apple seem to have an odd antagonistic relationship with one another. One of the Antisec hacks was against an FBI laptop that caused the release of millions of Apple users' data. The FBI was recording and debriefing Sabu every day. How did they allow that to happen?
And there's a chatlog where Sabu asked hyrrilya to give him (and I'm assuming by extension then Hammond, which he claimed in his defense) access to Stratfor.
Good correction though. I care a lot less about the technical details with this case than the social/sociopolitical ones.
Let's all accept a depressing fact: effective cyber-security places all of us in a state of perpetual war. You cannot learn from your enemy without invasive action, and you cannot test your capabilities without constantly attacking your adversaries, whether they know it or not. We cannot simply fork their nation's Github repo and try out zero-days in a safe and isolated environment.
We shouldn't be so quick to rail against government zero-day stockpiling. It is likely that other branches of government are using these flaws for their own means to monitor foreign states and other entities. If we give up that power we risk crippling our offensive capabilities more than we might stand to gain by having a stronger defense.
I cannot vouch for one side or the other. I am not a senior intelligence official and I do not have all the facts.
If you re-read my comment you will find nothing that suggests catastrophic cyber warfare is a major threat.
The real threat is a death of a thousand cuts. Trade secrets, troop movements, active spies, little snippets of information that can cause a lot of trouble if put in the wrong hands.
We don't accept this argument when it's turned on independent researchers. Researching vulnerabilities doesn't create vulnerabilities --- bad software engineering does.
Independent researchers usually disclose, yes? Hopefully responsibly.
There are no silver bullets. We're always going to have bugs, and bad ones that affect security.
Stockpiling of zero-days blurs the line between law enforcement and adversary. The greater good is probably served by disclosure, rather than surveillance, break-ins or advancement of the careers of prosecutors.
No, many researchers do not disclose. Every time Hacker News (incorrectly) takes the line that Facebook or Google isn't paying enough for a bug bounty, they're acknowledging that.
Then they're not researchers, right? I feel like "researchers" should be synonymous with white hats, and disclose to the company when they find something. People who find something and don't disclose are black hats, or at least grey hats, but definitely shouldn't be considered researchers.
"Researchers" here is a term of art in the field; for the most part, vulnerability researchers are not researchers in the academic sense, but rather in the newsgathering sense.
People who find vulnerabilities purely for the bounty seem to fit the classical definition of Bounty Hunters or Mercenaries. Certainly not researches. They're not in it for the academic benefit or advancing the state of the art. They're in it for the cash.
So your saying someone who does security research but does not get paid is a researcher, but if someone else does the same research but they get paid their not a researcher?
So what if a security researcher is paid for their work? We don't say Lawyers are not Lawyers because their being paid and not doing work pro bono.
Remember security research takes lot's of time, skill and hardware they should be paid to do their work.
Doing work on your own time, with your own materials, and expecting to be paid for your work product is "scarily similar to blackmail"? Could you go into that a little bit more?
Exactly how are these "professional researchers" generating their paychecks?
(NB: I was one of those "professional researchers".)
Once a researcher has found an issue, demanding money after the is similar to blackmail.
Agreeing on money up front seems like a reasonable way, I also see no problem with bounty programs or even asking for more from bounty programs. Withholding a bug until a bounty is raised is were I would draw the line at blackmail.
You haven't explained how it's anything at all like blackmail. Say I'm the researcher and you're the vendor. I'm offering to sell the product of my own work. You're free not to buy it from me. But you are in no way entitled to my work product!
The sole value of your "product" is to actively harm the vendor's product. It doesn't provide any other value (unless you want to claim that it can be sold for educational purpose).
Couldn't that be compared to, say, selling protective sportswear. That is also selling protection from harm. Now if the researcher threatens to auction off the exploit...
This is like the exact opposite. It would be more selling "not punches" as long as you buy I will show you all the places I could have punched you. You can guess what I do if you don't pay the known hacker/puncher.
What? So unlike every other profession, you're not a real infosec researcher unless you're not in it for the money? Just about everyone does their job for the money. Are we all mercenaries too?
This is a weird kind of ownership you've taken over the word "researcher". There are all sorts of people traditionally described as researchers, and many of them are private and for-profit.
Last time I checked our society tells us that striving for money is the way to go, so why should researches be hold to different standards? If you don't like the game, change the rules - don't blame the players.
The big tech companies would love that. If all researchers lived up to your standard, then there would be no vulnerability market—no bug bounties—and researchers would get paid peanuts. They'd be free labor for tech companies. "Researcher" means that you research, not that you work for free.
So what? That still doesn't mean USG bug hunters are creating bugs. The bugs are there whether the USG finds them or someone else does. And, having found them, the USG has done nothing to prevent anyone else from finding them later.
They have the resources to be the man-in-the-middle and a potentially large library of 0-days, can you keep them out?
Are you a republican, a democrat, or vocal on any issue? What if someone abused this power to stifle or harm you for your view? Have you heard of LoveInt?
The USA, its citizens and businesses have more software in business critical and life saving roles than other countries. For example: A 0-day in NGinx is far more likely to be able to harm the US Economy than to help get foreign state secrets. Sharing this exploit or publishing a patch protects US interests from foreign attackers far better than hoping for some foreign state to leak some secret.
Groups representing the US taxpayer should be acting on behalf of the taxpayer.
They are representing the taxpayer. They're doing it in a way you don't approve of, but any of us can say that about any number of things the government does!
I'm pretty skeptical that anything the FBI is doing is altering the balance of power in software security between the US and China.
It's also a little weird to me that we have the expectation that a government agency is going to shoulder responsibility for ensuring the software we run is secure. Shouldn't that be the vendor's responsibility?
Of course it is the Vendor's responsibility. But if the NSA, CIA, FBI, Homeland Security, Secret Service or any other government group gets in the way how much of the blame goes where when the shit hits the fan?
Most vendors will patch if they know about issues. Who is at fault when a hack happens and the the US government could have prevented it by divulging.
None of these groups are "getting in the way". They're doing independent vulnerability research. Their work doesn't prevent you from doing the same research and finding the same bugs. It is really hard to understand the argument that they're somehow doing harm, simply by learning things and then not sharing them with you.
Imagine if someone in infectious disease research said "I
t's not at all true that researchers on the whole do what they do to prevent disease. Many of the best researchers do the opposite!"
It would be interesting if monetizing the next flu bug worked the way that the market for vulns works.
Infectious disease researchers are finding microbes, just like security researchers are finding vulns.
Now let's try putting words in your mouth: You would be happy with disease microbes being sold to the highest bidder and weaponized, and turned against the population, just as vulns are when security researchers sell them to spy agencies and law enforcement. Is that what you are saying? Are those acceptable professional ethics for... biologists? Anyone?
If it was up to me, we'd come pretty close to banning the manufacture of firearms and ammunition, so I'm not the right person to ask about this. But, once again:
* Vulnerability researchers do not as a rule disclose to vendors. Some do, some don't.
* Sponsoring the discovery of a vulnerability so you can write an exploit for it doesn't prevent others from finding that vulnerability and patching it. If anything, sponsoring vulnerability discovery for exploit development increases the likelihood that the bug will be patched.
* When I ran a security consultancy, we had a "no selling vulnerabilities" rule. Published, on our website. I was comfortable with that, because "my company my rules". I am a lot less comfortable dictating my own morals on other people that don't have a contractual agreement with me.
* It is difficult to come up with an argument that vendors should get disclosure of vulnerabilities that doesn't involve vendors entitling themselves to the (often very expensive) work of vulnerability researchers. It's especially galling to see companies that don't spend any real money on software security expressing that sentiment.
And, of course: software vulnerabilities aren't infectious disease agents. The revulsion we have for weaponizing infectious diseases comes from the concern that they will spread unchecked. But that's not how software vulnerabilities work.
The question is whether selling vulns, or weaponizing them, or stockpiling weaponized vulns is acceptable professional ethics. Some people think that the government having stockpile of zero-days is a good thing. Some even think that vulnerable endpoints are a good compromise outcome so that encryption doesn't turn into intellectual contraband.
But it would be better, for everyone, for it be considered unethical and unprofessional to add to the stockpile and actively keep endpoint devices vulnerable. I think stockpiles of vulns should be disclosed, even through hacks or leaks, like the Hacking Team leaks. Hence the analogy to biologists auctioning off their discoveries secretly to be weaponized. It's analogous enough: The practice of stockpiling vulns for the purpose of spying leaves everyone with less privacy and security, at the mercy of the unaccountable and outright evil. It creates perverse incentives for deeply unethical behavior. It poisons the whole software and hardware industries globally. If vulnerability stockpiles were unilaterally disclosed, it would be a large net benefit to the common technology user.
Also, rewarding researchers for disclosure is fine. There are open, transparent, and ethical ways to do that, like published bug bounties followed by timely public disclosure.
You might have good intentions and high ethics, but industry norms have to be designed for people like Hacking Team.
Your worldview is that because there are bad actors like Hacking Team, anyone who does vulnerability research is obligated to disclose their findings to vendors?
No. Vulnerabilities exist because vendors ship bad code, not because researchers read that bad code. I refuse to sign on to an "ethic" that entitles negligent vendors to the work product of researchers.
You do the work, you choose what to do with the vulnerabilities. There are packages --- Cryptocat is a great example --- where I've found grave vulnerabilities, disclosed that I found them, but refused to divulge details. I would personally never sell a vulnerability; I think vulnerability markets are immoral. But I don't get to impose that morality on others. Would that I could! I think Cryptocat is immoral, too! But I have to live and work in a world where not everyone agrees with me.
The one common denominator we can all share is "nobody is entitled to appropriate my work from me without my consent".
I don't know cryptocat or its authors, so I have no idea why you consider them immoral. What's the story?
Obligations are a two-way street, and good ethics should have support. If you have the means to reward disclosure of a vuln you should announce a bug bounty.
Professions have ethical standards. Some are stronger than others. They are meant to impose a basic level of morality. In the real world, that never happens perfectly. But some of them definitely imply disclosing one's work without extracting every last penny from it, such as disclosing abandoned clinical trials.
I feel about Cryptocat the way you would probably feel about someone who set up an inner-city neurosurgery clinic after reading a bunch of Usenet HOWTO posts.
I think there are two separable arguments here. We may disagree on both of them. But:
* The first argument is whether it's OK for researchers to stockpile vulnerabilities --- to learn things about software and then not share them. This might seem like an artificial distinction, but there are lots of good researchers who back-pocket great, important vulnerabilities. They don't exploit them, they don't sell them, they just find them, make some notes, and move on.
* The second argument is whether it's ok for anyone to weaponize vulnerabilities. If you believe that the USG has an obligation to disclose vulnerabilities, you're almost (but not quite) required to believe they can't do exploit development work --- for any reason. Disclosing vulnerabilities to vendors kills exploits.
I'm OK with researchers stockpiling. I'm OK with the USG weaponizing. I'm OK with the latter in the same sense as I'm OK with them carrying firearms or breaking down doors to serve warrants or freezing bank accounts. Obviously, I'm not OK when the USG abuses those powers.
Inn the abstract is seems OK for researchers to simply sit on vulns they have found, but is that what really happens? Why do that? Do they get sold eventually? Are there a lot of cases where the developer is hostile to fixing them? How OK this is depends on the eventual disposition.
The other one seems clearer: "Disclosing vulnerabilities to vendors kills exploits." Well, yes. The problem is that, in the present situation, endpoint security is terrible. It seems unlikely that our government has made it possible for themselves to break endpoint security, but not the Chinese or any other nation, organized crime group, or other non-state actor with some software smarts. It may take some catastrophic infrastructure penetration or super-Snowden leak to show why this is unwise.
Yes. Vendors are usually hostile to researchers, and vendors generally do feel entitled to researcher work-product. Their feeling is, it's their code, so they're entitled to know about problems with it.
But the FBI isn't exactly independent, is it? Would you say the same about "independent" researchers employed by the Chinese government, or Syria or Israel?
True, but the article is arguing it's the FBI's failure to disclose the vulnerabilities that is making us less safe.
We expect researchers to follow responsible disclosure practices and at least notify the vendor to give them a chance to prepare a patch. I can understand why the FBI might not want to do that, but that's where the OP is coming from.
But whether someone knows there are vulnerabilities is not the same as exploiting the vulnerabilities for nefarious uses.
Lets say the FBI did not exist. We know those same vulnerabilities would exist, except an organization would not be aware of them as such since the org does not exist, but the vulns would still be there and software would still be as vulnerable. So them knowing is more or less neutral in terms of making software more or less vulnerable.
What if FDA on behalf of CIA withheld drug interaction information so that CIA could "eliminate" various targets more efficiently? Would that be OK?
“The end cannot justify the means, for the simple and obvious reason that the means employed determine the nature of the ends produced.” ― Aldous Huxley
Not since Steve Walker's Computer Security Initiative. The amount of security in mainstream products increased dramatically when they had clear guidelines and financisl incentives. Even the code itself for the handful that aimed for higher-assurance. Likewise, what DO-178B did on quality/safety side.
Safety stuff still aroubd but NSA/DOD killed other effort off. So, your comment is true today. Sadly. Least we know what it will take to get stuff back on the market.
I replied with a pile of high assurance browser designs last time you said that. Such work could be turned into a production system. It's what Google did, actually, by turning OP Web Browser into Chromium. Weakened its security to make Chrome lightening fast. Yet, Chromium work was way harder to build than just getting one of these prototypes into better shape. They managed that, someone could manage other goal.
Besides, you can always isolate that part onto an untrusted board with KVM switch built in like I used to do. Push-button easy.
The reason I cite browsers here is that browsers are very hard to get right (content-controlled full-featured programming languages along with renderers for every mainstream file type). I think they serve as a pretty good illustration of why the high-assurance software approach fails for consumer computing.
I'll take high-assurance consumer software seriously when it produces a browser that is competitive with IE on Twitter, Facebook, and Google Mail.
I don't think solutions that involve KVM switches are meaningful in the real world. Journalists aren't going to KVM switch from their browser to their word processor. I'm not interested in litigating this point; I am un-convinceable on it. I'm not much more receptive to systems that devolve to the software equivalent of KVM switches.
"browsers are very hard to get right (content-controlled full-featured programming languages along with renderers for every mainstream file type). I think they serve as a pretty good illustration of why the high-assurance software approach fails for consumer computing."
This is true. They may not be able to be represented directly in a way that spots every failure model. However, what's been done repeatedly in high-assurance is isolation and information flow mechanisms that can contain problems of arbitrary programs. Several did this for browsing while others did whole VM's. You've been satisifed with low assurance software isolating or mitigating problems in such apps. Why not high assurance doing same thing given it's worked before for other apps?
Side note, Burroughs 1961 machine had hardware checks to enforce pointer bounds, mark code/data separate in memory w/ cpu checks per instruction, protect stack, and interface check function calls. Everything but interface check had almost no performance overhead in various implementations. Various ways to do interface checks at different cost-benefit. Holding off on that one. Yet, even the others should severely constrain what attackers can do given almost every injection starts with pointer or stack manipulation followed by data being executed. All three are blocked by Burroughs architecture. That's huge security benefit with almost no performance hit that can be automated by compilers. CHERI went further than that with a port of FreeBSD and C lib on theirs.
"when it produces a browser that is competitive with IE on Twitter, Facebook, and Google Mail."
I know many use Webkit and Javascript engines. Microsoft's Xax was used with PDF readers and such. Whether it handles the stuff competitively is still a good benchmark which I have little data on. What would you say competitive means here? All the features work, page loads reasonably fast, and web apps run reasonably fast? Would that do for future measurements or anything else in mind? I'll try to see if I can get anyone in the projects to run them.
"I don't think solutions that involve KVM switches are meaningful in the real world."
The money that's made selling them, including companies that specialize in it, argues otherwise. The question is where they're meaningful and to whom for what price.
"Journalists aren't going to KVM switch from their browser to their word processor. "
That's a semi-strawman. There's a ton of companies and individuals that go through extra trouble for the sake of security. A flip of a switch and drag-and-drop transfer icon is way less trouble. So, the market is bigger than you suggest. Let's say it's a journalist anyway as I get what use-case you're describing. My concept was an All-in-One desktop PC with Trusted and Untrusted functionality with the physical computers, separation, switches, etc built-in. Almost all of it is hidden except for CMW-style windows representing different security levels and physical button/switch for changing. Leads to...
" I'm not much more receptive to systems that devolve to the software equivalent of KVM switches."
...basically a QubesOS or browser-VM-like solution with hardware-enforced separation that otherwise doesn't look any different from these. Tenix already did an ugly version of this to high-assurance. A more usable one is possible. Anyway, you saying you don't believe a journalist or layperson concerned about privacy/security would ever use a QubesOS-like solution to separate low and high risk, work and play, secret and public, or something similar? I think a number would. Only difference is mine would be implemented different inside. Even could have a software switch if absolutely necessary.
The original argument is based on the assumption that the opposite of 'revealing 0-days makes us safer' is 'not revealing 0-days makes us less-safe'. I am not sure that is a correct assumption. On the surface it seems reasonable but it is also very simplistic. If one party knows an exploit that others do not, then that party has an advantage over everyone else, and everyone else is less safe from that party. Does that mean less safe in general? That depends on your opinion and relationship with the advantageous party. Those who feel less safe by this are the ones that distrust the FBI.
Yes -- the FBI has no mission to protect the public good. Their job is not to defend ordinary Americans against cyber attacks. That's a different governmental agency, if such an agency even exists (I know there is a defensive part of NSA that does things like SELinux and hardening redhat, etc).
The job of the FBI is to detect and prosecute crimes under their jurisdiction. They've decided they can better do their jobs keeping the 0-day secret than disclosing it -- if it's kept secret, it makes it easier for criminals to commit more crimes for them to prosecute, and simultaneously gives them more investigative tools, win win.
That I agree with. That's also the government's official position per NSA IAD since Orange Book. They said most software was shit, showed it in evaluations, showed how to do better, proved that with evaluations, and the market stayed on shit for profit margins.
Anyway, I think we should use their own Common Criteria and INFOSEC statements against them in crypto debates.
"Mr. Comey, these NSA documents say a system isn't secure until certain rigorous practices are performed from the chips up to the app. This iPhone wasnt designed to that standard due to to backward compatibility and cost concerns. By your own docs, the Fed's or NSA at least shoukd be able to shred it along with most COTS systems. So why is FBI contradicting NSA's expert testimony?"
Lavabit case defense I wrote previously:
"Your honor, FBI wants to put a black box in the system that can stealthily compromise all users and even forge evidence. You asked for an alternative. In our possession is a network tap that is certified for security by NSA-approved labs per NSA-approved standards. It has a NSA-approved TPM to attest its software hasnt been tampered with. Our administrator of that device has a US security clearance and will testify under oath to its physical integrity. This device can, in audited way, run a specific search on our logs or stored keys to get just the data the court needs. We suggest using it as, per NSA expert testimony, it's all they need to get the job done and has no risk of tampering."
What you think, tptacek? Nice way to make the red tape pay off? ;)
As long as software exists, by definition, zero-days will exist. A zero-day is simply a bug in its most nascent state; one person has found it, and nobody else knows about it. Whether the finder is a "security researcher," a "blackhat," or a "nation-state" has no impact on whether the bug exists or not. In fact, the bug exists even if nobody finds it! The distinction of who found it, and what they do with it, is purely political. Anyone can still exploit the bug.
Sure, maybe the "friendlier" bug finders will responsibly disclose any bugs they find. But there will never be a way to guarantee that all bugs found will be responsibly disclosed. Even if we convince the FBI/NSA to "responsibly disclose" every bug they find (will never happen), what about every other country? The hundreds of security firms? The thousands of independent hackers and "researchers?"
Zero-days will ALWAYS exist. Software will ALWAYS be exploitable. Worrying about how people react when they find those exploits is the similar to arguing about gun control. Sure, maybe we can convince some actors to responsibly disclose, but the bad actors will always keep the exploits for themselves and use them "irresponsibly." And there will always be bad actors.
So instead of fretting about what happens when someone finds a bug, why don't we prepare for the eventuality that all bugs will be found and exploited, often times without anyone's knowledge? Why don't we build security systems to be tolerant of exploits, instead of resistant to them? There is no security panacea, just as there is no reliability panacea.
We build distributed systems with the assumption that nodes will fail, and we call that "fault tolerance." We don't say a system is broken because a node fails. We say it's broken if it cannot handle a node failing.
Why can't we do the same for our security systems? Exploits are as inevitable as any type of system failure. We need to design for exploit tolerance with the same enthusiasm we design for fault tolerance.
Wow - well said. I have often said that modern computer security is akin to trying to float on the ocean in a sieve while constantly plugging each hole in the sieve all the time.
I think the world is ready for a new kind of computer. Want to start a company? ;-]
Look up CHERI processor and CHERIBSD at Cambridge. Look up Gaisler Leon3/4 SOC. License them, port CHERI tech to Leon, add capability-aware IOMMU, add TRNG, add ROM for main bootloader, fab the joker, and you got critical part of a secure computer. Clone Tandem Nonstop lockstep tech if you want fault-tolerance.
And there you go. A secure PC for only a few million dollars with BSD support. Optionally port EROS microkernel w/ jVPS filesystem for stronger solution.
Exploits being inevitable does not exonerate our elected and appointed officials from their responsibilities and obligation of running the government the people who put them in power want.
Do we want a government that collects threats that are more likely to be used against its own people than anyone else? The USA produces and use more software than any other country, not sharing exploit information fundamentally hurts the USA and the Economy of the USA more than other countries.
It's a pretty big leap you've taken here, between your disagreement with the USG's policy regarding vulnerabilities and their "obligation to run the government people want". Clearly, they're not running the government that message boards want. But that's not the same thing!
I remember some old document or preseident saying saying something about a "government for the people, by the people".
I suspect Google, Microsoft and most businesses involving the Internet and Money at the same time care. They probably want to know about flaws so they don't wind up losing their pants like the Bangladesh bank did recently.
There is huge money and real lives on the line here, this is not about appeasing message board hackers. Imagine if some big hack was learned to be known about in a 0-day the FBI withheld? I am fairly certain it was Target's mismanagement, but imagine if the a document was leaked and it showed the government knew about a 0-day that allowed the Target hack. That is small compared to what might actually happened when talking about browser or OS attack surface.
Just because you personally disagree with something the government is doing doesn't mean they aren't doing it "for the people". You have to compose a real argument.
76 comments
[ 26.4 ms ] story [ 2883 ms ] threadNo 0day, no Stratfor hack. No FBI, no Stratfor hack.
Sometimes I wonder if penetrating other agencies and corporations was part of their gameplan. The FBI were entirely behind the formation of antisec.
Aside: Other interesting observation... The FBI and Apple seem to have an odd antagonistic relationship with one another. One of the Antisec hacks was against an FBI laptop that caused the release of millions of Apple users' data. The FBI was recording and debriefing Sabu every day. How did they allow that to happen?
Good correction though. I care a lot less about the technical details with this case than the social/sociopolitical ones.
We shouldn't be so quick to rail against government zero-day stockpiling. It is likely that other branches of government are using these flaws for their own means to monitor foreign states and other entities. If we give up that power we risk crippling our offensive capabilities more than we might stand to gain by having a stronger defense.
I cannot vouch for one side or the other. I am not a senior intelligence official and I do not have all the facts.
http://dickdestiny.com/blog1/?p=913
The real threat is a death of a thousand cuts. Trade secrets, troop movements, active spies, little snippets of information that can cause a lot of trouble if put in the wrong hands.
If they truly cared about this, they would push vendors to plug the leaks that they know about.
I'm sorry but this just sounds unethical and wrong. So much can be learned passively.
This is a good read: https://www.nostarch.com/silence.htm
There are no silver bullets. We're always going to have bugs, and bad ones that affect security.
Stockpiling of zero-days blurs the line between law enforcement and adversary. The greater good is probably served by disclosure, rather than surveillance, break-ins or advancement of the careers of prosecutors.
So what if a security researcher is paid for their work? We don't say Lawyers are not Lawyers because their being paid and not doing work pro bono.
Remember security research takes lot's of time, skill and hardware they should be paid to do their work.
There is plenty of room between blackmail and research. A professional researcher can draw a paycheck and release exploits as found.
Exactly how are these "professional researchers" generating their paychecks?
(NB: I was one of those "professional researchers".)
Agreeing on money up front seems like a reasonable way, I also see no problem with bounty programs or even asking for more from bounty programs. Withholding a bug until a bounty is raised is were I would draw the line at blackmail.
... do not have the funding of the richest nation on the planet and have not shown the level of malice of that government.
They have the resources to be the man-in-the-middle and a potentially large library of 0-days, can you keep them out?
Are you a republican, a democrat, or vocal on any issue? What if someone abused this power to stifle or harm you for your view? Have you heard of LoveInt?
The USA, its citizens and businesses have more software in business critical and life saving roles than other countries. For example: A 0-day in NGinx is far more likely to be able to harm the US Economy than to help get foreign state secrets. Sharing this exploit or publishing a patch protects US interests from foreign attackers far better than hoping for some foreign state to leak some secret.
Groups representing the US taxpayer should be acting on behalf of the taxpayer.
I'm pretty skeptical that anything the FBI is doing is altering the balance of power in software security between the US and China.
It's also a little weird to me that we have the expectation that a government agency is going to shoulder responsibility for ensuring the software we run is secure. Shouldn't that be the vendor's responsibility?
Most vendors will patch if they know about issues. Who is at fault when a hack happens and the the US government could have prevented it by divulging.
It would be interesting if monetizing the next flu bug worked the way that the market for vulns works.
Now let's try putting words in your mouth: You would be happy with disease microbes being sold to the highest bidder and weaponized, and turned against the population, just as vulns are when security researchers sell them to spy agencies and law enforcement. Is that what you are saying? Are those acceptable professional ethics for... biologists? Anyone?
* Vulnerability researchers do not as a rule disclose to vendors. Some do, some don't.
* Sponsoring the discovery of a vulnerability so you can write an exploit for it doesn't prevent others from finding that vulnerability and patching it. If anything, sponsoring vulnerability discovery for exploit development increases the likelihood that the bug will be patched.
* When I ran a security consultancy, we had a "no selling vulnerabilities" rule. Published, on our website. I was comfortable with that, because "my company my rules". I am a lot less comfortable dictating my own morals on other people that don't have a contractual agreement with me.
* It is difficult to come up with an argument that vendors should get disclosure of vulnerabilities that doesn't involve vendors entitling themselves to the (often very expensive) work of vulnerability researchers. It's especially galling to see companies that don't spend any real money on software security expressing that sentiment.
And, of course: software vulnerabilities aren't infectious disease agents. The revulsion we have for weaponizing infectious diseases comes from the concern that they will spread unchecked. But that's not how software vulnerabilities work.
But it would be better, for everyone, for it be considered unethical and unprofessional to add to the stockpile and actively keep endpoint devices vulnerable. I think stockpiles of vulns should be disclosed, even through hacks or leaks, like the Hacking Team leaks. Hence the analogy to biologists auctioning off their discoveries secretly to be weaponized. It's analogous enough: The practice of stockpiling vulns for the purpose of spying leaves everyone with less privacy and security, at the mercy of the unaccountable and outright evil. It creates perverse incentives for deeply unethical behavior. It poisons the whole software and hardware industries globally. If vulnerability stockpiles were unilaterally disclosed, it would be a large net benefit to the common technology user.
Also, rewarding researchers for disclosure is fine. There are open, transparent, and ethical ways to do that, like published bug bounties followed by timely public disclosure.
You might have good intentions and high ethics, but industry norms have to be designed for people like Hacking Team.
No. Vulnerabilities exist because vendors ship bad code, not because researchers read that bad code. I refuse to sign on to an "ethic" that entitles negligent vendors to the work product of researchers.
You do the work, you choose what to do with the vulnerabilities. There are packages --- Cryptocat is a great example --- where I've found grave vulnerabilities, disclosed that I found them, but refused to divulge details. I would personally never sell a vulnerability; I think vulnerability markets are immoral. But I don't get to impose that morality on others. Would that I could! I think Cryptocat is immoral, too! But I have to live and work in a world where not everyone agrees with me.
The one common denominator we can all share is "nobody is entitled to appropriate my work from me without my consent".
Obligations are a two-way street, and good ethics should have support. If you have the means to reward disclosure of a vuln you should announce a bug bounty.
Professions have ethical standards. Some are stronger than others. They are meant to impose a basic level of morality. In the real world, that never happens perfectly. But some of them definitely imply disclosing one's work without extracting every last penny from it, such as disclosing abandoned clinical trials.
I think there are two separable arguments here. We may disagree on both of them. But:
* The first argument is whether it's OK for researchers to stockpile vulnerabilities --- to learn things about software and then not share them. This might seem like an artificial distinction, but there are lots of good researchers who back-pocket great, important vulnerabilities. They don't exploit them, they don't sell them, they just find them, make some notes, and move on.
* The second argument is whether it's ok for anyone to weaponize vulnerabilities. If you believe that the USG has an obligation to disclose vulnerabilities, you're almost (but not quite) required to believe they can't do exploit development work --- for any reason. Disclosing vulnerabilities to vendors kills exploits.
I'm OK with researchers stockpiling. I'm OK with the USG weaponizing. I'm OK with the latter in the same sense as I'm OK with them carrying firearms or breaking down doors to serve warrants or freezing bank accounts. Obviously, I'm not OK when the USG abuses those powers.
The other one seems clearer: "Disclosing vulnerabilities to vendors kills exploits." Well, yes. The problem is that, in the present situation, endpoint security is terrible. It seems unlikely that our government has made it possible for themselves to break endpoint security, but not the Chinese or any other nation, organized crime group, or other non-state actor with some software smarts. It may take some catastrophic infrastructure penetration or super-Snowden leak to show why this is unwise.
We expect researchers to follow responsible disclosure practices and at least notify the vendor to give them a chance to prepare a patch. I can understand why the FBI might not want to do that, but that's where the OP is coming from.
Lets say the FBI did not exist. We know those same vulnerabilities would exist, except an organization would not be aware of them as such since the org does not exist, but the vulns would still be there and software would still be as vulnerable. So them knowing is more or less neutral in terms of making software more or less vulnerable.
“The end cannot justify the means, for the simple and obvious reason that the means employed determine the nature of the ends produced.” ― Aldous Huxley
Safety stuff still aroubd but NSA/DOD killed other effort off. So, your comment is true today. Sadly. Least we know what it will take to get stuff back on the market.
Besides, you can always isolate that part onto an untrusted board with KVM switch built in like I used to do. Push-button easy.
I'll take high-assurance consumer software seriously when it produces a browser that is competitive with IE on Twitter, Facebook, and Google Mail.
I don't think solutions that involve KVM switches are meaningful in the real world. Journalists aren't going to KVM switch from their browser to their word processor. I'm not interested in litigating this point; I am un-convinceable on it. I'm not much more receptive to systems that devolve to the software equivalent of KVM switches.
This is true. They may not be able to be represented directly in a way that spots every failure model. However, what's been done repeatedly in high-assurance is isolation and information flow mechanisms that can contain problems of arbitrary programs. Several did this for browsing while others did whole VM's. You've been satisifed with low assurance software isolating or mitigating problems in such apps. Why not high assurance doing same thing given it's worked before for other apps?
Side note, Burroughs 1961 machine had hardware checks to enforce pointer bounds, mark code/data separate in memory w/ cpu checks per instruction, protect stack, and interface check function calls. Everything but interface check had almost no performance overhead in various implementations. Various ways to do interface checks at different cost-benefit. Holding off on that one. Yet, even the others should severely constrain what attackers can do given almost every injection starts with pointer or stack manipulation followed by data being executed. All three are blocked by Burroughs architecture. That's huge security benefit with almost no performance hit that can be automated by compilers. CHERI went further than that with a port of FreeBSD and C lib on theirs.
"when it produces a browser that is competitive with IE on Twitter, Facebook, and Google Mail."
I know many use Webkit and Javascript engines. Microsoft's Xax was used with PDF readers and such. Whether it handles the stuff competitively is still a good benchmark which I have little data on. What would you say competitive means here? All the features work, page loads reasonably fast, and web apps run reasonably fast? Would that do for future measurements or anything else in mind? I'll try to see if I can get anyone in the projects to run them.
"I don't think solutions that involve KVM switches are meaningful in the real world."
The money that's made selling them, including companies that specialize in it, argues otherwise. The question is where they're meaningful and to whom for what price.
"Journalists aren't going to KVM switch from their browser to their word processor. "
That's a semi-strawman. There's a ton of companies and individuals that go through extra trouble for the sake of security. A flip of a switch and drag-and-drop transfer icon is way less trouble. So, the market is bigger than you suggest. Let's say it's a journalist anyway as I get what use-case you're describing. My concept was an All-in-One desktop PC with Trusted and Untrusted functionality with the physical computers, separation, switches, etc built-in. Almost all of it is hidden except for CMW-style windows representing different security levels and physical button/switch for changing. Leads to...
" I'm not much more receptive to systems that devolve to the software equivalent of KVM switches."
...basically a QubesOS or browser-VM-like solution with hardware-enforced separation that otherwise doesn't look any different from these. Tenix already did an ugly version of this to high-assurance. A more usable one is possible. Anyway, you saying you don't believe a journalist or layperson concerned about privacy/security would ever use a QubesOS-like solution to separate low and high risk, work and play, secret and public, or something similar? I think a number would. Only difference is mine would be implemented different inside. Even could have a software switch if absolutely necessary.
The job of the FBI is to detect and prosecute crimes under their jurisdiction. They've decided they can better do their jobs keeping the 0-day secret than disclosing it -- if it's kept secret, it makes it easier for criminals to commit more crimes for them to prosecute, and simultaneously gives them more investigative tools, win win.
Anyway, I think we should use their own Common Criteria and INFOSEC statements against them in crypto debates.
"Mr. Comey, these NSA documents say a system isn't secure until certain rigorous practices are performed from the chips up to the app. This iPhone wasnt designed to that standard due to to backward compatibility and cost concerns. By your own docs, the Fed's or NSA at least shoukd be able to shred it along with most COTS systems. So why is FBI contradicting NSA's expert testimony?"
Lavabit case defense I wrote previously:
"Your honor, FBI wants to put a black box in the system that can stealthily compromise all users and even forge evidence. You asked for an alternative. In our possession is a network tap that is certified for security by NSA-approved labs per NSA-approved standards. It has a NSA-approved TPM to attest its software hasnt been tampered with. Our administrator of that device has a US security clearance and will testify under oath to its physical integrity. This device can, in audited way, run a specific search on our logs or stored keys to get just the data the court needs. We suggest using it as, per NSA expert testimony, it's all they need to get the job done and has no risk of tampering."
What you think, tptacek? Nice way to make the red tape pay off? ;)
Sure, maybe the "friendlier" bug finders will responsibly disclose any bugs they find. But there will never be a way to guarantee that all bugs found will be responsibly disclosed. Even if we convince the FBI/NSA to "responsibly disclose" every bug they find (will never happen), what about every other country? The hundreds of security firms? The thousands of independent hackers and "researchers?"
Zero-days will ALWAYS exist. Software will ALWAYS be exploitable. Worrying about how people react when they find those exploits is the similar to arguing about gun control. Sure, maybe we can convince some actors to responsibly disclose, but the bad actors will always keep the exploits for themselves and use them "irresponsibly." And there will always be bad actors.
So instead of fretting about what happens when someone finds a bug, why don't we prepare for the eventuality that all bugs will be found and exploited, often times without anyone's knowledge? Why don't we build security systems to be tolerant of exploits, instead of resistant to them? There is no security panacea, just as there is no reliability panacea.
We build distributed systems with the assumption that nodes will fail, and we call that "fault tolerance." We don't say a system is broken because a node fails. We say it's broken if it cannot handle a node failing.
Why can't we do the same for our security systems? Exploits are as inevitable as any type of system failure. We need to design for exploit tolerance with the same enthusiasm we design for fault tolerance.
I think the world is ready for a new kind of computer. Want to start a company? ;-]
And there you go. A secure PC for only a few million dollars with BSD support. Optionally port EROS microkernel w/ jVPS filesystem for stronger solution.
Do we want a government that collects threats that are more likely to be used against its own people than anyone else? The USA produces and use more software than any other country, not sharing exploit information fundamentally hurts the USA and the Economy of the USA more than other countries.
I suspect Google, Microsoft and most businesses involving the Internet and Money at the same time care. They probably want to know about flaws so they don't wind up losing their pants like the Bangladesh bank did recently.
There is huge money and real lives on the line here, this is not about appeasing message board hackers. Imagine if some big hack was learned to be known about in a 0-day the FBI withheld? I am fairly certain it was Target's mismanagement, but imagine if the a document was leaked and it showed the government knew about a 0-day that allowed the Target hack. That is small compared to what might actually happened when talking about browser or OS attack surface.