Security
Brief items
Keeping Secrets
[This article was contributed by Tom Owen]
Information contained on hard drives is often of the type that should not fall into the wrong hands. After all, being on the wrong end of a Canadian class action lawsuit for releasing personal information counts as one of the rougher server administrator nightmares. It's not clear whether the Canadian disk drive was stolen or retired, but it doesn't look like an isolated case. Responsible equipment dealers and recyclers use special tools to sanitize disks that come into their hands. But it doesn't always happen, and there's always the risk of simple theft.Being sued is one possible outcome. In Europe, criminal charges are possible, though unlikely. Even if all you have to worry about is an embarrassingly public gap between your privacy policy and your real operations, it may be time to look more closely at what might emerge if your data partitions ended up on eBay.
The problem is that the ordinary techniques of host security are useless against an explorer who can install your disks in a lab machine. 0600 modes won't be noticed by an attacker who is root already. Wipes and sanitizers won't have been used if the equipment was stolen. The only option is to encrypt the information you don't want to leak. If you do it right you can publish the contents of your disks without a qualm. Encryption is doubly important for Linux administrators because the range of software is so great that failure to encrypt is that much less excusable. The only plausible objections relate to performance and convenience issues.
In the past, the US imposed export restrictions on cryptographic software. Those rules obliged Linux kernels from kernel.org to exclude cryptographic software. Something like that never stops hackers, and the kernel code for encrypted disks and networks was hosted and has continued outside the US. The 2.5 kernel has crypto built in, but users of the current stable kernels must get their encryption code from another source. Incorporating crypto code into a standard kernel is well documented but it's simpler to use a distribution like SuSE which includes crypto out of the box.
Beyond the offerings from your distribution the broad choice is rather daunting. The standard approach uses encryption in the loopback device to create a secure partition "hosted" in a big contiguous file. A filesystem can be created on that device and mounted as the data directory. The host file is unintelligible without the passphrase.
Encrypted loopback can't handle swapfiles, and so there's a risk of leaving decrypted application information on the disk. If you can't configure enough memory, ppdd, which layers encryption on top of the plain loopback device does support swap files.
Other approaches like CFS don't use loopback, instead running a userspace daemon to encrypt on a file by file basis. These suffer under I/O load and wouldn't be a good choice to host a database.
All of this is relatively well documented. But the manuals seem to skate around the hard problems:
-
Passwords are hard to manage.
Changing the password involves backup and restore,
too much trouble to do often, so it has to be closely guarded.
Even worse, the passphrase can't be held anywhere on the machine,
so an unattended start isn't possible.
- It's surprisingly tricky to backup encrypted data. The loopback host file can be sensitive to absolute location on the disk, and getting data securely off the machine requires more encryption.
It's unfortunate that the commonest server setup, remote hosting, is one of the toughest operational security challenges. But if remote servers are the only possible answer, then encryption security is still possible. Linux is solid enough that unattended restart isn't strictly necessary. Instead, the machine can boot far enough to page the admin to ssh in and mount the loopback devices. And a backup can be prepared on the encrypted volume and once it's re-encrypted with the admin's public key any transfer method will do.
This is all convoluted to say the least. It's not standard, and it goes beyond what's commonly done. It's easy to feel that keeping the site going and current is challenge enough. But if you take privacy seriously there are no other choices. Once your hosts are as secure as you can make them against attacks from the network, it's time to move up a level. If you have other people's personal data, you should probably encrypt it.
New vulnerabilities
hypermail - buffer overflows
| Package(s): | hypermail | CVE #(s): | CAN-2003-0057 | ||||||||
| Created: | February 11, 2003 | Updated: | February 27, 2003 | ||||||||
| Description: | Ulf Harnhammar discovered two problems in hypermail, a program to
create HTML archives of mailing lists.
An attacker could craft a long filename for an attachment that would overflow two buffers when a certain option for interactive use was given, opening the possibility to inject arbitrary code. This code would then be executed under the user id hypermail runs as, mostly as a local user. Automatic and silent use of hypermail does not seem to be affected. The CGI program mail, which is not installed by the Debian package, does a reverse look-up of the user's IP number and copies the resulting hostname into a fixed-size buffer. A specially crafted DNS reply could overflow this buffer, opening the program to an exploit. | ||||||||||
| Alerts: |
| ||||||||||
kernel-utils: setuid vulnerability
| Package(s): | kernel-utils | CVE #(s): | CAN-2003-0019 | ||||
| Created: | February 7, 2003 | Updated: | January 21, 2005 | ||||
| Description: | The kernel-utils package contains several utilities that can be used to
control the kernel or machine hardware. In Red Hat Linux 8.0 this package
contains user mode linux (UML) utilities.
The uml_net utility in kernel-utils packages with Red Hat Linux 8.0 was incorrectly shipped setuid root. This could allow local users to control certain network interfaces, add and remove arp entries and routes, and put interfaces in and out of promiscuous mode. All users of the kernel-utils package should update to these packages that contain a version of uml_net that is not setuid root. Alternatively, as a work-around to this vulnerability issue the following command as root: chmod -s /usr/bin/uml_net | ||||||
| Alerts: |
| ||||||
PostgreSQL - more buffer overflows
| Package(s): | postgresql | CVE #(s): | |||||||||||||||||
| Created: | February 12, 2003 | Updated: | November 7, 2003 | ||||||||||||||||
| Description: | A new set of buffer overflows has been discovered in PostgreSQL 7.2.2; they affect the circle_poly(), path_encode(), and path_addr() functions. Exploiting these overflows requires that the attacker first obtain a connection to the PostgreSQL server. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
w3m - cross-site scripting vulnerabilities
| Package(s): | w3m | CVE #(s): | CAN-2002-1335 CAN-2002-1348 | ||||||||||||||||||||||||
| Created: | February 7, 2003 | Updated: | February 18, 2003 | ||||||||||||||||||||||||
| Description: | w3m is a pager with Web browsing capabilities. Two cross-site scripting
(XSS) issues have been found in w3m.
An XSS vulnerability in w3m 0.3.2 allows remote attackers to insert arbitrary HTML and web script into frames. Frames are disabled by default in the version of w3m shipped with Red Hat Linux. Therefore, this problem will not appear as long as users do not use w3m with the -F option, or enable frame support in either the /etc/w3m/w3mconfig or ~/.w3m/config configuration files. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-1335 to this issue. An XSS vulnerability in versions of w3m before 0.3.2.2 allows attackers to insert arbitrary HTML and web script into image attributes. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-1348 to this issue | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
Resources
LinuxSecurity.com newsletters
This week's Linux Advisory Watch and Linux Security Week newsletters from LinuxSecurity.com are available.
Page editor: Jonathan Corbet
Next page:
Kernel development>>