Home page logo

bugtraq logo Bugtraq mailing list archives

Re: DJB's students release 44 *nix software vulnerability advisories
From: Chris Paget <ivegotta () tombom co uk>
Date: Wed, 22 Dec 2004 12:23:34 +0000

Antoine Martin wrote:


* 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
* 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).

If you have compromised a source code repository wth the knowledge that the code in that repository will be compiled and run on your target system, then why would you go to all the effort of exploiting a NASM buffer overflow? Simply write your trojan / backdoor / whatever in regular ASM or C, and let it get compiled as regular code. Exploiting NASM in this case gains you nothing, and actually makes your life considerably harder.

I have difficulty in seeing this as a "remote" exploit; it's entirely dependant upon a piece of code (NASM) being invoked by a user on the local system with your arbitrary data being supplied. Surely the very definition of a remote exploit is one that gives you the ability to run code on a system which you otherwise could not; ie a remote user with no access at all.

I'm curious - if you class this as a "remote" vulnerability, what would you class as a "local" bug, and what is the distinction as you see it?


Chris Paget
ivegotta () tombom co uk

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]