> /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.
> /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/
[ reply ]