Re: [SC-L] [Fwd: DJB's students release 44 *nix software vulnerability advisories]
At 12:16 AM -0500 12/22/04, der Mouse wrote: >I'm not sure whether this list's focus is more "how do we write code >more securely, assuming we have the mandate to do so" or "how do we >cause more of the code written to be more secure" (or perhaps something >else). The latter is a political-economic task, fairly disconnected from the former (presuming the former is possible at all). -- Larry Kilgallen
Re: [SC-L] [Fwd: DJB's students release 44 *nix software vulnerability advisories]
>> To have fewer bugs due to an external audit, that external audit >> would have to happen, not just be possible. > Not necessarily. Just the threat of public embarrassment [...] could > cause open source developers to be more disciplined in the first > place. This hypothesis has been around for quite some time as part > of the "open source is better" hype. > However, it is also unsubstantiated. I'm also not entirely certain it's as relevant as the discussion makes it sound. As someone who insists on source code (not necessarily open source by any of the various definitions floating around - but if *I* don't have source, I don't run it), my reasons aren't so much that I think it likely to be more nearly bug-free as much as that if I suspect a bug, I can go check, and if I encounter a bug, I can go fix it. Or at least much more nearly so. I've run into bugs in gcc that I am not competent to fix, but I've been able to fix a much higher proportion of the bugs (and nonbugs that I desire to have changed, such as feature enhancements) I've run into when I've had source than when I haven't. However, until a significant fraction of the market starts making similar choices, it won't have any significant effect on the mandates handed from managers to coders - and shops where managers hand out orders to coders are still where almost all of the code comes from, whether in terms of number of programs, number of lines, number of copies run, whatever. I've seen indications that this is starting to happen, which I (being a fairly strong source-code bigot) find encouraging. But they're still just preliminary rumblings. I'm not sure whether this list's focus is more "how do we write code more securely, assuming we have the mandate to do so" or "how do we cause more of the code written to be more secure" (or perhaps something else). /~\ The ASCIIder Mouse \ / Ribbon Campaign X Against HTML[EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: [SC-L] [Fwd: DJB's students release 44 *nix software vulnerability advisories]
Shea, Brian A wrote:
Isn't the base problem residing in this essentially flawed statement:
"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."
To have fewer bugs due to an external audit, that external audit would
have to happen, not just be possible. Assuming fewer bugs because an
Audit COULD happen is like saying we're all infected with Bird Flu
because it COULD happen.
Not necessarily. Just the threat of public embarrassment ("lookit the
crappy code that Jone DOe wrote! ") could cause open source
developers to be more disciplined in the first place. This hypothesis
has been around for quite some time as part of the "open source is
better" hype.
However, it is also unsubstantiated.
Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
CTO, Immunix http://immunix.com
RE: [SC-L] [Fwd: DJB's students release 44 *nix software vulnerability advisories]
At 8:19 AM -0800 12/20/04, Shea, Brian A wrote: >Isn't the base problem residing in this essentially flawed statement: > >"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." The only flaw in that statement is that it is likely to be misinterpreted, and perhaps was even misinterpreted by the author. The notion that something "is commonly believed" is quite different from the notion that something "is true" ! -- Larry Kilgallen
RE: [SC-L] [Fwd: DJB's students release 44 *nix software vulnerability advisories]
Isn't the base problem residing in this essentially flawed statement: "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." To have fewer bugs due to an external audit, that external audit would have to happen, not just be possible. Assuming fewer bugs because an Audit COULD happen is like saying we're all infected with Bird Flu because it COULD happen. I suspect that while this class found 44 bugs, what they really found was a deeper issue; that people aren't actually auditing the software enough, open source or not. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gadi Evron Sent: Saturday, December 18, 2004 2:35 AM To: [EMAIL PROTECTED] Subject: [SC-L] [Fwd: DJB's students release 44 *nix software vulnerability advisories] [Ed. Cross-posted from Bugtraq... KRvW] Subject: DJB's students release 44 *nix software vulnerability advisories Date: Thu, 16 Dec 2004 01:47:12 -0800 Message-ID: <[EMAIL PROTECTED]> From: "Thor Larholm" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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. 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/ 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. [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/con
[SC-L] [Fwd: DJB's students release 44 *nix software vulnerability advisories]
[Ed. Cross-posted from Bugtraq... KRvW] Subject: DJB's students release 44 *nix software vulnerability advisories Date: Thu, 16 Dec 2004 01:47:12 -0800 Message-ID: <[EMAIL PROTECTED]> From: "Thor Larholm" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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. 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/ 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. [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_ad
