| |||||||||||||
nasm: Buffer overflow vulnerabilitynasm: Buffer overflow vulnerabilityPosted Apr 21, 2005 22:23 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)Parent article: nasm: Buffer overflow vulnerability
NASM's an assembler, right? So what's the vulnerability? That someone might put a malformed .s file in a source tarball and run arbitrary code?
If you're building someone else's source and you don't trust that person, it seems like having a buffer overflow in your assembler is the least of your worries.
(Log in to post comments)
nasm: Buffer overflow vulnerability Posted May 5, 2005 9:28 UTC (Thu) by nix (subscriber, #2304) [Link] This was one of the huge scads of `overflows' that DJB's students found, most only holes in the most obscure sense, like this one.
If you're in the habit of assembling code on one machine and running it on another, then this might expose the first machine to attack, I suppose. Nonetheless, this isn't a hole I'd be too terribly worried about. :)
nasm: Buffer overflow vulnerability Posted May 5, 2005 14:55 UTC (Thu) by proski (subscriber, #104) [Link] From http://tigger.uic.edu/~jlongs2/holes/nasm.txt:Of course, if you _run_ a program, you're authorizing the programmer to take control of your account; but the NASM documentation does not say that merely _assembling_ a program can have this effect. It's easy to imagine situations in which a program is run inside a jail but assembled outside the jail; this NASM bug means that the jail is ineffective.
|
|||||||||||||