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 for Android: free password hash cracker in your pocket

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

Date: Thu, 23 Dec 2004 17:49:55 +0100 (CET)
From: Michal Zalewski <lcamtuf@...ne.ids.pl>
To: Jonathan Rockway <jrockw2@....edu>
Cc: bugtraq@...urityfocus.com
Subject: Re: DJB's students release 44 *nix software vulnerability advisories

On Tue, 21 Dec 2004, Jonathan Rockway wrote:

> /bin/sh exists to run shell commands.  That is the purpose of the
> shell.  NASM, on the other hand, is designed to create object files
> from assembly files.  If NASM starts running arbitrary code on your
> machine, it's doing something unauthorized.  That is a security hole.

Consider this example: I am sending you an e-mail telling you to type
"/usr/local/bin/game_of_pong AAAAAAAAAAAAAAAA(...)$ASCII_SHELLCODE".  The
game_of_pong utility happens to be have a command-line parameter buffer
overflow problem. If you follow my instructions, you will get 0wned.

The aforementioned application has a flaw, and as a result, did something
it was not designed for. This does not constitute a remotely exploitable
vulnerability by our standards, however. If it did, *all* bugs would
belong to that category.

What happened is that the user had became a wetware REMOTE->LOCAL gateway
for all kinds of attacks, if he can be tricked into feeding untrusted and
unchecked input received over the network into programs that were never
designed to handle such information.

We may and should blame the author for writing shoddy code, but this is
not a remotely exploitable flaw in his software.

I am not saying such a two-factor attack fits the "local" label; I am
simply saying it does not belong to the "remote" bunch.

/mz
http://lcamtuf.coredump.cx/