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

[Jonathan Rockway <jrockw2 () uic edu>]

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 () uic edu>