Antoine Martin wrote: <snip>
* 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).
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 -- Chris Paget ivegotta@xxxxxxxxxxxx