DJB's students release 44 *nix software vulnerability advisories

[Thor Larholm]

Widely deployed open source software is commonly believed to contain
fewer security vulnerabilities than similar closed source software due
to the possibility of unrestricted third party source code auditing.
Predictably, most users of open source software do not invest a
significant amount of time to audit the applications they use and now a
class of 25 students has discovered 44 vulnerabilities during a CS
course.

This small group of students highlights how individuals outside the
security industry without special security prerequisites can still
manage to outperform the average Bugtraq poster in sheer quantity of
discoveries. This adequately validates the typical estimate of between 5
and 15 errors in every thousand lines of code.

D.J. Bernstein (http://cr.yp.to/djb.html) is lecturing a course this
fall at the University of Illinois at Chicago called "MCS 494: Unix
Security Holes" (http://cr.yp.to/2004-494.html). One of the requirements
to pass the course was to find and exploit 10 previously undiscovered
security holes in currently deployed Unix software.=20

With a class of 25 students discovering 44 vulnerabilities most students
now expect to fail the course
(http://it.slashdot.org/article.pl?si.../12/15/2113202).

The 44 security advisories have been published at=20

http://tigger.uic.edu/~jlongs2/holes/


Ariel Berkman has discovered a remotely exploitable security hole in
2fax, a text-to-TIFF converter.
[remote] [control] 2fax 3.04 expandtabs overflows s buffer
http://tigger.uic.edu/~jlongs2/holes/2fax.txt

Limin Wang has discovered two remotely exploitable security holes in
abc2midi.=20
[remote] [control] abc2midi 2004.12.04 event_text overflows msg buffer;
event_specific overflows msg buffer
http://tigger.uic.edu/~jlongs2/holes/abc2midi.txt

Limin Wang has discovered a remotely exploitable security hole in
abc2mtex.
[remote] [control] abc2mtex 1.6.1 process_abc overflows key buffer
http://tigger.uic.edu/~jlongs2/holes/abc2mtex.txt

Limin Wang has discovered a remotely exploitable security hole in
abcm2ps.
[remote] [control] abcm2ps 3.7.20 put_words overflows str buffer
http://tigger.uic.edu/~jlongs2/holes/abcm2ps.txt

Yosef Klein has discovered a remotely exploitable security hole in
abcpp.
[remote] [control] abcpp 1.3.0 process_directive overflows token buffer
http://tigger.uic.edu/~jlongs2/holes/abcpp.txt

Limin Wang has discovered two remotely exploitable security holes in
abctab2ps.
[remote] [control] abctab2ps 1.6.3 write_heading overflows t; trim_title
overflows rest
http://tigger.uic.edu/~jlongs2/holes/abctab2ps.txt

Qiao Zhang has discovered two remotely exploitable security holes in
asp2php.
[remote] [control] asp2php 0.76.23 preparse() overflows token buffer;
preparse() overflows temp buffer
http://tigger.uic.edu/~jlongs2/holes/asp2php.txt

James Longstreet and Tom Indelli have discovered a remotely exploitable
security hole in bsb2ppm, a program to convert BSB image files to PPM
image
files.
[remote] [control] bsb2ppm 0.0.6 overflows line buffer
http://tigger.uic.edu/~jlongs2/holes/bsb2ppm.txt

Ariel Berkman has discovered a locally exploitable security hole in
ChangePassword, a YP/Samba/Squid password-changing tool.
[local] [control] ChangePassword 0.8 runs setuid shell
http://tigger.uic.edu/~jlongs2/holes/changepassword.txt

Danny Lungstrom has discovered a remotely exploitable security hole in
ChBg, a tool to change background pictures.
[remote] [control] chbg 1.5 simplify_path overflows res buffer
http://tigger.uic.edu/~jlongs2/holes/chbg.txt

Ariel Berkman has discovered a remotely exploitable security hole in
Convex 3D.
[remote] [control] Convex 3D 0.8pre1 readObjectChunk overflows
objectname buffer
http://tigger.uic.edu/~jlongs2/holes/convex3d.txt

Limin Wang has discovered a remotely exploitable security hole in
csv2xml.
[remote] [control] csv2xml 0.5.1 get_field_headers overflows token
http://tigger.uic.edu/~jlongs2/holes/csv2xml.txt

Ariel Berkman has discovered a remotely exploitable security hole in
CUPS.
[remote] [control] CUPS 1.1.22 hpgltops ParseCommand overflows buf
http://tigger.uic.edu/~jlongs2/holes/cups.txt

Bartlomiej Sieka has discovered several security problems in how
lppasswd, version 1.1.22 (current), edits /usr/local/etc/cups/passwd.
[local] [kill] CUPS 1.1.22 lppasswd ignores write errors, etc.
http://tigger.uic.edu/~jlongs2/holes/cups2.txt

Ariel Berkman has discovered a remotely exploitable security hole in
dxfscope, a viewer for DXF drawings.
[remote] [control] dxfscope 0.2 overflows ent_name buffer
http://tigger.uic.edu/~jlongs2/holes/dxfscope.txt

Ariel Berkman has discovered a remotely exploitable security hole in the
elm/bolthole filter program.
[remote] [control] elm/bolthole filter 2.6.1 save_embedded_address
overflows address buffer
http://tigger.uic.edu/~jlongs2/holes...ole-filter.txt

Manigandan Radhakrishnan has discovered two remotely exploitable
security holes in ``Get and Resume Elite Edition'' (greed), an FTP/HTTP
downloading tool.
[remote] [control] greed 0.81p DownloadLoop overflows COMMAND;
DownloadLoop does not check for nasty characters
http://tigger.uic.edu/~jlongs2/holes/greed.txt

Wiktor Kopec and Matthew Dabrowski have discovered a remotely
exploitable security hole in html2hdml.
[remote] [control] html2hdml 1.0.3 remove_quote overflows print_buf
buffer
http://tigger.uic.edu/~jlongs2/holes/html2hdml.txt

Manigandan Radhakrishnan has discovered a locally exploitable security
hole in IglooFTP, at least version 0.6.1 (the current version in FreeBSD
ports).
[local] [control] IglooFTP 0.6.1 uses fopen in /tmp
http://tigger.uic.edu/~jlongs2/holes/iglooftp.txt

Yosef Klein has discovered a remotely exploitable security hole in
IglooFTP, at least version 0.6.1 (the current version in FreeBSD ports).
[remote] [control] IglooFTP 0.6.1 does not check for directory escapes
http://tigger.uic.edu/~jlongs2/holes/iglooftp2.txt

Tom Palarz and Limin Wang have discovered a remotely exploitable
security hole in jcabc2ps.
[remote] [control] jcabc2ps switch_voice() overflows t1 buffer
http://tigger.uic.edu/~jlongs2/holes/jcabc2ps.txt

James Longstreet has discovered a remotely exploitable security hole in
jpegtoavi.
[remote] [control] jpegtoavi 1.5 get_file_list_stdin overflows fn buffer
http://tigger.uic.edu/~jlongs2/holes/jpegtoavi.txt

Yosef Klein has discovered two remotely exploitable security holes in
junkie, an FTP client, version 0.3.1 (current).
[remote] [control] junkie 0.3.1 gui_popup_view_fly does not check for
nasty characters; ftp_retr does not check for directory escapes
http://tigger.uic.edu/~jlongs2/holes/junkie.txt

Stephen Dranger has discovered a remotely exploitable security hole in
LinPopUp, an instant-messaging tool
[remote] [control] LinPopUp 1.2.0 overflows sub_string buffer
http://tigger.uic.edu/~jlongs2/holes/linpopup.txt

Mohammed Khan and Danny Lungstrom have discovered a remotely exploitable
security hole in Mesh Viewer.
[remote] [control] Mesh Viewer 0.2.2 Mesh::type overflows s1 buffer
http://tigger.uic.edu/~jlongs2/holes/meshviewer.txt

Bartlomiej Sieka has discovered a remotely exploitable security hole in
mpg123.
[remote] [control] mpg123 0.59r find_next_file overflows linetmp buffer
http://tigger.uic.edu/~jlongs2/holes/mpg123.txt

Ariel Berkman has discovered a remotely exploitable security hole in
MPlayer.
[remote] [control] MPlayer 1.0pre5 get_header overflows data buffer
http://tigger.uic.edu/~jlongs2/holes/mplayer.txt

Bartlomiej Sieka has discovered a remotely exploitable security hole in
NapShare, at
least version 1.2 (the current version in FreeBSD ports).
[remote] [control] NapShare 1.2 auto_filter_extern overflows filename
buffer
http://tigger.uic.edu/~jlongs2/holes/napshare.txt

Jonathan Rockway has discovered a remotely exploitable security hole in
NASM.
[remote] [control] NASM 0.98.38 error() overflows buff[]
http://tigger.uic.edu/~jlongs2/holes/nasm.txt

Wiktor Kopec has discovered a remotely exploitable security hole in
o3read, a converter for SXW files.
[remote] [control] o3read 0.0.3 parse_html overflows t buffer
http://tigger.uic.edu/~jlongs2/holes/o3read.txt

Danny Lungstrom has discovered two remotely exploitable security holes
in pcal.
[remote] [control] pcal 4.7.1 getline overflows tmpbuf; get_holiday
overflows tmp
http://tigger.uic.edu/~jlongs2/holes/pcal.txt

Tom Palarz and Kris Kubicki have discovered a remotely exploitable
security hole in pgn2web, a converter from PGN-format chess games to web
pages.
[remote] [control] pgn2web 0.3 process_moves overflows token buffer
http://tigger.uic.edu/~jlongs2/holes/pgn2web.txt

Jonathan Rockway has discovered that qwik-smtpd, version 0.3, allows
spammers to freely relay mail.
[remote] [exhaust] qwik-smtpd overflows clientHelo buffer
http://tigger.uic.edu/~jlongs2/holes/qwik-smtpd.txt

Qiao Zhang has discovered a remotely exploitable security hole in
ringtonetools.
[remote] [control] ringtonetools 2.22 parse_emelody overflows song
buffer
http://tigger.uic.edu/~jlongs2/holes/ringtonetools.txt

Limin Wang has discovered a remotely exploitable security hole in
rtf2latex2e.
[remote] [control] rtf2latex2e 1.0fc2 ReadFontTbl overflows buffer
http://tigger.uic.edu/~jlongs2/holes/rtf2latex2e.txt

Yosef Klein has discovered a remotely exploitable security hole in
tnftp, an FTP client, version 20030825 (current at least in FreeBSD
ports).
[remote] [control] tnftp 20030825 does not check for directory escapes
http://tigger.uic.edu/~jlongs2/holes/tnftp.txt

Danny Lungstrom has discovered that uml_net allows local users to take
down the computer's Ethernet connection.
[local] [kill] uml-utilities 20030903 uml_net slip_down() fails to check
permissions
http://tigger.uic.edu/~jlongs2/holes/uml-utilites.txt

Yosef Klein and Limin Wang have discovered a remotely exploitable
security hole in unrtf.
[remote] [control] unrtf 0.19.3 process_font_table overflows name buffer
http://tigger.uic.edu/~jlongs2/holes/unrtf.txt

Qiao Zhang has discovered a remotely exploitable security hole in vb2c.
[remote] [control] vb2c 0.02 parse_sub overflows token buffer
http://tigger.uic.edu/~jlongs2/holes/vb2c.txt

Ariel Berkman has discovered a remotely exploitable security hole in
vilistextum, an HTML-to-text converter.
[remote] [control] vilistextum 2.6.6 get_attr overflows temp buffer
http://tigger.uic.edu/~jlongs2/holes/vilistextum.txt

Ariel Berkman has discovered a remotely exploitable security hole in
xine-lib.
[remote] [control] xine-lib open_aiff_file overflows buffer
http://tigger.uic.edu/~jlongs2/holes/xine-lib.txt

Tom Palarz and Kris Kubicki have discovered a remotely exploitable
security hole in xlreader, a program to read Excel files.
[remote] [control] xlreader 0.9.0 overflows insert_start buffer
http://tigger.uic.edu/~jlongs2/holes/xlreader.txt

Manigandan Radhakrishnan has discovered a remotely exploitable security
hole in YAMT, an MP3-organization tool.
[remote] [control] YAMT 0.5 id3tag_sort does not check for nasty
characters
http://tigger.uic.edu/~jlongs2/holes/yamt.txt

Ariel Berkman has discovered a remotely exploitable security hole in
Yanf.
[remote] [control] Yanf 0.4 get() overflows buf
http://tigger.uic.edu/~jlongs2/holes/yanf.txt


Regards

Thor Larholm
Senior Security Researcher
PivX Solutions
23 Corporate Plaza #280
Newport Beach, CA 92660
http://www.pivx.com
thor@pivx.com
Stock symbol: (PIVX.OB)
Phone: +1 (949) 231-8496
PGP: 0x4207AEE9
B5AB D1A4 D4FD 5731 89D6 20CD 5BDB 3D99 4207 AEE9

PivX defines a new genre in Desktop Security: Proactive Threat
Mitigation.=20
<http://www.pivx.com/qwikfix> =20

[Crispin Cowan]

Thor Larholm wrote:

>This small group of students highlights how individuals outside the
>security industry without special security prerequisites can still
>manage to outperform the average Bugtraq poster in sheer quantity of
>discoveries.
>
That might be just a tad overstated.

The slashdot article
http://it.slashdot.org/article.pl?sid=04/12/15/2113202 was submitted by
one of these students. The student said that he spent 300 hours on the
project. The class had 25 students, so if we assume that is typical,
that is 7500 man-hours to find 44 vulnerabilities, or 170 hours per bug.

I don't believe that this "outperforms" the typical bugtraq poster. More
likely, it shows that when you are a professor, you can mandate a lot of
work if you want to

> This adequately validates the typical estimate of between 5
>and 15 errors in every thousand lines of code.
>
>
How so? The assignment was to find bugs in "UNIX" code, which arguably
is at least 10,000,000 lines of code for a typical UNIX desktop, which
should have over 50,000 bugs. That the class could find approx. 50 of
them does not come close to validating a rate that predicts 50,000.

None of which is to denigrate the fine work that DJB and his class have
done. I just don't think it validates the claims that Thor says it does.

Crispin

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

[cees-bart]

Thor Larholm wrote:

>This small group of students highlights how individuals outside the
>security industry without special security prerequisites can still
>manage to outperform the average Bugtraq poster in sheer quantity of
>discoveries. This adequately validates the typical estimate of between 5
>and 15 errors in every thousand lines of code.
>
>
Most of the 44 posted "security" advisories are about software bugs with
a very low security risk. See for example the posted bug on NASM
(http://tigger.uic.edu/~jlongs2/holes/nasm.txt): what's the chance of an
evil asm file being sent to an ignorant user that calls nasm to compile
this file? And this nasm bug is then called a "remotely exploitable
security hole". If I mail out a shell script that does "rm -rf $HOME/*",
this can also be considered a remotely exploitable security hole.

A proper (wide-scale) remotely exploitable security hole is one than can
be exploited without any ignorant user on the other side: for example,
the bug Windows Messenger service which was enabled by default, making
every user vulnerable, regardless of their stupidity.

>With a class of 25 students discovering 44 vulnerabilities most students
>now expect to fail the course
>(http://it.slashdot.org/article.pl?sid=04/12/15/2113202).
>
>

I think punishing students that have actually found security holes does
not make the world a better place



--
cees-bart.

[security curmudgeon]

: Widely deployed open source software is commonly believed to contain
: fewer security vulnerabilities than similar closed source software due
: to the possibility of unrestricted third party source code auditing.
: Predictably, most users of open source software do not invest a
: significant amount of time to audit the applications they use and now a
: class of 25 students has discovered 44 vulnerabilities during a CS
: course.

: D.J. Bernstein (http://cr.yp.to/djb.html) is lecturing a course this
: fall at the University of Illinois at Chicago called "MCS 494: Unix
: Security Holes" (http://cr.yp.to/2004-494.html). One of the requirements
: to pass the course was to find and exploit 10 previously undiscovered
: security holes in currently deployed Unix software.
:
: With a class of 25 students discovering 44 vulnerabilities most students
: now expect to fail the course
: (http://it.slashdot.org/article.pl?sid=04/12/15/2113202).
:
: The 44 security advisories have been published at
:
: http://tigger.uic.edu/~jlongs2/holes/

In each case, Professor Bernstein notified the author of the vulnerable
package on Dec 15 via e-mail. This mail hit Bugtraq on the 16th, giving
one day for vendors to provide fixes.

Is the class on responsible disclosure next semester perhaps?

[D. J. Bernstein]

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 Bugtraq on the
> 16th, giving one day for vendors to provide fixes.

Actually, I sent all of these notifications to the public securesoftware
mailing list (http://securesoftware.list.cr.yp.to) at the same time that
I sent them to the authors. It certainly wasn't my intention to give the
authors an extra day of self-delusion.

> Is the class on responsible disclosure next semester perhaps?

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 examples on
subsequent days of how people react to full disclosure when they're
trying to protect their shoddy security practices.

The reason that the 16 students sent their 91 reports to me privately is
so that they wouldn't have to deal with people like you. It was entirely
my decision to send out these 44 public notices.

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

[Julian T J Midgley]

On Fri, 17 Dec 2004, security curmudgeon wrote:
>
> In each case, Professor Bernstein notified the author of the vulnerable
> package on Dec 15 via e-mail. This mail hit Bugtraq on the 16th, giving
> one day for vendors to provide fixes.
>
> Is the class on responsible disclosure next semester perhaps?

To be honest, I was pleasantly surprised that DJB had bothered to contact
the authors at all. He once said, in a discussion about the
securesoftware mailing list, which he touted at the time as a competitor
to bugtraq:

"Immediate full disclosure, with a working exploit, punishes the
programmer for his bad code. He panics; he has to rush to fix the problem;
he loses users.

You're whining that punishment is painful. You're ignoring the effect
that punishment has on future behavior. It encourages programmers to
invest the time and effort necessary to eliminate security problems."

http://groups-beta.google.com/group/...76548f53195b01

By which standard, 24 hours is the height of responsibility. Admittedly,
the vulnerabilities were notified to the securesoftware list
(http://securesoftware.list.cr.yp.to/archives.html) concurrently with
author notification, but since there have been only 57 messages sent to
that list in the last three years, 44 of which were the student discovered
vulnerabilities themselves, I doubt it has a large readership ;-)

The actual notifications to the world (via slashdot and later bugtraq)
don't seem necessarily to have occurred at DJB's instigation, so he may
have been intending to give the authors a chance after all.

Notwithstanding all that, the course itself seems like an excellent idea
to me, and it will be interesting to see if useful statistics on the rates
incidence of security holes in software, and techniques for detecting them
and, ideally, preventing their inclusion in the first place, come out of
it.

Julian

--
Julian T. J. Midgley http://www.xenoclast.org/
Cambridge, England.
PGP: BCC7863F FP: 52D9 1750 5721 7E58 C9E1 A7D5 3027 2F2E BCC7 863F

[Marcin Owsiany]

On Fri, Dec 17, 2004 at 01:16:44PM +0100, cees-bart wrote:
> Most of the 44 posted "security" advisories are about software bugs with
> a very low security risk. See for example the posted bug on NASM
> (http://tigger.uic.edu/~jlongs2/holes/nasm.txt): what's the chance of an
> evil asm file being sent to an ignorant user that calls nasm to compile
> this file?

You are right, that this is very low risk.

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

> If I mail out a shell script that does "rm -rf $HOME/*",
> this can also be considered a remotely exploitable security hole.

The difference between nasm executing arbitrary code and a shell script
causing a shell to execute "rm -rf $HOME/*" is that the first IS NOT
meant to do that, and the second IS meant to do that. So let's not
compare those two.

Actually while the bug in nasm is very low risk, it is such bugs that
make it difficult to build new software using other software as building
blocks - you would need to audit and fix nasm before you could use it in
an web-to-assembler-gateway :-)

regards,

Marcin
--
Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216

"Every program in development at MIT expands until it can read mail."
-- Unknown

[Jonathan T Rockway]

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>

[milw0rm Inc.]

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

[Dave Holland]

On Mon, Dec 20, 2004 at 05:14:22PM -0600, Jonathan T Rockway wrote:
> Two points.

Me too, two.

> Regarding local versus remote, look at it this way: You have a 100%
> secure system.

There's no such thing.

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

As has already been pointed out, a user from the network could send me a
shell script containing "rm -rf ~". I'd be mad not to inspect a random
unsolicited shell script before I ran it. I'd be mad not to inspect a
similarly unsolicited NASM file before I assembled it; ditto input to
csv2xml, abcm2ps, or many of the other "vulnerable" programs.

This is not to belittle the effort that went into finding these bugs.
Just to say that labelling them all as "remotely exploitable" is rather
overstating the case.

Dave
--
** Dave Holland ** Systems Support -- Special Projects Team **
** 01223 494965 ** Sanger Institute, Hinxton, Cambridge, UK **

[Thor]

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

You still need a local account: the one used by the user coaxed into
assembling the code. The fact that the source of the code in your example
was from a network user does not make it a remote exploit; one could just as
easily write the code on a bubble gum wrapper and have the user type it in,
then assemble it. Your example simply bypasses this logic by providing
circumstances where the attacker need not possess the local account
credentials, though a local account is most certainly needed to exploit the
vulnerability.

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

I doubt seriously that many will read this statement and interpret it
magnanimously. The "you're lucky we didn't use it for criminal purposes"
position doesn't exactly leave one all warm and fuzzy. To me, there are
many other aspects of the "full-disclosure" debate that should be considered
within the context of how the community is affected before the "well, I
could have done this as an individual" statements are made.

T





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

[Stephen Samuel]

Side effects is my issue here.

It'a a fine thing to encourage programers to design their software well,
and fix bugs quickly. I've got no problems with punnishing programmers
for bad code, but there are different issues to deal with in the classroom
and out in the wild.

If you wanted to run a course where students are failed for having one bug
in a 10,000 line project, they were aware of the standards going in, and
given the training and tools such that the standard wss achievable, not
only wouldn't I have a problem with it -- I'd encourage everybody I knew
to hire anybody who passed the course. (at least, anybody I knew who
gave a rat's ass about producing quality code).

When dealing with code out in the wild, however, you have two communities
to consider -- the programming community and the user community. Hmm. OK,
three -- there's also the cracking community.
We're now living in a world where the time from description of a bug
and creation of a commercially viable exploit can approach zero. The
'commercially viable' exploits are viruses and worms used to generate
zombie armies of tens of thousands of remote-controllable 'bot machines
that can spread spam, launch DDOS exploits and do whatever else their
controllers wish.


Out in the wild, there is a wide gamut of care about producing quality
code and fixing bugs. At one extreme is Microsoft taking about 6 months
to *NOT* fix a security bug in WMP 9. (The fix is only available in WMP
10 released this week). That the programmer who reported the bug to MS
would wait the 6 months for _any_ real response from MS, I would agree
with your probble determination that it is a disservice to the user
community and does little more than reward MS for "trying to protect
their shoddy security practices."

Near the other extreme are BSD coders working feverishly to fix a bug
(and find any related errors) with _theoretical_ secrity issues in
their code in mere hours because the code was security related and they
felt a very real responsibility to ensure that their community had secure
code.

I would think that an optimal responsible disclosure policy should be
designed to (as much as possible) punnish the former while enabling the
latter. Not all coders hav achieved your standard of never, ever
releasing buggy code at any time of their life. As much as we may wish
otherwise, I doubt that that day will arrive soon either. A realistic
disclosure policy needs to take into accunt the interests of the three
communities I mentioned above.

I would suggest that a realistic disclosure policy would:

1) Discourage and punnish shoddy security practices.
2) Enable responsible software maintainers to realisticly respond
to bugs.
3) Give the user community timely and usable information about bugs in
the code that they're using.
4) Minimize the ability of the cracker community to exploit these bugs
before 1 and 2 have

Your zero Time To Respond approach would address 1, but do nothing
to astisfy 2-4. It doesn't so much punnish bad programmers as it
does encourage crackers to read your missives. Even the best of
programmers have to sleep, and if you release your exploit just
exploit just as the team/person responsible for the maintenance of
a piece of software is going to sleep, crackers will have up to
8 hours to code and use your bug before the responsible programmer
even wakes up to read the email about exploited code.

Even if rd party coders have managed to generate a fix, there won't
be an official release of the fix until the responsibe programmers
have at least had an opportunity to vette the proposed fixes.

A reasonable and responsible disclosure policy should be to (unless
there are signs that an exploit is already in use) allow responsible
a realistic (if short) opportunity to fix the instant bug and audit
their code for similar errors -- thus at least allowing the
*possibility* that a fix could be released at the same time as the
announcement of the bug.

If a fix can be announced at the same time as the bug, users have an
opportunity to install the fix while crackers are still crafting a
commercial exploit.

I don't think that 24-48 hours (or even longer) is an unreasonable
arning time for unexploited bugs. I'm not asking for time to 'be
delusional', 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.

6 months with no fix, on the other hand is obscene. I honestly
doubt if companies like Microsoft will ever treat Security as
a genuine responsibility aas opposed to a PR issue. On the other
hand, it is far less likely that they'll start responding
reasonably if they don't even have a hope of being able to craft
a fix before crackers have created a 'live' exploit.

D. J. Bernstein wrote:
> 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 Bugtraq on the
>>16th, giving one day for vendors to provide fixes.
>
>
> Actually, I sent all of these notifications to the public securesoftware
> mailing list (http://securesoftware.list.cr.yp.to) at the same time that
> I sent them to the authors. It certainly wasn't my intention to give the
> authors an extra day of self-delusion.
>
>
>>Is the class on responsible disclosure next semester perhaps?

Also posted: http://www.bcgreen.com/comments/2004/bug-release.html
--
Stephen Samuel +1(604)876-0426 samuel@bcgreen.com
http://www.bcgreen.com/~samuel/
Powerful committed communication. Transformation touching
the jewel within each person and bringing it to light.

[Devin Ganger]

Jonathan T Rockway writes:

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

By that logic, *no* exploit can ever be considered local. A truly remote
exploit doesn't rely on manual interaction from a local user on the
system.

> Now in regards to full disclosure, I think you should all be=20
> happy that we bothered to tell you all about these exploits. =20
> We could have selfishly used them to compromise machines,

When you're trying to argue that your actions were ethical and moral,
pointing out that you could have committed crimes isn't the way to do
it.

> but instead we wrote them up and mailed them off to the users and=20
> the authors! That is very nice of us.

No, it's the absolute minimum level of ethical behavior one expects from
serious security researchers. Nothing nice about it.

> If you would like notification sooner than the "public", find=20
> the exploit yourself. If I can find them, then surely anyone can.

One day, when you are writing software for distribution, someone will
find an error in your code. When that day comes, remember this attitude.
While those who discover those bugs and exploits in your software have
no obligation to give you advanced warning of your bugs, I'm certain
you'd be grateful to have that warning so you have time to fix the bug
before word goes public.

--=20
Devin L. Ganger Email: deving@3sharp.com
3Sharp LLC Phone: 425.882.1032 x 109
15311 NE 90th Street Cell: 425.239.2575
Redmond, WA 98052 Fax: 425.702.8455

[David F. Skoll]

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

> 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's nonsense. 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.

> 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!

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.

--
David.

[Stephen Harris]

On Mon, Dec 20, 2004 at 05:14:22PM -0600, 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

And so we have a distinction without meaning.

I could take a machine with no external connectivity beyond a single
keyboard and monitor and by typing in a listing from a piece of paper
use a command to reformat the system and lose all data. Remote exploit?
By your usage of the term it is.

In your example, a local user MUST take action in order to perform
the exploit, therefore the exploit is local. Your "FROM THE NETWORK"
is meaningless; it could be sent on floppy or printout or via psychic
rays and get the same result.

> 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

And thus years of discussion on this, and other, lists about responsibility
and concern goes out of the window. But that's a matter between you and
your conscience. Be happy!

--

rgds
Stephen