Re: DJB's students release 44 poorly-worded, overblown advisories

["Paco Hope" <bhope () cigital com>]

Bernstein has a history of being inflammatory, and in this case I think he
has done the whole security community a disservice. He has called everything
a "remotely exploitable security hole" even when exploiting it requires
explicit user actions. He's playing fast and loose with terminology, which
can't help anybody.

Somebody¹s gotta come up with a  reasonable definition of "remotely
exploitable." Consider the following statement:

> Limin Wang has discovered two remotely exploitable security holes in
> abc2midi. http://tigger.uic.edu/~jlongs2/holes/abc2midi.txt

If you read the exploit description, he says:
> You are at risk if you take an ABC file from an email message (or a web
> page or any other source that could be controlled by an attacker) and
> feed that file through abc2midi. Whoever provides the ABC file then has
> complete control over your account: she can read and modify your files,
> watch the programs you're running, etc.

When IE has a buffer overflow that can be exploited by carefully crafted
HTML in an email or web page, do we call that "remotely exploitable"? How
about those viruses that spread as password-protected zip files attached to
emails? The user has to click them and then enter the password before
they're activated? Aren't those "viruses" or "trojans"? If they exploited
notepad.exe when they activated would we announce a "remote exploit" on
notepad.exe? They exploit a buffer overflow in local software, but they
require action by the user before they can activate.

I mean, if these things are "remote exploits," I could say "The entire
OpenBSD operating system is remotely exploitable: if I email you an OpenBSD
binary and you execute it, I 0wn you." Well, duh.

On the other hand, he points out that things that people think are safe
(like "ABC" files) are not necessarily safe when handled by poorly written
programs.

In the end, however, there are several cases:
- running an always-listening service (like snmpd) that is vulnerable at all
times.
- executing a malicious binary from an untrusted source.
- explicitly processing untrusted input with a vulnerable program.

Only that first case is, in my mind, uncontestably remotely exploitable. The
second case is decidedly not, but the last is sort of a gray area.

Thoughts?
Paco
-- 
Paco Hope, CISSP
Senior Software Security Consultant
Cigital, Inc. http://www.cigital.com/
[EMAIL PROTECTED] -- +1.703.585.7868

----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------