![[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 EditorialsThe inherent problems in /tmp. A topic of much discussion on BugTraq this week was the security problems inherent in the use of a /tmp directory. It was pointed out, arguably enough, that the entire /tmp model is in direct conflict with the overall Unix model of security. Unix was developed as a time-sharing system, thus it was also designed to protect one user from the actions of another. Into this model was introduced /tmp, a shared directory to which anyone had write privileges and the ability to delete files created by other users. Why? Looking back from a historical angle, one might first guess that it was introduced due to limited resources, in order to share space more efficiently. On the other hand, Unix filesystems already do this quite efficiently. There is no advantage from a space perspective from having a shared /tmp directory as opposed to a /tmp/$user directory hierarchy. The same rules about file deletion could be applied to this type of space; as a systems administrator, this editor managed many "temporary disks", large amounts of shared space with a limited life-span for the files on the disk. These disks were not managed as world-writable directories; instead, they contained subdirectories for each user. Cudgeling the memory cells as to when and why /tmp was used, its earliest advantages all amounted to programmatic convenience. It was easier to scrub a single directory than a directory hierarchy. It was easier for a programmer to know the name of a directory to which temporary files could be written and to assume that such files would be automatically deleted, rather than manage the deletion directly. Files written to /tmp didn't clutter up a user's home directory, didn't count against the normal disk quotas. In general, simple checks to make sure sufficient space existed on the disk before writing were skipped as well. As best as we can remember, /tmp is simply a programmatic convenience. Of course, /tmp was also adopted during an era of extreme trust, so the security issues were simply not considered to be as important as making sure that people could work easily and conveniently while efficiently sharing resources. The first rule of thumb in a /tmp-related vulnerability is that the programmer is at fault. This is correct; an application that uses a temporary file in a world-writable directory has a responsibility to do so securely. Nonetheless, the use of world-writable directories will continue to be a source of new vulnerability reports. Any distribution that prides itself on security would be wise to implement, by default, a system with user-specific temporary file storage, either under $HOME or elsewhere. Of course, the first one to try will be the one to find all the applications that ignore the TMPDIR environment variable and have "/tmp" hard-wired into the application. It would not be an easy or simple transition. All of this is theoretical, of course. What is not theoretical right now is the need for all programmers to fix sloppy programming habits in the way they use /tmp. Kris Kennaway posted a nice, concise message which should serve as a good rule of thumb for how to deal with /tmp, leaving us with applications that will work whether a system uses a shared /tmp directory or some safer alternative. December CRYPTO-GRAM newsletter. Bruce Schneier's CRYPTO-GRAM newsletter for December is out. It covers, of course, electronic voting, along with a look at IBM's new crypto algorithm and digital safe deposit boxes. The newsletter is also available on Bruce's site.Slackware Linux announces OpenSSL cryptography libraries. Slackware Linux announced the addition of the OpenSSL cryptography libraries and the OpenSSH suite of network connectivity tools. Users of Slackware 7.1 and -current can download these packages from Slackware's current developmental tree.eCrime, Law and You (ZDNet). The Wall Street Journal's Keith Johnson takes a look at The HoneyNet Project in his article eCrime, Law and You. Honeypots are baited traps for hackers. In this case, the honeypots are used primarily as learning tools, with a "know your enemy" concept.
"To be sure, Spitzner's HoneyNet Project -- which includes some 30
security professionals, programmers and psychologists, all working on the
project in their spare time -- isn't the first time honeypots have been
used to gather intelligence on the Internet underground. ...
But unlike previous honeypots, which were baited with known
vulnerabilities designed to mimic various computers, Spitzner's team puts
unmodified production systems online -- networks with the same
specifications, operating systems and security as those used by many
companies. And this project isn't a hush-hush, internal corporate
operation like previous honeypots: Spitzner posts all of his findings on
the Internet for the security community to see at project.honeynet.org Kaspersky Lab 'year end' review. Kaspersky Lab has published a anti-virus year in review document. It's mostly Windows-oriented, of course, but there is a brief section on Linux. "Despite the fact that some species are able to replicate and work independently, no Linux virus has ever been detected 'in-the-wild.' Kaspersky Lab experts assume that this is because the Linux desktop standard is not as popular as its competitors." ...or, perhaps, it's the fact that it takes a little more than a bogus email attachment in the Linux environment...?Security ReportsGnuPG web of trust circumvention. A couple of security problems with GnuPG were discussed on the gnupg development mailing list recently. The first problem deals with web of trust circumvention, made possible because private/secret keys will be imported from public key servers along with private keys, without user intervention. The same problem can occur via the "--import" option.As a result, a new "--allow-secret-key-import" option has been added to GnuPG and a security patch against GnuPG 1.0.4 has been released. Note, we compliment Red Hat on their advisory on this topic, which provided excellent references for tracking down the original source material for these vulnerabilities. This week's updates: Zope local role and DTML editing vulnerabilities. It has been a busy week for the Zope team. Two more security hotfixes were released this week, one for a problem with the processing of local roles and the other a problem where users with DTML editing privileges can manipulate the raw data of an object for which they have no privileges.These two vulnerabilities following quickly on the report of a Zope legacy vulnerability last week. Zope 2.2.5 should be released in the near future, including all the recent security hot fixes.
This week's updates:
JPilot directory permissions problem. JPilot is a desktop organizer for the PalmPilot that allows information from a PalmPilot to be sync'd to the disk of a Unix or Linux system. A directory permissions problem was reported in JPilot by Weston Pawlowski. By default, JPilot uses the default umask on its ".jpilot" subdirectory and files. As a result, private information, including possibly passwords, may be readable and/or writable. An easy workaround is to change the default permissions on the ".jpilot" directory. Check BugTraq ID 2136 for more details.nano tmplink vulnerability. Nano is a free pico clone. Not too surprisingly, it has also been found to be vulnerable to the same tmplink problem originally reported in the joe editor in November. Check BugTraq ID 2135 for more details.This week's updates: stunnel local arbitrary command execution. stunnel is an SSL encryption wrapper designed to be used with Internet daemons such as POP and IMAP, to prevent cleartext passwords from passing across the network. Insecurely-structured calls to syslog can be exploited by a remote attacker to gain local access, potentially as root. The release of stunnel 3.9 fixed this problem, as well as others. For more details, check BugTraq ID 2128.This week's updates: BSD ftpd single byte buffer overflow. The ftpd daemon provided with NetBSD and OpenBSD was found to be vulnerable to a one byte overflow, which can be exploited remotely to gain root access. Note that this vulnerability is being actively exploited. FreeBSD and Linux systems are not vulnerable. The anonymous ftp service must be enabled and a writable directory provided for the exploit to work. OpenBSD has released a patch and the NetBSD CVS source tree is reported to have been fixed. Check BugTraq ID 2124 for more details.
Multiple vulnerabilities in FreeBSD procfs. FreeBSD issued an advisory warning of multiple vulnerabilities in procfs which can be exploited locally to gain root, to hang the system or to bypass restrictions on the super-user account. Workarounds and patches are made available. Note that they mark this vulnerability as not specific to FreeBSD. Presumably Linux systems are not impacted, but other BSD systems may be. For more details, check BugTraq IDs 2131 and 2132.Another potential buffer overflow in bftpd. bftpd 1.0.13 was announced last week to address multiple vulnerabilities, including multiple buffer overflows. This week, an additional potential buffer overflow was reported by Christophe Bailleux. Perhaps as a result, bftpd 1.0.14 was released this week, with a note that security has been improved yet again.expect buffer overflow. Expect is a nice tool for automating interactive applications. This week, a buffer overflow in expect was reported. Any script written with expect can be exploited. Of course, only setuid/setgid scripts will subsequently yield an increase in privileges. No information on a fix for this problem has been reported yet.itetris local root vulnerability. An exploit has been published that can reportedly be used to gain local root access via a 'system' call whose input is not thoroughly checked. No confirmation, patch or fix for this has been posted yet; you may wish to disable itetris on your system until one is made available.ProFTPD memory leak. A potential memory leak in ProFTPD was reported this week which could be exploited to cause a denial-of-service attack via the use of the SIZE command. Sample code to demonstrate the problem has been posted. The developers have been informed, but have not yet been able to recreate the symptoms.cgi-bin scripts. The following cgi-bin scripts were reported to contain vulnerabilities:
Commercial products. The following commercial products were reported to contain vulnerabilities:
UpdatesSecure Locate buffer overflow. Originally reported in the November 30th LWN Security Summary, the first distribution update for this problem came in this week from Debian.This week's updates: Zope security update. The Zope Legacy vulnerability was reported last week. All versions of Zope up through 2.2.4 could be exploited to allow anonymous users privileges inside the server. The application of the Zope Legacy hotfix is highly recommended.This week's updates: Previous updates:
DNS-based IRC server denial-of-service vulnerabilities. Check last week's Security Summary for the original report of denial-of-service vulnerabilities and more in multiple IRC clients, including BitchX 1.0c17-2 and earlier.This week's updates: Previous updates:rp-pppoe denial-of-service vulnerability. Also first reported last week, Roaring Penguin Software's PPPoE client (a user-space PPP-over-ethernet client) contains a boundary condition exception that can be exploited to cause the connection to drop when a malformed TCP packet is received. rp-pppoe 2.5 has been released to fix the problem.This week's updates: Previous updates:
Oops buffer overflow. Check the December 14th LWN Security Summary for the original report. Version 1.5.1 has been released with a fix for this problem.This week's updates: ssldump format string vulnerability. Last week, we discussed a format string vulnerability in ssldump. This week, ssldump author Eric Rescorla responded, pointing out that the issue is not actually a format string vulnerability; it is "a pointer indirection problem resulting from a bug in the handling of sequence number wraparound". He is working on a fix for the problem and asked people to let him know of any other problems in ssldump that they find.pam_localuser buffer overflow. A buffer overflow was reported in the pam_localuser module on December 7th.This week's updates:
ed symlink vulnerability. Originally reported on November 30th, Alan Cox noticed that GNU ed, a basic line editor, creates temporary files unsafely. The problem has subsequently been fixed in ed 0.2-18.1.This week's updates: Previous updates:
Netscape 4.75 buffer overflow. First spotted via this FreeBSD advisory and reported on November 9th, a buffer overflow in Netscape 4.75 enables a client-side exploit. Check the November 9th LWN Security Summary for our original report. Netscape 4.76, which was released on October 24th, fixes the problem.This week's updates: Previous updates:
tcsh symlink vulnerability. A /tmp symbolic link vulnerability was reported in tcsh on October 29th. Check BugTraq ID 1926 for more details. This week's updates: Previous updates:
klogd/sysklogd format string vulnerability. Check the September 21st LWN Security Summary for the original report of this problem. Note that the "new" advisory listed this week is actually quite old; we don't know what kept it from getting posted in September, when it was dated, but we have included it this week in order to give a round report on available updates for this problem. This week's updates:
Resourcessshmitm and webmitm. Dug Song released sshmitm and webmitm this week. These are tools for testing potential simple active monkey-in-the-middle attacks against SSH and HTTPS. EventsUpcoming security events.
For additional security-related events, included training courses (which we don't list above) and events further in the future, check out Security Focus' calendar, one of the primary resources we use for building the above list. To submit an event directly to us, please send a plain-text message to lwn@lwn.net. Section Editor: Liz Coolbaugh |
December 21, 2000
LWN Resources | |||||||||||||||
Copyright © 2000
Eklektix, Inc., all rights reserved
Next: Kernel