DJB's students release 44 *nix software vulnerability advisories

I'm not so sure about this. In the nasm case, a local use must run nasm
therefore requireing a local account. In my opinion, remote exploits are
holes that I can attack from the network without waiting for a local user
to execute something, i.e. services that are running or exposed protocols.

As for the other comments in this thread about telling the vendor early, I
personally feel it helps users if the vendor has a few days to look at the
hole and devise a patch BEFORE everyone on the planet knows about it. You
punish users of software in addition to vendors. All software has a
security problem of one kind or another, and its silly to think that a
perfect application will every be written.

On Mon, 20 Dec 2004, Jonathan T Rockway wrote:

> Two points.
>
> Regarding local versus remote, look at it this way: You have a 100%
> secure system. Then you install NASM. Now a user FROM THE NETWORK can
> send you some tainted assembly code for you to assemble and he can
> compromise your account. That is why it is considered remote. Local
> would mean that I, the attacker, need an account on the target machine to
> compromise the target account. In this nasm case, I do not need an
> account. That is why the wording "remote" was chosen.
>
> Now in regards to full disclosure, I think you should all be happy that we
> bothered to tell you all about these exploits. We could have selfishly
> used them to compromise machines, but instead we wrote them up and mailed
> them off to the users and the authors! That is very nice of us.
>
> If you would like notification sooner than the "public", find the exploit
> yourself. If I can find them, then surely anyone can.
>
> Regards,
> --
> Jonathan Rockway <jrockw2@uic.edu>
>

--/9DWx/yDrRhgMJTb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 20, 2004 at 05:14:22PM -0600, Jonathan T Rockway wrote:
> Two points.
>=20
> Regarding local versus remote, look at it this way: You have a 100%
> secure system. Then you install NASM. Now a user FROM THE NETWORK can
> send you some tainted assembly code for you to assemble and he can
> compromise your account. That is why it is considered remote. Local
> would mean that I, the attacker, need an account on the target machine to
> compromise the target account. In this nasm case, I do not need an
> account. That is why the wording "remote" was chosen.

What you really have is a local exploit that you can sometimes trick a
person into executing for you. Not the same thing as a remote
exploit. You as a remote user have no way of compomising the system
without first penetrating the system in some other way. Just because
there is a social engineering method to achieve this penetration does
not make this a remote exploit.

I might add that if a person is assembling an untrusted piece of
assembly code, there is a decent chance that he is planning on
executing it.

>=20
> Now in regards to full disclosure, I think you should all be happy that we
> bothered to tell you all about these exploits. We could have selfishly
> used them to compromise machines, but instead we wrote them up and mailed
> them off to the users and the authors! That is very nice of us.

Yeah, you know, if the choice is between criminal activity and this
kind of announcement, you did ok, but I think we all assume that people
in the security community want to actually protect users from security
problems. Assuming that this is your goal, I think you can do better.

--=20
Raymond M. Reskusich
System Programmer/Administrator
CITES/Engineering Workstation Group
University of Illinois at Urbana-Champaign
reskusic@uiuc.edu
pgp key id: D9D38030


--/9DWx/yDrRhgMJTb
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFByIRCWZWv9dnTgDARAtp0AKCBx2Bl4qQCV/XLvwU3uSgqeFMF+QCfXMbh
qRduSGy5NG06vkn4KKkWIZk=
=kW8D
-----END PGP SIGNATURE-----

--/9DWx/yDrRhgMJTb--

Stephen Samuel writes:
> crackers will have up to 8 hours to code and use your bug

It's not _my_ bug. It's also not my student's bug. It's the _program's_
bug. Sorry to have to break the news to you, but the attacker has had a
_year_ to exploit the bug if the program was released a year ago.

You're under the delusion that the bug's existence and exploitability
were created by the messenger---the bug-report publisher---rather than
by the original programmer. I realize that this is a common delusion,
one of the big excuses for inadequate security efforts; one of the
virtues of full disclosure is that it forcibly overrides the delusion.

> I'm asking for a reasonable ammount of time for a responsible
> programmer to ensure that his/her user community is properly served
> and protected from the effects of the bugs.

Same delusion: you think that users are protected from security holes if
the security holes are patched before they're announced. Sorry, but
that's not nearly fast enough. Protecting the users means making the
programs secure before they're deployed in the first place.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

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>

On 21 Dec 2004, at 3:22 PM, laffer1 wrote:

> As for the other comments in this thread about telling the vendor
> early, I personally feel it helps users if the vendor has a few days
> to look at the hole and devise a patch BEFORE everyone on the planet
> knows about it. You punish users of software in addition to vendors.
> All software has a security problem of one kind or another, and its
> silly to think that a perfect application will every be written.

Why are users using insecure software? Or rather, why do users accept
the fact that their software may be insecure?

Besides, full disclosure helps the users too.

I remember a few years ago when the major SSH remote hole was found. I
read about it on slashdot between classes. Since there was no patch
yet, but there was an exploit, I ssh'd into my home machine and turned
off ssh. Even if there wasn't an exploit, I wasn't going to leave a
vulnerable service up and running. By the time I got home, sshd was
patched, and I installed that patch. If nobody had disclosed the
threat to me, I could have been compromised. But, because I was
notified, I was able to take preventative measures.

The sooner someone told me about the problem, the sooner I was able to
protect myself from the threat.

Full disclosure is important because vendors will drag their feet if
they're the only ones who know about it. Imagine you are a student and
have a paper due "whenever". When are you going to write the paper?
Today? No, you'll do it later. After all, nothing bad happens if you
don't do it, and not doing it is much easier than doing it.

Humans and software vendors are LAZY. If there's no reason to do
something, they won't do it. Full disclosure forces the issue and puts
everything out in the open. No "it'll be ready in 90 days" stalling.
It will be ready NOW or users will look to more secure alternatives.
They will make the first move and choose a program that doesn't have
security problems to begin with. This is better for everyone (well,
except people with financial interest in selling crappy software. that
doesn't particularly upset me, though.)

I do have more sympathy for open source developers. They are not
trying to profit from the security of their software, so I think they
deserve a little leeway. BUT, fixes are usually contributed by outside
experts. The experts can't just guess "Oh, I bet Person A of the NASM
project needs help with security problems. I'll send him an email and
ask if he needs help." They need to know about the vulnerability
before they can attempt to fix it. If they're reading a full
disclosure mailing list, they'll know about the problem. Then they can
code up a fix, email it to the author, and bang, it's fixed. It all
starts with full disclosure, though. (Without full disclosure, the
author of the software would be on his own to fix it. With full
disclosure, someone more experienced can help him out. That's a Good
Thing and is what makes the Open Source movement work.)

Full disclosure makes the Internet more secure. It forces vendors to
fix their broken software, and it forces users to update their broken
software. Less broken-ness is good for everybody.

If you disagree, you are probably writing broken software and are
afraid of what your users will do to you when they find out about it.
Good luck with that, and remember: don't shoot the messenger. If you
wrote the buggy code, you have only yourself to blame.

Regards,
--
Jonathan Rockway <jrockw2@uic.edu>

--==_Exmh_-1328937180P
Content-Type: text/plain; charset=us-ascii

On Tue, 21 Dec 2004 14:59:15 EST, "David F. Skoll" said:
> Could you have? How, pray tell, would you compromise a machine with
> the NASM exploit? Even if you have a local account, the NASM exploit
> lets you run arbitrary code as... yourself. Big deal.

Do you audit every line of code you receive from the network? Even for a
package the size of Apache or the X11 distribution? And you miss the point -
if *I* can hand you a trojaned program that will run arbitrary code as
"yourself" *when I don't have a userid on your system*, I have a toehold on
your system.

Remember that "I get you to run arbitrary code as yourself" is the *primary*
way that spyware and zombie software get onto people's systems. So it's not
an academic moot point.

Having said that, running 'more' on the foo.S file will almost certainly show
up the exploit as a oddly formatted line. What is *much* more likely to
actually work is.. Hmm.. thinking for a moment..

Yeah.. ship software with "optional MMX for speed" support, and have the package's
Makefile invoke gcc. gcc will invoke the C preprocessor on the assembler source,
allowing for all sorts of #ifdef and #define magic to make the code look like
one thing but do another.

Probably take a *lot* longer for people to twig onto what was going on than the
Trojan that showed up in the Sendmail distrib and a number of other things a while
back - the ./configure script would compile-and-run a backdoor-shell program.

All the same, getting *any* program to execute arbitrary code other than what
the programmer intended is a *vulnerability*. The fact that some social engineering
is required to actually *exploit* the hole doesn't change the fact that there's
still a hole.

If I dig a deep hole, with lots of pointy poisoned sticks at the bottom, and
cleverly concealed with netting, there's *still* a hole there even if I fail
to convince you to take a stroll with me down this trail, and oh would you
mind going first, there's a narrow spot here.....

--==_Exmh_-1328937180P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFByP7+cC3lWbTT17ARAg5JAJ9EtdsZLt51z2sTMRT7ks QOld99UACeLT3B
d+G2Jmg2d9RbmNS5P7tMKFo=
=ex8O
-----END PGP SIGNATURE-----

--==_Exmh_-1328937180P--

Besides which packages were found to be vulnerable, it seems like it
would be equally or more informative to know which other packages were
audited and not found to have bugs. The bulk of the "7500 man-hours"
were probably spent *confirming* the security of some of the software,
and some students may have accidentally selected well-written
software.

It might also be useful to know which individuals looked for which
kinds of vulnerabilities. For example, one report dealt with buffer
overflows in a long SQL query that was apparently controllable by the
user, but there was no mention of whether SQL injection
vulnerabilities were investigated. Another mentioned directory
traversal via ".." sequences but didn't mention "/absolute/pathname"
vulns (which could be thought of as the same general issue, except a
lot of software is vulnerable to one but not the other.)

The bulk of the reported issues seem to be classic buffer overflows, a
rate of about 70%, which is rather high compared to the industry-wide
average of about 20% in recent years. This could suggest an
unintended bias somewhere in the audits, e.g. in the tools or
techniques used by the students, or the types of packages that were
audited. However, there were insufficient details to know whether
these overflows resulted from newer-style attacks, e.g. by modifying
length fields to be inconsistent with the real length of the input.
And to be fair, the industry-wide figures for publicly reported issues
reflect their own biases.

About 20% of the issues weren't classifiable into well-known
categories, while the remainder fell into 5 categories, a small
percentage of the 20 or so well-known categories.

All that said, I agree that this is an excellent effort, and it would
be great to see even more focused activities like this in the academic
world.

- Steve

In the following, I assume that we want to minimize the probability that
a user falls victim to an attack based on a preexisting vulnerability in
a piece of software, one that you, the security researcher, have just
discovered. I'll call this probability P.


D. J. Bernstein wrote:

>It's not _my_ bug. It's also not my student's bug. It's the _program's_
>bug. Sorry to have to break the news to you, but the attacker has had a
>_year_ to exploit the bug if the program was released a year ago.
>
>

Only attackers who know about the bug, though. P is proportional to the
number of people, N, who know about the bug before it is fixed.

Observation 1: When you disclose the existence of the bug, you
increase N, which tends to increase P.

But P is also proportional to the time, T, that elapses before the bug
is fixed. By disclosing the existence of the bug, you greatly increase
the likelihood that the bug is fixed in the near term.

Observation 2: When you disclose the existence of the bug, you
decrease T, which tends to decrease P.

There is a trade-off.

>Same delusion: you think that users are protected from security holes if
>the security holes are patched before they're announced. Sorry, but
>that's not nearly fast enough. Protecting the users means making the
>programs secure before they're deployed in the first place.
>
>

But the question of vendor notification is one of software that *has*
been deployed with security bugs. In that case, notifying the vendor
before disclosure (with the understanding that public disclosure will
follow after a reasonable period of time) provides the benefits of
Observation 2, without the costs of Observation 1.

You would argue, I think, that by foregoing vendor notification, you put
the fear of God into programmers, and this will ultimately lead to the
eradication of bugs in the first place. I'm skeptical.

-David Eisner

>> And this nasm bug is then called a "remotely exploitable
>> security hole".
>
>Obviously it is not. I don't think it is even locally exploitable.

Many of the DJB-reported issues deal with exploitation of errors in
parsers or converters for specific file formats. Many files are
typically "shared," such as images, text documents, data exchange
formats, and so on. So, there can be vectors in which the attacker
can send a crafted file across network-based channels - web, email,
whatever - that then could conceivably be processed by the user,
either manually or automatically.

Granted, this is a different scenario than might be encountered in
what's typically labeled a "remotely exploitable" vulnerability, but I
haven't seen any emerging terminology that's been able to make this
reasonable distinction. However, with the growing researcher interest
in finding vulnerabilities based on irregularities in file formats,
the need for better terminology is growing.

In addition to modeling the level of authentication needed, I've been
thinking that it might also be important to note how much user/victim
participation is required for activation of the exploit, i.e. whether
the issue can be automatically exploited by normal user activity
(e.g. by simply reading an email message) or whether there's some
social engineering involved. However, I haven't put much thought into
terminology for this besides:

- automatic: exploit is automatically activated as a result of
normal usage of the product

- complicit: requires some victim participation or inaction

- opportunistic: can not really control when, or if, the victim
activates the exploit

Exploitation of web or email client vulnerabilities that happen as
soon as someone reads a message might be called "automatic," e.g. if
there's a buffer overflow when preparing a preview of the message. If
the user needs to click on a button or two, e.g. to extract something
whose icon shows as a JPG when in fact it's an executable, that might
be "complicit." If you insert terminal escape sequences into some log
file in the hopes that an admin accidentally runs "more" or "grep" on
that log file from the proper terminal, then that might be
"opportunistic." Phishing might be regarded as either automatic or
complicit, depending on whether or not you think web client users
should check their browser's status bar every time they click on a
link. Again, though, these are just rough ideas.

- Steve

>/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?

What other purpose does NASM have other than to compile code
and then, implicitely, run it?

I could buy the argument for a webbrowser or a wordprocessor;
but a assembler or compiler?

>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". :)

Any script which exploits a local security hole would do.

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

You should have paid better attention in class.

Casper

Actually, I think this would make for a fascinating course. If I were =
teaching it, I don't know that I would have insisted on each student =
finding 10 holes, that does seem too optimistic. Rather, I would think =
requiring students to document their efforts at attempting to find =
holes, and assign extra credit for those who actually discover them. =
That would allow all students an equal chance at a grade, without =
penalizing those who aren't fortunate enough (as it were) to run across =
a vulnerability.

This sort of course is well outside what those in academia think of as =
the normal CS curriculum (see =
http://www.computer.org/cspress/CATALOG/cs01499.htm). Instead of =
criticism, I would think that we in the software industry (and =
especially those of us who also teach CS) should champion inventive (and =
currently quite relevant) courses such as this. It is hard to convince =
those who make such decisions to allow such courses, especially in light =
of insufficient precedence (the bureaucratic inertia of academia rivals =
that of other government offices).

Arguing over how to classify an exploit seems to be fair game for this =
list, but you folks often forget just how 'l33t you are. You forget how =
long it took you to know what you know. College students are probably =
more over-worked than you are. If I were the instructor of this class, I =
would probably caution my students on submitting their work to lists =
like Bugtraq, and if they chose to, to be well aware of the flames that =
may result. Arguing over full disclosure or whether something is =
remotely exploitable or not misses the point of the class, near as I can =
tell.

Happy Holidays to all.
Robert Manning


> -----Original Message-----
> From: D. J. Bernstein [mailto:djb@cr.yp.to]
> Sent: Friday, December 17, 2004 8:25 PM
> To: bugtraq@securityfocus.com
> Subject: Re: DJB's students release 44 *nix software vulnerability
> advisories
>=20
>=20
> Shu T. Messenger writes:
> > In each case, Professor Bernstein notified the author of the
> > vulnerable package on Dec 15 via e-mail. This mail hit=20
> Bugtraq on the
> > 16th, giving one day for vendors to provide fixes.
>=20
> Actually, I sent all of these notifications to the public=20
> securesoftware
> mailing list (http://securesoftware.list.cr.yp.to) at the=20
> same time that
> I sent them to the authors. It certainly wasn't my intention=20
> to give the
> authors an extra day of self-delusion.
>=20
> > Is the class on responsible disclosure next semester perhaps?
>=20
> If you had bothered to look at the slides on the course web page, you
> would have seen a half day dedicated to the topic, plus some=20
> examples on
> subsequent days of how people react to full disclosure when they're
> trying to protect their shoddy security practices.
>=20
> The reason that the 16 students sent their 91 reports to me=20
> privately is
> so that they wouldn't have to deal with people like you. It=20
> was entirely
> my decision to send out these 44 public notices.
>=20
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
>=20

D. J. Bernstein wrote:

>Stephen Samuel writes:
>
>
>>I'm asking for a reasonable ammount of time for a responsible
>>programmer to ensure that his/her user community is properly served
>>and protected from the effects of the bugs.
>>
>>
>Same delusion: you think that users are protected from security holes if
>the security holes are patched before they're announced. Sorry, but
>that's not nearly fast enough. Protecting the users means making the
>programs secure before they're deployed in the first place.
>
>
In theory, theory is just like practice. But in practice, it isn't.

In theory, I agree with DJB: an infinitely-funded adversary can hire a
gang of code analysts to scour a code base looking for vulnerabilities
and *not* publish them, effectively manufacturing private exploits in
whatever quantity they are willing to pay for. It is conjectured that
certain foreign governments are actually doing this.

But in practice, there is a *substantial* amount of epidemiological data
that shows that wide-spread attacks against software follow shortly
after the disclosure (responsible or otherwise) of a vulnerability. See
Brown, Arbaugh et al A Trend Analysis of Exploitations
<http://www.cs.umd.edu/%7Ewaa/pubs/CS-TR-4200.pdf> for great data on
when attacks happen with respect to disclosure. Furthermore, if you
force a fire drill in releasing the security patch, you compromise the
quality of the patch. See my work on patch quality "Timing the
Application of Security Patches for Optimal Uptime", Beattie et al
Postscript
<http://immunix.com/%7Ecrispin/time-t...x-lisa02.ps.gz>. or
ugly PDF <http://immunix.com/%7Ecrispin/time-t...nix-lisa02.pdf>.

So while I am sympathetic to DJB's passion for correct software and to
hell with the tender feelings of developers who ship buggy code, in
practice this kind of 0-day notice of vulnerabilities *mostly* just
harms end-users.

Crispin

--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
CTO, Immunix http://immunix.com

On Tue, Dec 21, 2004 at 02:34:20PM -0600, milw0rm Inc. wrote:
> /*
> Two points.
> Regarding local versus remote, look at it this way: You have a 100%
> secure system. Then you install NASM. Now a user FROM THE NETWORK can
> send you some tainted assembly code for you to assemble and he can
> compromise your account.
> */
>
> quote "for you to assemble"
>
> Its a user error. Your not remotely exploiting anything but the trust
> from the user.
>
> //str0ke

Would you also argue that if someone views a web page and is compromised
because of a bug in the HTML parser of their web browser, it is their fault?
Certainly, assembling and then executing code of unknown provenence is a dumb
idea. But at the point you assemble it, it is just ASCII text. There is a big
difference between running code that you don't know, and running code you do
know on potentially malicious data. The first might be asking for it, but you
do the second every time you connect to a network.

Jack

On Tue, 21 Dec 2004, Jonathan Rockway wrote:

> /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.

Consider this example: I am sending you an e-mail telling you to type
"/usr/local/bin/game_of_pong AAAAAAAAAAAAAAAA(...)$ASCII_SHELLCODE". The
game_of_pong utility happens to be have a command-line parameter buffer
overflow problem. If you follow my instructions, you will get 0wned.

The aforementioned application has a flaw, and as a result, did something
it was not designed for. This does not constitute a remotely exploitable
vulnerability by our standards, however. If it did, *all* bugs would
belong to that category.

What happened is that the user had became a wetware REMOTE->LOCAL gateway
for all kinds of attacks, if he can be tricked into feeding untrusted and
unchecked input received over the network into programs that were never
designed to handle such information.

We may and should blame the author for writing shoddy code, but this is
not a remotely exploitable flaw in his software.

I am not saying such a two-factor attack fits the "local" label; I am
simply saying it does not belong to the "remote" bunch.

/mz
http://lcamtuf.coredump.cx/

http://www.cs.umd.edu/~waa/pubs/Wind...nerability.pdf summarizes
reports to CERT of intrusions through three particular security holes.
Most intrusions occurred months or years after the holes were disclosed
to the public. (Let's assume that reports to CERT are noticeably
correlated with actual damage.)

Crispin starts from these three examples of intrusions occurring _after_
full disclosure, and---applying the principle ``post hoc, ergo propter
hoc''---leaps to the astounding conclusion that the intrusions were
_caused_ by full disclosure, i.e., that avoiding disclosure would have
prevented the intrusions.

Crispin's conclusion is obviously incorrect. We've all seen reports of
extensive damage caused by attackers exploiting security holes that
_weren't_ publicly known before the attacks. Clearly the attackers are
capable of reading software and finding security holes for themselves.
This isn't rocket science.

There is, by the way, a more subtle problem with the argument against
full disclosure: the argument focuses entirely on short-term effects and
ignores long-term effects. But the basic problem with the argument is
that it's out of whack with reality. If you think that hiding security
information keeps us safe, you're deluding yourself.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago