[37848] in bugtraq
Re: DJB's students release 44 *nix software vulnerability
daemon@ATHENA.MIT.EDU (Antoine Martin)
Tue Dec 21 16:48:09 2004
From: Antoine Martin <antoine@nagafix.co.uk>
To: "milw0rm Inc." <milw0rm@gmail.com>
Cc: bugtraq@securityfocus.com, Jonathan T Rockway <jrockw2@uic.edu>
In-Reply-To: <814b9d504122112346acc78e8@mail.gmail.com>
Content-Type: text/plain
Date: Tue, 21 Dec 2004 21:30:25 +0000
Message-Id: <1103664625.10617.15.camel@cobra>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
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
>
