Message-ID: <46DC1D8B.8000608@nruns.com>
Date: Mon, 03 Sep 2007 16:43:23 +0200
From: Jan Münther <jan.muenther@...ns.com>
To: Sergio Alvarez <sergio.alvarez@...ns.com>
Cc: 'BugTraq' <bugtraq@...urityfocus.com>,
	full-disclosure@...ts.grok.org.uk, security@...ns.com
Subject: Re: [Full-disclosure] n.runs-SA-2007.027 - Sophos Antivirus UPX parsing
 Arbitrary CodeExecution Advisory

Hello everyone,

please allow me to chime in real quick to try and clarify some issues
which may have caused confusion.

First of all: As Sophos has now acknowledged, this bug in discussion
does constitute an exploitable condition. Of course a single byte
overwrite in an arbitrary memory location isn't your classical
drive-by-shooting stack overflow, but there are plenty of methods to
achieve code execution (function pointers and exception handlers being
the most obvious choice). Sergio just sent Sophos a crash-PoC, so their
initial reaction was to consider it just a crash bug.
When I asked Sergio about the details of the bug I already knew it'd be
exploitable - when he dubs a bug exploitable, it typically is (unless
there's an error in the topic, hah hah :P ).
Sergio discussed the topic with Sophos and they've conceded to the fact
there's exploitability, and updated their own advisory accordingly - we
couldn't ask for better cooperation, really!

As of the recent German "anti-hacking-tool laws" - these really bug
everyone around here. The biggest problem is the fuzziness of the actual
punishable acts: The law implies that the "criminal energy" is basically
contained within the tools themselves, which of course is an absurd
thought that only someone with zero contact with the actual subject
matter can come up with. However, due to these new rules nobody around
here knows what the real deal is - is having nmap on your box dangerous
now? Is having ping and telnet dangerous? What about metasploit, CANVAS
or CORE Impact, or god beware, own exploits, possibly 0days?

The problem really is that without the law being applied at least once,
it is impossible to tell. Just for the record: When this law is applied
for the first time, I am positive the German Supreme Court will send the
lawmakers back to school. One of the most important principles in
legislation is the clarity of the laws, and this has very obviously been
neglected here, else we wouldn't have such a mess now.

Let me assure you that we at n.runs and our highly respected colleagues
over at Recurity (ex-SABRE, please note the name change due to a stupid
a** lawsuit, gah) as well as the CCC and some other valued individuals
have strongly lobbied against this law and done everything we deemed
possible. The unfortunate truth however is that the lawmakers simply
didn't care what the experts had to say, mostly out of sheer
stubbornness and the attitude that if a law is lacking in any way,
jurisdiction will fix it in the long run. As many of you probably know,
these laws are the German national implementation of the so-called
European Cybercrime Convention. The convention however - in contrast to
our national law - does contain explicit exceptions for researchers and
professionals. As of the reasons why these are missing here, one can
only speculate (a task that I better leave to Fefe, he's much better at
it :P ).

In any case, Lisa is of course right (as usual :) ). The law does not
directly prohibit publishing vulnerability details. A particularly
anally retentive lawyer may construct punishability through assistance
or something, but that seems far fetched even by German standards.
Sergio's comment in this regard was just the outcome of the ubiquitous
confusion regarding these new rules.

One other little barrier is one that we gave ourselves - we currently
subscribe to Rain Forest Puppy's Responsible Disclosure Policy with a
little bit of @stake's publishing policy mixed in, as you can see under
http://www.nruns.com/rfppolicy.php, and the policy contains the
following passus:

"The Security Advisory will not contain the following information:
Proof of concept code or test code that could readily be turned into an
exploit. Sufficiently detailed technical information, such as exact data
inputs, buffer offsets, or shell code strategies that could expedite the
writing of exploit code."

We may have overinterpreted that a little, however, we plan on just
changing it. Please understand that we cannot publish details on past
bugs since our communication with the vendors was under the premises of
this policy. However, in future advisories, we will be more verbose. If
any authorities give us a hard time about it, we will surely let you
know! :)

In the meantime, please trust Sergio that when he confirms the
exploitability of a bug repeatedly, it is exploitable.

Thanks for listening, and have a great day,

Jan
--
Jan Münther, CTO Security, n.runs AG

Powered by blists - more mailing lists