<<< Date Index >>>     <<< Thread Index >>>

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



Hello everyone.

On 21 Dec 2004, at 1:59 PM, David F. Skoll wrote:

 If you have /bin/sh installed, I can send you a shell
script FROM THE NETWORK that will give me root access if you run it.
Therefore, every UNIX system on Earth has a remote hole, according to
your definition.

/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. By typing "nasm file.S" you are not intending to authorize the author of file.S to take over your account, right?

Also, could you please show me this shell script you speak of? All the shell scripts I know of that give me root access require me to type the root password. If you have found a way around this, then you are correct, "every UNIX system on Earth has a remote hole". :)

You (not you personally, but many people from whom I received a reply) seem to think that "local" and "remote" are indicators of severity, but that's just not the case. The NASM hole I discovered, for example, is not very severe. I estimate that a total of 0 users will have their accounts compromised via this hole. But the possibility exists for a remote user to compromise an account, so it is called remote. Local holes require a local user to do something special, like write a program that closes fd 2 and execs chsh (the intent being for chsh to open /etc/passwd under fd 2, and then write something attacker-controlled to "stderr" which is actually /etc/passwd.)

Summary: Local exploits are bad.  Remote exploits are bad.

milw0rm' writes:

> > "for you to assemble"
> Its a user error.  Your not remotely exploiting anything but the trust
> from the user.

The user trusts NASM to not wipe their homedir. NASM is betraying the user's trust.

Many University classes utilize an assignment submission mechanism that automatically compiles and runs submitted programs. The execution of the compiled code is done in a jail, but the compiling is not (because it's hard to get all the compiler executables and resource files into the jail). The NASM bug allows someone to compromise the system in the compiling stage.

Even if the compile step were done in a jail, the attacker could remove the NASM binary, causing the system to not work for other users. It, therefore, IMPOSSIBLE to build a secure auto-grading system that uses NASM.

Wesley Shields writes:

> This is far from a remote vulnerability.  That's like posting some
> tainted shellcode in an exploit and waiting for people to blindly
> compile and run it. Stupid users blindly running untrusted code is not
> a remote vulnerability.

Yes, but stupid users compiling said code and being compromised IS a vulnerability. If you run the executable that NASM produces, you get what you deserve. Merely compiling it, though, should not allow arbitrary code to be executed.

(This raises the question, "why would you compile it and not run it?" to which I don't have a good answer. This detail limits the impact of this particular bug.)

Roger A. Grimes writes:

> Do you want us to be thankful because you did not commit an illegal
> crime?

No, I want you to be aware that some people aren't interested in the academic value of security research. They want to 0wn b0x3n, and they are doing that without our help. Were this NASM exploit useful in spreading viruses, it probably would have been discovered by a malicious cracker and used to create botnets that relay spam.

Also, I am of the belief that laws do not equal safety. You can tell me all you want that I can't hack your network, but until you deploy secure software, you are vulnerable. Hacking your network is only illegal if I get caught.

If you use secure software, however, it is, by definition, physically impossible for you to be hacked. I would rather protect my data by making it impossible to get at than by imprisoning anyone that tries to get it. (For every one that you catch, how many do you miss?)

And finally, in regards to "responsible disclosure", here is the patch for NASM:

old: vsprintf(buff, fmt, arg);
new: vsnprintf(buff, 1024, fmt, arg);

Setting buff[1023] to '\0' is a good idea, since vsnprintf won't do that if vsprintf(buff, fmt, args) generates 1024 bytes.

Be careful to not let a user supply fmt, however, since that would lead to a format string vulnerability which would allow an attacker to write to any byte in memory. :-)

Regards,
--
Jonathan Rockway <jrockw2@xxxxxxx>