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/
