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>