Onderwerp: Re: DJB's students release 44 *nix software vulnerability

D. J. Bernstein -> bugtraq@securityfocus.com @ 18 Dec 2004 04:25:11 -0000:

>> In each case, Professor Bernstein notified the author of the
>> vulnerable package on Dec 15 via e-mail. This mail hit Bugtraq on the
>> 16th, giving one day for vendors to provide fixes.

DJB> Actually, I sent all of these notifications to the public
DJB> securesoftware mailing list (http://securesoftware.list.cr.yp.to)
DJB> at the same time that I sent them to the authors. It certainly
DJB> wasn't my intention to give the authors an extra day of
DJB> self-delusion.

Was it your intention not to give _users_ of their programs an extra
time of not being _widely_ attacked? While you certainly cannot offer
them alternative software for their tasks - of your own programs only
ezmlm with third-party patches is more than proof of concept. We need
software that does the work, not only one that demonstrates that the
work can be done in principle.

--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru

On Tue, 2004-12-21 at 14:34 -0600, milw0rm Inc. wrote:
> /*
> Two points.
> Regarding local versus remote, look at it this way: You have a 100%
> secure system. Then you install NASM. Now a user FROM THE NETWORK can
> send you some tainted assembly code for you to assemble and he can
> compromise your account.
> */
>
> quote "for you to assemble"
>
> Its a user error. Your not remotely exploiting anything but the trust
> from the user.
Although I agree with you that in the vast majority of cases this
exploit would require user interaction, there are corner cases where
this can be successfully exploited remotely:
* gentoo systems by compromising one of the master servers (or more
simply by hijacking the connection to one of the those servers) to serve
the malicious file - but in this case you probably don't really need
this exploit to compromise the system.
* other automated build systems (no generic name comes to mind) which
download the files they work on from other systems - which may not be
trusted to the point that grants a shell but just enough to provide
input.
* compromising any open-source software's repository that already uses
nasm and placing the exploit file in the default build target - tough,
but not impossible (it has happened before and will happen again).

I guess this is just not "remotely expoitable" in the usual sense
(direct attack vector)


A.M
>
> //str0ke
>

I don't know what you people are arguing about. The bugs are valid, and they're
remote, and that's the end of the story. Haven't any of you ever done a
tutorial online to learn some new techniques? Didn't you perhaps download a C
file, or assembly file, and build it on your system? When you downloaded and
built that code, you assumed the only actions that would occur are the actual
assembly instructions you are reading. Now I haven't looked at the nasm bugs
yet, so I don't know if you are able to spot an evil asm file with a quick look
(though you probably are). Yes I'm pretty sure that most of would realize
something is wrong, but still, crap, look at all the idiots that get infected by
BRITNAYSPARESPRONG.JPG files every day. Yes there may be some mitigating
factors that make it difficult to exploit, but that does not invalidate the
vulnerability.

--
[ sean ]