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. |
News and EditorialsPGP meets ADK. PGP (Pretty Good Privacy) has been around for a long time. It is a public-key encryption technique, developed by scientist Phil Zimmerman, that was, and is, a very commonly used public-key encryption system. It is not free, however, though PGP Security makes freeware versions available for Unix/Linux, in addition to their commercial offerings. Over the past week, though, reports have come in about security problems with PGP. What is going on? Well, recent versions of PGP have introduced the concept of Additional Decryption Keys (ADKs). This allows a public certificate to contain multiple decryption keys. What is the purpose of an ADK? CERT comments, tactfully, "This configuration might be used, for example, in environments where data encrypted with an individual's key also needs to be available to their employer." It can also be used by governments that wish to require key escrow systems, whereby a third party can use an ADK to read an encrypted communication (if, for example, a police investigation gets a court order for the release of the secondary key). Unfortunately, the newly introduced ADKs brought with them some improprieties. For example, PGP clients have not been checking to make sure that an ADK was signed by the owner of the public key. That allows another entity to submit a modified public key to a public key authority, including an additional ADK that will allow them to get access to the contents of encrypted code, if the sender of the encrypted code uses the corrupted public key. What needs to be done? The problem has to be fixed in more than one place. PGP-based software needs to check to make sure that ADKs are authorized, and warn senders of ADKs in the public key even if they appear to be authorized. That means you need to make sure the PGP client you use has been fixed. Public key authorities need to reject the submission of altered public keys that contain unsigned ADKs. In amongst this, there is some confusion as to whether this entire issue impacts Unix/Linux machines or only Windows machines. The CERT summary, mentioned above, is silent on this point. This ZDNet article states that only Windows clients are impacted. PGP Security has released updates for all platforms, including their freeware version of PGP for Unix/Linux. This BugTraq post from Howard Lowndes states that PGP-6.5.1i for Unix is vulnerable, which would explain the release of PGP-6.5.2 for Unix. If you are using PGP, upgrading to the latest version is a good idea. Alternately, for those that prefer their software free, the GNU Privacy Guard (GnuPG) provides a completely free alternative that is highly recommended. Note that the CERT advisory and several other sources detail how GnuPG can be used to detect the addition of an authorized ADK to a public certificate. Meanwhile, the whole issue has focused attention on the use of public key encryption. PGP and GnuPG together are possibly the most common/popular public key encryption system under Linux. PGP has always been somewhat arcane, resulting in only a minority of people using it. These new issues are not likely to encourage more people to try it out. Here are some additional resources for people who want to delve more deeply into this issue:
OpenBSD's Good Example (RootPrompt). Here's an article on RootPrompt.org about the lessons Linux could learn from OpenBSD. "Why do we in the Linux community produce distributions that require the user to be a security expert? Why don't we at least add a 'Secure by Default mode' to our distributions?" Quarterly CERT summary. Here is the latest quarterly CERT summary detailing the most active, ongoing security issues. Security Reportsmgetty temporary link vulnerability. Stan Bubrouski reported a vulnerability in mgetty this week, triggered by the use of a temporary file in a world-writable directory by faxrunqd, a daemon normally run as root which is used to send fax jobs spooled by faxpool. As a result, any file on the system can be overwritten. mgetty 1.2.21 and all prior version are reported to be affected. An upgrade to mgetty 1.2.22 should fix the problem. Check BugTraq ID 1612 for more details.This week's updates: glibc vulnerability in ld.so. Caldera Systems appears to be the originator for the report of a vulnerability in ld.so, part of glibc, in which environment variables are not properly removed in all cases before a setuid program is run. As a result, a local root compromise is possible (though no exploit has been reported as of yet. This week's updates:Linux-Mandrake security update to xpdf. MandrakeSoft has issued a security update to xpdf which fixes a symlink race condition. No other information on this problem has been spotted as of yet.Commercial products. The following commercial products were reported to contain vulnerabilities:
Updatesxlockmore. Check last week's Security Summary for details. An update to xlockmore 4.17.1 is recommended. This week's updates: Older updates:xchat URL handler bug. Versions of xchat from 1.3.9 through and including 1.4.2 can allow commands to be passed from IRC to a shell. Check BugTraq ID 1601 for more details. This week's updates:
dhcp. A second set of problems with the ISC dhcp client was reported in the July 20th Security Summary.This week's updates: Older updates:
ntop. Check last week's Security Summary for more details. This week's updates: Older updates:
Netscape 'Brown Orifice' vulnerability.Check the August 10th Security Summary for more details. This week's updates:
Jukka Lahtinen minicom. Check last week's Security Summary for details. No official updates have been seen as of yet. Unofficial reports indicate that Red Hat 6.1 and 6.2 and Slackware 7.0 are vulnerable and that SuSE, Linux-Mandrake, FreeBSD and now Debian are not vulnerable.usermode. Check the August 17th Security Summary for details on the most recent problem with usermode. This week's updates:
ResourcesComplete Reference Guide to Creating a Remote Log Server (LinuxSecurity.com). LinuxSecurity.com has put out a Reference Guide for the process of creating a remote log server. "A remote log server is nothing more then a system preconfigured at install-time to provide hard drive space for other systems to log to. This system must be completely secured and locked down. No unencrypted remote access should be allowed, all RPC Daemons and other misc. services should be turned off as well. The only data allowed to the machine should be UDP/Port 514." EventsSeptember security events.
Section Editor: Liz Coolbaugh |
August 31, 2000
| ||||||||||||||||||