bugtraq - Re: DJB's students release 44 *nix software vulnerability advisories

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <41C96746.6060701@tombom.co.uk>
Date: Wed, 22 Dec 2004 12:23:34 +0000
From: Chris Paget <ivegotta@...bom.co.uk>
To: Antoine Martin <antoine@...afix.co.uk>
Cc: "milw0rm Inc." <milw0rm@...il.com>, bugtraq@...urityfocus.com,
	Jonathan T Rockway <jrockw2@....edu>
Subject: Re: DJB's students release 44 *nix software vulnerability	advisories

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