Weekly Edition
Return to the Press page
| |||||||||||||
|
| |||||||||||||
Students uncover dozens of Unix software flaws (News.com)
News.com
reports on flaws found in Unix applications by graduate students.
"Students of iconoclastic computer scientist Daniel Bernstein have found some 44 security flaws in various Unix applications, according to a list of advisories posted online.
The flaws, which range from minor slipups in rarely used applications to more serious vulnerabilities in software that ships with most versions of the Linux operating system, were found as part of Bernstein's graduate-level course at the University of Illinois at Chicago."
(Log in to post comments)
Students uncover dozens of Unix software flaws (News.com) Posted Dec 17, 2004 1:44 UTC (Fri) by huffd (guest, #10382) [Link] An excerpt from the article "While the number seems high, the company said it is far lower than the number associated with most commercial software."
Students uncover dozens of Unix software flaws (News.com) Posted Dec 17, 2004 2:16 UTC (Fri) by gdt (subscriber, #6284) [Link] That's a rather misleading excerpt, as at the point of the quote the story is discussing the Linux kernel's regression testing. I read the list of bugs the students found at http://tigger.uic.edu/~jlongs2/holes/. Most of the bugs are well-known issues with the use of C, mainly buffer overflows. Some of the bugs are from trusting external input, a problem in most languages. Rather than consider the number "small", a more startling statistic is that the majority of the Linux installed base is vulnerable to at least one of the bugs the students in this small class found (prominent programs with flaws are: CUPS, mpg123, mplayer, nasm, xine).
Students uncover dozens of Unix software flaws (News.com) Posted Dec 17, 2004 2:29 UTC (Fri) by marr (guest, #5675) [Link] The 2 flaws found in the 'pcal' PostScript/HTML calendar generation application were fixed in the latest v4.8.0 release, now available on SourceForge:
For details of new features in the latest release and lots of other information, please visit the 'pcal'/'lcal' webpage:
Bill Marr (v4.8.0 release manager)
Moral of the story Posted Dec 17, 2004 5:01 UTC (Fri) by bojan (subscriber, #14302) [Link] Given that it's all open source, the patches can be on their way. With closed source, you can see the problem, but not offer the solution until the vendor decides to to get off their back side.
And that is the moral of this story. At least for me ;-)
Students uncover dozens of Unix software flaws (News.com) Posted Dec 17, 2004 7:55 UTC (Fri) by aleXXX (subscriber, #2742) [Link] That's a good thing that the flaws were found. They can happen easiliy. More universities should have courses like this.
Alex
Students uncover dozens of Unix software flaws (News.com) Posted Dec 17, 2004 10:36 UTC (Fri) by sdalley (subscriber, #18550) [Link] Does anyone know of any projects or teams, apart from the cracker underground, who make it their business to systematically find vulnerabilities like this? They'd be doing everybody a great service, in the longer term.
(Ah, yes, OpenBSD have been doing this for years, of course, but is there anyone else?)
Systematically rooting out old-offenders like sprintf, strcat, strcpy, strncpy, strncat, (not to mention any remaining occurrences of the unspeakable gets()), and replacing them with snprintf, strlcpy, strlcat, fgets, would be a jolly good start, eliminate most of the holes found in the reported examples, and often make them more efficient as well.
See http://www.courtesan.com/todd/papers/strlcpy.html .
For some impenetrable reason, the GNU C library does not include strlcpy, strlcat, maybe because it was invented by the BSD lot.
Students uncover dozens of Unix software flaws (News.com) Posted Dec 17, 2004 10:43 UTC (Fri) by pjdc (subscriber, #6906) [Link] It's more that Ulrich Drepper thinks the strl* functions are no good.
Students uncover dozens of Unix software flaws (News.com) Posted Dec 17, 2004 10:58 UTC (Fri) by sdalley (subscriber, #18550) [Link] Yes, one could use exactly the same argument as Drepper's to say that safety razors are completely nonsense, they don't increase safety, they only allow sloppy shavers get by without having to learn the use of an old-style cutthroat.
The track record of OpenBSD, however, speaks for itself.
Students uncover dozens of Unix software flaws (News.com) Posted Dec 17, 2004 18:17 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] The strl* functions are not magic, though they can be useful in getting rid of one class of error (and replacing it with another, less severe, class of error: the silent truncation of long lines).Reading a line into a fixed-sized buffer is the problem, and use of strl* functions to get rid of the buffer overrun is only a band-aid. You may think that you can assume that no valid line will be more than N characters, and later on break when you get N+1 characters. You can get subtle bugs because strings are truncated to different lengths in different places. Read lines into dynamically-sized buffers instead, e.g. std::string for C++ programmers, appropriate library for C programmers. The GNU Readline library, for example, does not impose arbitrary limits on string length (as long as you have virtual memory).
Students uncover dozens of Unix software flaws (News.com) Posted Dec 17, 2004 20:35 UTC (Fri) by sdalley (subscriber, #18550) [Link] > Reading a line into a fixed-sized buffer is the problem,> and use of strl* functions to get rid of the buffer overrun > is only a band-aid.
Well, yes, but only if you use it rather mindlessly without checking the return value. If this compares greater than the len parameter then you know immediately that the result is truncated.
In the case where you expect meaningful strings to be relatively short and longer ones to be erroneous, strl* functions are ideal and it makes perfect sense to have fixed-sized buffers. In the case where strings of arbitrary length are meaningful, you obviously want a fully dynamic solution such as asprintf and friends - see http://www.mibsoftware.com/libmib/astring/ .
Students uncover dozens of Unix software flaws (News.com) Posted Dec 17, 2004 22:50 UTC (Fri) by hppnq (subscriber, #14462) [Link] Well, yes, but only if you use it rather mindlessly without checking the return value.Exactly. Hence the band-aid.
Glibc and strlcpy Posted Dec 18, 2004 5:53 UTC (Sat) by ncm (subscriber, #165) [Link] Ulrich is right, as far as he goes.However, by not providing bindings for functions with those names, he encourages sloppy programmers porting programs that call them to grab the BSD implementation and add it in. If Glibc were to implement strlcpy etc. but, instead of returning a value to be checked, simply log an error and call abort(), then the bugs would have attention called to them. They could not just silently fail no matter how sloppily coded. Of course, sloppy code shouldn't be run at all (there are a lot more ways to fail than strcpy!). A program that is always aborting is less likely to be run. Problem solved.
Glibc and strlcpy Posted Jan 2, 2005 9:54 UTC (Sun) by raboofje (guest, #26972) [Link] I would think that's a pretty bad idea: it introduces a `crash' at run-time rather than at compile-time. If the error is, for example, in some rarely-encountered but vital error-handling code, you might get bitten hard.
The ability to see these kind of things at compile-time is one of the main reasons I often choose compiled languages over interpreted ones.
Students uncover dozens of Unix software flaws (News.com) Posted Dec 17, 2004 12:33 UTC (Fri) by metaur (guest, #13633) [Link] Well, we also have Debian Security Audit Project (which I'm involved in):
http://www.debian.org/security/audit/
and Gentoo Linux Security Audit Project:
http://www.gentoo.org/proj/en/security/audit.xml
// Ulf Harnhammar
Students uncover dozens of Unix software flaws (News.com) Posted Dec 17, 2004 21:46 UTC (Fri) by error27 (subscriber, #8346) [Link] Some secure Linux distros audit software pretty carefully. The problem is you have to limit your focus quite a bit. Some admins audit the code for the daemons they run... For example, stay away from mp3 streamers.
Who's going to go looking for exploits in nasm? Not so many people run nasm. People that do run nasm don't need to do it as root.
In the end, you have to understand that there will always be security bugs. Use a firewall, use kernel hacks to stop buffer overflows, don't run software as root and make backups.
Students uncover dozens of Unix software flaws (News.com) Posted Dec 18, 2004 16:39 UTC (Sat) by tzafrir (subscriber, #11501) [Link] Bah.
I have just installed my Linux Desktop. I want it to just work, and work well. I don't want to have to live in constant fear.
Living in fear Posted Jan 2, 2005 9:58 UTC (Sun) by raboofje (guest, #26972) [Link] Well, there *will* always be security problems, but on this point other OS'es are at least as `scary' as Linux...
vulnerability disclosure policies Posted Dec 17, 2004 10:37 UTC (Fri) by DonDiego (subscriber, #24141) [Link] Whatever happened to informing authors/vendors of vulnerabilities first and giving them some time to patch the application before making issues public? I work on MPlayer and we were not informed prior to making the vulnerability public, a mail was sent to our users mailing list (not even the developers mailing list) at the same time it was sent out to the world. Irresponsible behavior IMNSHO.
vulnerability disclosure policies Posted Dec 17, 2004 12:24 UTC (Fri) by clugstj (subscriber, #4020) [Link] Publicity Stunt.
vulnerability disclosure policies Posted Dec 20, 2004 22:15 UTC (Mon) by darthmdh (guest, #8032) [Link] Dan Bernstein doesn't believe in responsible disclosure. He believes programmers should be "punished" for bad code.
http://groups-beta.google.com/group/comp.security.unix/ms...
I agree, which is why I don't run qmail :-)
Students uncover dozens of Unix software flaws (News.com) Posted Dec 17, 2004 15:46 UTC (Fri) by dlapine (subscriber, #7358) [Link] Perhaps a better title would be "Students fail in attempt to meet class requirements to find 10 vulnerabilities per student in deployed any deployed unix code." I know that this title doesn't have the same ring, but maybe it's more relevant. When the entire class can only find 44 bugs in all deployed unix software, I'm wondering what they could do given access to the source for all Windows (TM) compatible packages... I'll also point out that some vulnerabilites they found are somewhat hard to trigger.
This does have some aspects of a publicity stunt, certainly in the extent that this as been reported.
Students uncover dozens of Unix software flaws (News.com) Posted Dec 18, 2004 13:49 UTC (Sat) by edt (subscriber, #842) [Link] What would I say to this? Thank you, please try to find more.I've been following the LKML for years. Checkers have been run on the kernel source and uncovered many problems - which were promptly fixed. In this case applications were parsed too. Great! The more audits like this are done the fewer problems I will have. Ed
|
|
||||||||||||