![[LWN Logo]](http://old.lwn.net/images/lcorner.png)
![[LWN.net]](http://old.lwn.net/images/security.png)
|
|
|
 Sections: Main page Security Kernel Distributions Development Commerce Linux in the news Announcements Back page All in one big page See also: last week's Security page. |
SecurityNews and EditorialsCERT to disclose software flaws (ZDNet). CERT, the first official "Computer Emergency Response Team", was founded in 1988 by DARPA (Defense Advanced Research Projects Agency). It quickly became an essential resource for computer systems administrators dealing with a (then rare) computer intrusion. Over time, however, CERT's policy of contacting all vendors in advance about security problems, and giving them all time to provide fixes, led to longer and longer lead times before security problems were announced. This was particularly troublesome when the reported vulnerability was widely known and being actively exploited.CERT's policy did a lot to demonstrate the need for full disclosure lists, such as BugTraq, which came along later. CERT's policy failed to put much needed pressure on vendors to make security a high priority. Now, in the midst of large-scale debates about whether or not full disclosure is a "good thing", CERT has finally, twelve years later, changed its own policy. Whether or not all vendors have produced fixes, CERT will now announce all vulnerabilities 45 days after they are initially reported, promising full credit to the originators of the report. We mentioned this policy change last week. This week, ZDNet has reported on it as well, commenting that "It may herald the end of a fight that has inflamed the security community for more than a decade". While we doubt that the fight is likely to be over any time soon, CERT has drawn a new line. They consider themselves to have chosen a middle course, between full disclosure and no disclosure. What they have done, instead, is to validate the arguments of full-disclosure adherents and establish a new outer limit to non-disclosure. Given the overwhelming number of new security vulnerabilities that are being reported, it is also likely that an open-ended vendor process for each vulnerability simply became impossible to support. In addition, there are many for-profit and non-profit security groups that are now in competition with CERT. CERT's announcement, as a result, is less ground-breaking and more an acceptance of the status quo: full disclosure with some set time allowed for cooperation with vendors, ranging from a matter of hours to a matter of a few weeks. 45 days is, under those rules, probably the most generous offer a vendor is likely to find. Why the world needs reverse engineers (ZDNet). Educating people on the need for reverse engineering is the goal of this ZDNet article, written by Weld Pond, Manager of Research and Development for @stake, Inc., a computer security firm. The CueCat barcode scanner from Digital:Convergence is used as an example. "Many of the privacy risks we face today such as the unique computer identification numbers in Microsoft Office documents, the sneaky collection of data by Real Jukebox, or the use of Web bugs and cookies to track users were only discovered by opening up the hood and seeing how things really work." Open Sources: The other side of the story (ZDNet). An interesting story showed up on ZDNet's Interactive Week. It's a story about security as seen through the eyes of Mudge, Vice President of R&D at the company once known as L0pht and now known as @stake. "...software consumers have become so cynical they 'need third-party proof of concept' before they'll believe the software's been fixed, and the only way that will happen is through independent review. The software companies are where Swift and Armour were in 1906, when Upton Sinclair wrote his classic expos on the meatpacking industry, The Jungle - the consumer uses the product at his own risk." OpenBSD plugs a rare security leak (Upside). Upside looks at OpenBSD's handling of security problems. "For most open source projects, news of an overlooked security hole is simply part of the debugging process. But for the developers of OpenBSD, an operating system whose design motto is 'secure by default,' it's nothing short of an affront." Security ReportsBuffer overflow problems in ncurses. A buffer overflow problem in the ncurses library has been reported by Jouko Pynnnen. As a result of this problem, programs that use ncurses are vulnerable to attack. Successful exploits have already been demonstrated, though none are known to be in use by the Bad Guys as yet. It is possible - though unconfirmed - that remotely-exploitable vulnerabilities could exist. The problem is present in most, if not all, Linux and BSD variants.Expect to see a pile of fixes show up in the next few days; we'll let you know when they are released. This is another ugly one. To help people find binaries linked against ncurses, Dominic Mitchell sent us this script, along with an example output from searching /usr/bin on FreeBSD. It quickly reported 27 possibly affected binaries... LinuxPPC security update - single user mode. LinuxPPC has issued a security update regarding single user mode login. Currently, all past and present versions of LinuxPPC (going back to 1998's Release 4.0, and possibly earlier) have a vulnerability when booting in single user mode. The computer will automatically perform a root login without asking for password. Updates are recommended, although LinuxPPC plans to have this fixed in its upcoming release.Red Hat security update to usermode. A bug report to Red Hat pointed out a new vulnerability in the usermode package. The userhelper binary inherits the LANG or LC_ALL environment variables and then passes them on to non-setuid root programs, bypassing protections recently integrated into the glibc library to prevent a format-string exploit.This week's updates:
Boa. Lluis Mora reported vulnerabilities in the Boa webserver which could both allow access to files outside the document tree and a compromise of the web server account. The Boa development team, in coordination with Lluis' advisory, released boa 0.94.8.3, which fixes these problems.This week's updates: TCP weak initial sequence numbers. The Hacker Emergency Response Team (HERT) put out an advisory for problems with the manner in which initial TCP sequence numbers are generated, leading to the ability to predict sequence numbers and therefore "spoof" packets. Their report focused on FreeBSD, which responded with this advisory, acknowledging the problem and providing patches. However, FreeBSD's advisory states that they do not believe this problem is unique to FreeBSD. We have no updated information on what other operating systems might be impacted; the implication is that all systems derived from 4.4BSD-Lite2 are likely candidates.Directory transversal vulnerabilities. The following web scripts were reported to contain directory transversal vulnerabilities, allowing arbitrary files on the web-server to be read:
UpdatesLPRng, LPR format string vulnerabilities. Format string problems in LPRng were reported in late September. Updates for LPRng and lpr (for a related problem) continue to be published.This week's updates:
ssh/OpenSSH file transfer vulnerability. All versions of ssh derived from ssh-1.2.x contain a vulnerability in which a compromised server can be used to copy arbitrary files to an uncompromised local system, if that system uses ssh/scp to download files from the compromised server. Check last week's LWN Security Summary for more details. No fixes for this problem have been reported as of yet. Some distributions are shipping updates that remove the setuid bit from the scp binary in order to minimize potential damage.This week's updates: traceroute local root access. A local user can exploit vulnerabilities in traceroute to gain root access. For more information, check last week's LWN Security Summary. Note that Red Hat 7 already included a patch to get a raw socket and then drop privileges at startup. As a result, it was not affected by this most recent report. Kudos to them for proactively fixing potential security problems before a new vulnerability pops up; it's nice to know somebody was looking at the code with security in mind.This week's updates: Previous updates:
esound tmpfile link vulnerability. Check the September 7th LWN Security Summary for the original report of this problem from FreeBSD. Linux security teams should note that it took two weeks from that initial report before a Linux update for this problem was released.This week's updates: Previous updates:
GNU CFEngine format string vulnerability. Root access can be obtained on a local system by exploiting CFEngine's use of syslog and its related format string vulnerability. Check last week's LWN Security Summary for more details.This week's updates: tmpwatch fork bomb denial-of-service vulnerability. Check the September 14th LWN Security Summary for additional details. Note that almost a month passed before the first update for this problem was released. Since then, a local root compromise problem has turned up as well; this is fixed in all of the updates.
gnorpm tmpfile link vulnerability. All version of gnorpm prior to 0.95.1 contain an improper use of a link to a temporary file that can be locally exploited to overwrite arbitrary files on the system. Check last week's LWN Security Summary for more details. The latest version contains many non-security fixes as well, reportedly making it actually usable.This week's updates: Previous updates:
Apache mod_rewrite vulnerabilty. Files outside the document root can be accessed, if the mod_rewrite module for Apache is in use. For more details, check last week's LWN Security Summary.This week's updates: ResourcesFull Disclosure Panel. A panel discussion on the issue of Full Disclosure is planned for the next episode of Info.sec.radio, a radio show produced by SecurityFocus.com and made available via RealAudio. The show will be held on Monday, October 16th. EventsUpcoming security events and announcements.
Section Editor: Liz Coolbaugh |
October 12, 2000
| |||||||||||||||||||||||||||||||||
Copyright © 2000
Eklektix, Inc., all rights reserved
Next: Kernel