[liberationtech] no-disclosure / other-disclosure [was: Foxacid payload]

[coderman]

On Sun, Jul 20, 2014 at 8:00 AM, Michael Rogers
<michael at briarproject.org> wrote:
> ...
> Assuming the effort doesn't stop when exploits dry up, but instead
> looks for new ways to attract exploits, what's the problem?

the problem is you assume this is easy.

"look for new ways to attract exploits" is a special kind of fishing.

maybe i'm just incompetent? i've been playing the "observe attacks to
better defend against attacks" game for over a decade. it used to be
dead simple, the exploits prevalent, the environment accommodating
(run a VM, expose to attacks, trace the traffic and malcode)

now even the average crimeware is obfuscated and multi-staged, nopes
out of virtualized environments to avoid detection, and rarely if ever
uses novel attacks or 0day exploits. even the targeted spear fishing
campaigns rarely use 0day anymore.

now consider the attacks you're looking for are an order of magnitude
less prevalent, an order of magnitude more stealthy, and an order of
magnitude more difficult to capture, with the most advanced attacks
delivered over direct injection to local radios, not via upstream
network over IP. (not to mention all the tricks available if physical
access to your systems is obtained. e.g. physical implants through
blackbag or  tampering during shipment.)



>> if your concern is security for the public, do it by making the
>> software we use more difficult to exploit as a whole, rather than
>> fixating on free exploits from NSA for a particular vulnerability
>> among many.
>
> That sounds like a false dichotomy to me. Publicising a specific
> exploit may spur the development of general as well as specific
> mitigations.

let me provide a concrete example: stolen certificates used in an
active attack to inject in the middle a malicious payload as trojan
update, then feed a second stage to this loader for desired effect.

publicize the payload over presumably authentic TLS? "that's not
possible because the certificate is valid.",  provider:"this is false
as we have no evidence of malicious activity on our servers nor have
any of our systems sent malware to our customers" (see lavabit. they
won't believe you unless the private keys are leaked, or stolen keys
are used for signing malicious code directly.)

publicize the code delivered in the payload that serves as loader? "if
you allow untrusted code to execute locally, that's your problem."
(see every mobile and most desktop app that does insecure updates, for
a start.  the loaders are not really that interesting)

publicize the local priv esc. delivered to the loader for
pivot/persistence/exfil? "another day, another local escalation, you
should have better
[sandboxing|grsec|rbac|ACLs|apparmor|selinux|jails|etc]" (see how
local execution almost always leads to privilege escalation on most
consumer devices and computers)


all of these things we know are problems. not only that, but we have
multiple general and specific mitigations for them, and yet they
continue to be prevalent, the protections slow to be integrated. go
look up how many known and still un-patched vulnerabilities exist in
your mobile device.



finally, while "publishing the whole thing" is a bad idea (e.g. the
public db of verbatim attacks and payloads),

reporting some of the vulns (like the priv. esc part) is useful,
though i still argue it should be done anonymously to the vendor, so
that whoever is in position to observe these attacks may continue to
do so as long as possible.  i also argue that "report anonymously to
the vendor" is very difficult right now, given the types of systems
every vendor uses to coordinate vulnerability reporting. (plain-text
email, insecure web forms, "private" mail lists, etc.)


best regards,