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@tombom.co.uk
