[Dailydave] Ignorance is Bliss

[Dave Aitel]

As Stephen Colbert Says: "A great man said that. Who? Don't know, and
don't want to know!"

And frankly, this is where Matt Blaze and his Co-Authors are on the
subject of the 0days, or anything hacking related. I'll pause here to
post a couple links:

  * http://www.volokh.com/2014/01/08/shorter-matt-blaze-nsa-hacking-ok-long-take-away-best-hacking-tools/
  * http://www.crypto.com/papers/GoingBright.pdf

Matt Blaze and I went back and forth on twitter for a while a few days
ago, but to summarize the argument (which is also in the NSA Task Force
recommendations) from their paper - they claim that the NSA (or FBI/LE)
can realistically both use 0days for hacking, and report all their 0days
(with some minor exceptions) to the vendors. They like to claim that a
"window of vulnerability" is all you would need as a Law Enforcement or
intelligence agency, since you could of course just increase your
investment in security research to always find more 0days from the
endless series of vulnerabilities that exist. To support this they quote
some lame statistics from various source (bugtraq, Vupen, etc.)

Nothing cheeses me off more than professors claiming to have conducted
"research" when having absolutely no actual data on the subject matter,
having produced what is an obviously inaccurate and misleading opinion
paper on the subject.
Here's a quote from page 6:
"""
/In the (very) rare cases where no remote exploitation is possible, a
"black bag job" a legally authorized surreptitious physical break-in
might be performed to install the exploit code directly on the target's
device./
"""

Let me just put it this way: Exploits and Implants are different things,
and if you have even the smallest interaction with the community of
experts who deals in such things you don't confuse them.

"""

/Compromising the target's platform is practical because modern software
systems are and will continue to be inherently vulnerable to attack. New
exploitable vulnerabilities in widely used software are discovered at a
steady rate, literally daily. /
"""

That's the sort of thing you would say if you've never tried to write a
software exploit, but instead spent a few minutes reading CVE numbers.

"""
/These groups discover and release a steady stream of new
vulnerabilities in widely used software platforms. Table 1 lists the
numbers of remotely exploitable vul-nerabilities discovered each month
from several of these commercial vulnerability research groups for the
period of 1 March through mid-July 2012. //
//
//The fact that a new vulnerability is found is usually published
immediately. Public disclosure of the details usually occurs a few weeks
later, typically to Bugtraq [www.securityfocus. com/archive/1] and
Full-disclosure [http://seclists. org/fulldisclosure]/
"""
Straight up not true. I can't think of a time a Vupen bug went public,
for very good reasons. This is the kind of thing that shows the quality
of the "research" in these papers.

"""
/An upper bound on the cost of vulnerability discovery can be estimated
straightforwardly from currently existing markets that traffic in 0-day
exploits. The government could either purchase "fresh" 0-day
vulnerabilities from the market or discover them internally, as budget,
resources, and policy permit./
"""

That's like saying that because there are always apples in Whole Foods,
it's ok to burn the apple orchards.

Franky, I could go on, but the paper has more inaccuracies than
accuracies after page 6. There's also no discussion or understanding of
basic OPSEC or strategy.

Let me close with this: I'm all about advocacy and creating a more free
society - CALEA is bad for us all -  but cloaking advocacy in this sort
of paper, essentially claiming expertise where there is none, is counter
productive.

-dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.immunityinc.com/pipermail/dailydave/attachments/20140114/3177d1d8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <https://lists.immunityinc.com/pipermail/dailydave/attachments/20140114/3177d1d8/attachment.sig>