Section 2.13 New Lamps for Old

   


2.13 New Lamps for Old

graphics/fivedangerlevel.gif

You really do want to swap your old lamps (versions of these programs) for new ones, lest a cracker come across your old lamp and rub it until a genie pops out and grants him three wishes:

  1. to own your system

  2. to get famous (if yours is a large site)

  3. to get a SysAdmin "called on the carpet"

Popular Linux distributions as late as summer 2002 had security bugs in some of these programs. Additionally, new vulnerabilities seem to be found in some of these programs year after year, so continued watching of the security lists discussed in Appendix A is of extreme importance. It is important to accept that new bugs will continue to be found in all software, including Linux. Although I find the bug rate in Linux far lower than other platforms, it is critical to get on the various bug tracking mailing lists (discussed elsewhere) and promptly update software. The particular issues discussed in this section might be old news by the time you read this.

All of the Linux distributions are taking security much more seriously now that businesses and individuals are starting to recognize the cost of breaches and are carrying the very real possibility of serious financial loss. For years, almost all of them have maintained a mailing list so that SysAdmins can be notified when security patches are available. Unless a more advanced update method is being used, I consider it mandatory to be on the mailing list. When a vulnerability in a program is discovered, it is a race between crackers and SysAdmins to get to vulnerable systems first.

Some crackers have built up databases containing lists of IP addresses and what versions of software are being used at those locations. Then, when vulnerability is discovered in a particular program, the cracker can consult their database to find systems that easily can be compromised. It is critical to install patches quickly for vulnerable software; therefore, Red Hat, Mandrake, and SuSE all have semiautomated or automated update facilities. While some prefer the automatic updates, I prefer to decide whether to install a patch. If I am not using a program, I might simply remove it from the disk rather than install a patch.

The preponderance of historical data has shown us that, if a program has one problem, probably it will have another. The average person uses less than 10 percent of the programs on their system, so why leave a buggy program around? By removing unused programs and therefore limiting the number of packages that need updating, your updates will be quicker. Unfortunately, all of the distributions still are using only FTP rather than SFTP for updates. Hopefully, this will change soon.

SuSE is moving to using patch packages rather than full packages for updates. This makes life easier for those on low-bandwidth connections.

Red Hat 7.3 has a slick GUI interface to its up2date updating program. It also has an icon on the tool menu at the bottom of the screen for up2date. When doing a workstation install, it asks if you want to have the system configured to check for updates automatically (which I strongly recommend). By default, it checks every two hours. This check simply determines if there are any new updates available; it does not download them. Perhaps it just exchanges a time-stamp.

Up2date will not automatically install new packages, but the icon will change from a green tickmark to a red exclamation point when new security patches are available. Click on the ! icon to pop up the up2date window. At this point, you will want to click on the up2date button, which causes it to download details on any new patches that are available. It loads a summary of the patches, not the patches themselves, so it is fast.

Red Hat has taken some care in the design to make the process as painless as possible so that people will bother to do the updates. This is in everyone's interest. Up2date lists the updates available by package name. Click on a package and it explains what the package does. There are too many packages for anyone to know what they all do. An application that is not set-UID and is not invoked by root or another privileged user usually is not much of a threat unless it interprets untrusted data from the Internet.

Click on the View Advisory button to find out what the problem is. You can select any combination of patches to be downloaded and installed or you can click on the Select all packages button. Clicking Next starts the download and installation process. At this point the process is automatic, so you can do other things while the packages download and install. Progress bars are displayed while it is running.

The software is not perfect, though. Several times while downloading, the software stalled. This required me to use ps to guess which process to kill (the Python process) in order to recover. The icon vanished, and I was asked if I wanted it relaunched. I clicked on Yes and was able to repeat the process successfully.

Mandrake and SuSE have similar updating facilities, though perhaps not as slick as that from Red Hat. Windows also offers an automatic update facility. Regardless of whether you opt for an automatic update, a semiautomatic update (which I prefer in order to have control over changes to my systems), or being on a mailing list and manually updating, it is critical to stay up-to-date. No software is bug free. I cannot stress enough how important it is to minimize a cracker's window of opportunity by quickly applying the security patch that closes a given vulnerability.

There are alternatives to up2date and the vendor-provided update tools. Autoupdate (http://freshmeat.net/projects/autoupdate/) and autorpm (http://freshmeat.net/projects/autorpm/) work for any distribution based on rpm, and can be configured the proverbial six ways from Sunday. They will check, compare versions, resolve dependencies, download, and install the updated RPMs for your system. It is relatively easy to use these tools when you have one computer as a repository for the remainder of the computers on your network. For heavy graphical users, the Ximian RedCarpet service will handle system updates as effectively as up2date.

What is the future of Linux security? Linux has the advantage of starting with a well-designed security model, and most of the code is well written. This includes the ability to offer limited privileges for ordinary users and separate subsystems so that one simply can remove or not use those not needed. This causes any vulnerabilities in those subsystems to be a nonissue. A code audit of all of the code that comprises Linux has been ongoing for several years; the problems discovered get fixed.

Some troublesome subsystems that used to run as root, such as the Domain Name Service (DNS) daemon (named), can and should be run completely isolated as separate ordinary users in chrooted environments. This way, if a buffer overflow or some other vulnerability is encountered, only that subsystem is compromised, not the whole system. Additionally, security features recently have been built in to Linux at the application layer. Apache has some features that limit what ordinary HTML can do. Sendmail has a restricted shell for running programs. This shell limits what the instructions contained in the aliases file or a user's .forward file are allowed to do. Sendmail will refuse to trust data in group-writable or world-writable directories to prevent a SysAdmin's configuration error from leading to a compromise, unless it is overridden explicitly.

A major longstanding criticism of Linux (and UNIX before it) is that many interesting things require root access to function and thus a single bug in a program running with root permissions can compromise the whole system. Starting in 2001, work to resolve this was started in the form of the kernel's evolving Capabilities facility. This allows one to permit only a subset of root's capabilities (or even those of an ordinary user) to various programs. A classic case is that of a server that wants to listen on a well-known port number, one below 1024. Only root is allowed to start listening on such a port because clients trust such a server with passwords and data.

Some programs, such as named and Apache, can be told to open their assigned port early on and then give up root permissions. This is done to prevent a bug later in the program from leading to a root compromise. An even better solution is to use Capabilities to grant them root's permission only to open the port. While you can use this facility now, expect to see it become standard on releases in the near future.

Instructions for achieving best secure practices for Apache can be found in the section "Apache Ownership and Permissions" on page 275. This section describes the process where you can set the "run as" user and group for Apache. For early versions of Red Hat, the user was set to nobody. In later versions, an "apache" user and group were created to better separate the Web-server user's access from other users and especially from root. It is critical to remember, though, if this system's primary function is to be a Web server, the gold is owned by the apache user and its security is as important as root's.

Instructions for keeping your DNS daemon (named) in check are in the section "DNS (named, a.k.a. BIND)" on page 201. You will find instructions there for setting up named to run as a regular, nonprivileged user, so if it is compromised, the damage will be compartmentalized.

2.13.1 Upgrade Your 2.4 Kernel

graphics/threedangerlevel.gif

The 2.4 kernel still is not mature. One major change from 2.2 is in the area of IP Tables, which includes complex code. I do not consider Tables to be mature, and occasionally bugs still are found in it. Other areas of change involve memory allocation, where a bug can risk buffer overflows.

For some uses, a stable 2.2 kernel may offer a more secure solution. For others, using IP Chains under the 2.4 kernel may offer the most secure solution. A general rule of security is not to trust recent changes; instead allow someone else to find out the hard way if they are secure. An exception is if a feature is necessary or if it replaces a more troublesome older component.

2.13.2 Upgrade Your 2.2 Kernel

graphics/threedangerlevel.gif

It was discovered in the summer of 2000 that version 2.2.15 of the kernel and some earlier 2.2.x versions have a severe bug. Some people are still using these kernel versions. This bug will allow a local cracker to block the setuid() system call that some privileged programs, such as sendmail, Apache, and procmail use to change their effective UID from root to that of an ordinary user to do unprivileged operations on the behalf of that user. The exploit is to invoke sendmail or a similar set-UID program with the CAP_SETUID privilege disabled. The bug is that the setuid() request is denied but no error is returned. (Even if an error were returned, a program running as root has a "right" to expect that this call succeed and so will not bother to see if an error was returned. Any behavior breaking this expectation breaks upward compatibility and must be considered a bug.)

Besides 2.2.15, it is known to exist on Linux 2.2.14-5.0 (Red Hat 6.2). Exploits exist. Apache and procmail may offer popular mechanisms for black hats to exploit this bug. It is suggested that an immediate upgrade to 2.2.16 or later be done. A workaround to protect against exploiting this bug through sendmail is available from

ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.10.2.tar.gz

This sendmail workaround is not protection against exploit via these other programs. To protect them, the kernel needs to be upgraded to 2.2.16 or later.

2.13.3 Upgrade sendmail

graphics/fivedangerlevel.gif

The sendmail program is very complex, with all but the latest versions offering many well-known security holes. Upgrading is essential to security. The latest ones also have anti-spam software. There are some alternatives to sendmail, such as smail, that claim to be easier to configure and possibly more secure. Since sendmail is used in so many places I would consider it a safer bet.

Many systems have been broken into in the past via sendmail exploits. Many of these exploits have involved buffer overflow, tricking sendmail into invoking a program of the cracker's bidding instead of the intended one, and in the distant past, offering an interloper a root shell on request. In its defense it was written around 1980 by Eric Allman at Berkeley when the Internet was vastly smaller and friendlier. It must move data between different users, communicate with a TCP port that only root normally is allowed to listen on, use root privileges for certain operations, parse an unimaginably varied and bizarre set of addressing methods, and usually must accept e-mail from any system in the world. It also must fork off a variety of programs and offer various debugging options.

Because sendmail is a favorite target of crackers and spammers, it is critical for you to always keep yours upgraded to a recent version. Besides enjoying fixes for past exploits, you will enjoy the benefits of the improvements that are continually being made to it. Commercial versions of sendmail are available from Sendmail, Inc. that are quite reasonably priced.

There are ways to configure sendmail so that it does not require running as root. If the limitations of this configuration are acceptable, this certainly reduces the severity of any remaining exploits that are discovered.

If your version of sendmail is older than 8.9.3, there are known buffer overflow exploits that you are vulnerable to. Note that major anti-spam features were added in sendmail version 8.9 and that it also contains anti-relaying features. Presently I consider 8.12.4 to be the minimum acceptable revision of sendmail.

Version 8.12.4 of sendmail is available and you are strongly encouraged to install it (or a later released version) on your system really soon now. It is available from the CD-ROM and Web site; it may be downloaded from

ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.4.tar.gz

Some of the recent features of 8.12 are SMTP authentication, LDAP support, and multiple queues for parallel processing for increased performance. The SMTP authentication includes an optional password to limit your server to accepting e-mail only from certain sending systems and more spammer blocking capability than previous versions. The new authentication level allows adding a security layer for digital signing and encryption.

To determine the version of sendmail that one of your systems is running, say, mail.pentacorp.com, telnet to its port 25 and normally its sendmail will tell you.

 
 telnet mail.pentacorp.com 25 220 mail.pentacorp.com ESMTP Sendmail 8.12.4/8.12.4; 6 Sep 2002 quit 221 mail.pentacorp.com closing connection Connection closed by foreign host. 

The mail.pentacorp.com sendmail is version 8.12.4 and its sendmail.cf file states that it is for version 8.12.4 or newer.


An interesting new feature is being able to limit how many recipients an e-mail is allowed to have. This blocks a popular spammer trick of guessing common names (such as popular first names and common last names) and listing hundreds of these in an e-mail message. Also, it does more sophisticated analysis of mail headers to weed out spammers. It supports virtual hosting. Note that some of these anti-spam features either have been offered in previous versions in a more limited form or via various patches.

Its new AUTH command (part of the new SMTP authentication) allows your traveling people generating e-mail from otherwise untrusted remote sites (e.g., coldmail or yoohoo) to authenticate themselves and enjoy full services from your sendmail server while it still can block spam or even all other e-mail from said server.

The 8.12 version offers a "content management API" that allows you to have all e-mail messages pass through a separate process of your choice. It can be used to filter out messages with objectionable content, such as spam messages and viruses. It also might be used to archive certain types of messages. The U.S. Securities and Exchange Commission requires companies under its jurisdiction to do this. It might be used to implement public key encryption or signing.

The best place to get sendmail is from where you get your Linux distribution, if they offer an up-to-date version, perhaps on their Web site. This is because they may have tweaked pathnames for their particular configuration, such as whether the sendmail.cf file resides in /etc, /usr/lib, etc. Otherwise, have a look at sendmail.com, sendmail.org, or sendmail.net.

sendmail security is just touched on here, addressing the most urgent needs. Many other important sendmail issues are covered in "Sendmail" on page 174.


2.13.4 Fortify sendmail to Resist DoS Attacks

graphics/twodangerlevel.gif

There are many DoS attacks that simply flood a system with packets, called packet storms. There are others that are intended to run a system out of resources besides bandwidth, such as disk space or kernel table space. A popular way to do this is to send you massive amounts of junk e-mail to fill up your disk and waste your CPU time, process table slots, and so on. Regardless of whether the goal is to cripple your system or bother your users with phony get-rich-quick schemes, there are ways to resist.

If mail is sent very rapidly, in the process of forking off a child to handle each piece of e-mail, sendmail may run the system out of processes. This is because sendmail does not wait for one child to finish processing a piece of e-mail before starting the next, and the next, etc. Sendmail, Inc.[25] recommends the variable values shown in Table 2.4 as a starting point in tuning your sendmail to be more resistant to DoS and spammer attacks. Most or all of these recommendations will be applicable to later versions of sendmail too. These values should be set in /etc/sendmail.mc. If a "M4 variable" listed, say confMIN_FREE_BLOCKS, is not already in the /etc/sendmail.mc file, it should be defined similarly to

[25] Used with permission of Sendmail.net. Copyright 2000 Sendmail, Inc. Sendmail, Inc. was founded by Eric Allman, who wrote Sendmail, to provide commercial support for Sendmail. Their URL is:

www.sendmail.com

 
 define(`confMIN_FREE_BLOCKS', `100') 

Then issue the following shell command to convert the /etc/sendmail.mc file into the /etc/sendmail.cf file.

 
 m4 /etc/sendmail.mc > /etc/sendmail.cf 

Sendmail may be restarted so that it uses the new values. On Red Hat and its progeny, this is done with the following command. On other systems, such as Slackware, a system reboot is an easy way to restart sendmail; sending it a HUP signal and issuing the same sendmail invocation that is used in /etc/rc.d/rc.M (found with grep) is an alternative.

 
 /etc/rc.d/init.d/sendmail restart 

Many more sendmail configuration improvements are addressed in "Sendmail" on page 174.

Table 2.4. Sendmail DoS Fortification

Format:

M4 variable (configuration file variable) [Default]

Recommended: value

Textual description

confMIN_FREE_BLOCKS (MinFreeBlocks) [100]

Recommended: 4000 or larger

Minimum number of free blocks on queue file system to accept SMTP mail. (Prior to 8.7, this was minfree/maxsize, where minfree was the number of free blocks and maxsize was the maximum message size. In current versions of Sendmail, use confMAX_MESSAGE_SIZE for the second value.)

confMAX_MESSAGE_SIZE (MaxMessageSize) [infinite]

Recommended: 4000000 (?)

The maximum size of messages that will be accepted (in bytes).

confAUTO_REBUILD (AutoRebuildAliases) [False]

Recommended: False

Automatically rebuild alias file if needed. There is a potential for a denial of service attack if this is set.

confQUEUE_LA (QueueLA) [varies]

Recommended: 10 (depending on CPU power)

Load average at which queue-only function kicks in. Default value is (8 * numproc), where numproc is the number of processors (if that can be determined).

confREFUSE_LA (RefuseLA) [varies]

Recommended: 8 (depending on CPU power)

Load average at which incoming SMTP connections are refused. Default value is (12 * numproc), where numproc is the number of processors online (if that can be determined).

confMAX_DAEMON_CHILDREN (MaxDaemonChildren) [undefined]

Recommended: 40 (for 128 MB of RAM)

The maximum number of children the daemon will permit. After this number, connections will be rejected. If not set or <= 0, there is no limit. Set it to some number, depending on the amount of RAM. This value is suggested so as not to have so many active processes that thrashing sets in.

This is a DoS in itself. If you limit this to 40, an attacker need only open 40 connections and your system will refuse other connections. In a sense, it is a "no win" situation.

confMAX_HEADERS_LENGTH (MaxHeadersLength) [undefined]

Recommended: 32K or 64K

Maximum length of the sum of all headers.

confMAX_MIME_HEADER_LENGTH (MaxMimeHeaderLength) [undefined]

Recommended: 1024 or less

Maximum length of certain MIME header field values.

confMAX_RCPTS_PER_MESSAGE (MaxRecipientsPerMessage) [infinite]

Recommended: 10 100 (depending on your site policy)

If set, allows no more than the specified number of recipients in an SMTP envelope. Further recipients receive a 452 error code (i.e., they are deferred to the next delivery attempt).


A nontrivial solution to this "sendmail connection flood" problem is to enhance sendmail to limit the maximum number of open connections from any one system (or network) to a smaller number of connections. Any additional connections from the aberrant source will be closed immediately.

This might involve a table associating child PIDs of outstanding connections with the IP addresses of the systems that they are connected to, enabling easy processing when new connections are created. A likely location would be in daemon.c right after the accept(). Simply sequence through the table, counting the other connections from the same IP.

If the count exceeds the threshold (defaulting to one third of the total limit and settable on the command line) the SO_LINGER[a] is set to zero and the socket is closed. This change should take an experienced C programmer four to eight hours to do. An alternative to modifying sendmail would be the use of a stateful firewall that has this capability of limiting the number of connections from a system. There also should be a shorter time limit (timeout) for the duration of a connection and its various phases; a default timeout of one hour is typical but excessive. The lines starting O Timeout (possibly commented out) in the

 
 /usr/lib/sendmail-cf/m4/proto.m4 

file should be examined and altered as necessary, especially most of the timeouts set to be 1h. Although an hour might have made sense long ago, a 100 KB message can be sent in 36 seconds over a 28.8 Kbaud line. A value of 5m should be sufficient for many installations. If messages take longer than that, it could be an indication of a flaky network and it would be better to drop the connection so that the sender can try again later when the network congestion clears.


[a] If SO_LINGER is nonzero, the kernel will keep the connection open for a minute in case someone might want to connect. This avoids the overhead of possibly spawning a process. It is not needed here.

An enhancement to sendmail would be to reject the entire e-mail that has too many recipients rather than defer delivery to the additional recipients.


2.13.5 Upgrade SSH

graphics/fivedangerlevel.gif

There have been a number of security bugs in open SSH and a lesser number in the www.ssh.com version. Because this program has such a position of trust (root password access), it is critical to watch for patches. Still, it is far better than any other remote access method. Never use ssh1, though; it has design flaws.

The solution is to upgrade. It may be obtained from:

www.ssh.com

www.openssh.com

2.13.6 Upgrade WU-FTPD

graphics/fivedangerlevel.gif

Many distributions of Linux use the WU-FTPD program, the very widely used implementation of ftpd by Washington University. In almost every year there were security bugs discovered and quite a few sites were broken into. The WU-FTPD developers strongly encourage SysAdmins to keep their version up-to-date.

It is preferable to get updates from your Linux distributor, but if that is not possible then it may be downloaded from the following site or a mirror near you.

ftp://ftp.wu-ftpd.org/pub/wu-ftpd/

Note that WU-FTPD's original home, wuarchive.wustl.edu, no longer supports or maintains it and should not be used. The FAQ and a list of mirror sites may be obtained from:

ftp://ftp.wu-ftpd.org/pub/wu-ftpd/wu-ftpd-faq.txt

For more involved solutions to FTP security problems, consult "FTP" on page 190.

2.13.7 Upgrade Netscape

graphics/fourdangerlevel.gif

Versions of the Netscape client for Linux prior to 4.73 have a variety of security bugs and should not be used. It is recommended that all who use Netscape upgrade to the latest nonbeta version.

Versions of the Netscape browser up to and including 4.72 have a bug in the SSL (Secure Socket Layer) implementation that allows an intruder to trick Netscape into accepting a fake certificate. The intruder then can obtain the Netscape user's confidential data, such her electronic banking password or credit card number and proceed to impersonate her and withdraw her funds or make purchases with her credit card. In practice, it would be nontrivial for an attacker to exploit this bug so it is unlikely to affect many people. A determined knowledgeable cracker might be able to exploit it. The solution is to upgrade to version 4.73 of Netscape or later. The problem was reported on Bugtraq on May 10, 2000 and explained in detail. It involves poisoning a DNS server and proceeding from there.

There was an unconfirmed report that Netscape version 4.72 and earlier create temporary files in /tmp mode 666 with open() and fails to use the O_EXCL flag either. This is done while importing certificates for SSL operations. While it then does a fchmod() to change its mode to 0600, there is a small window which allows any user to dump data into this file to corrupt it. The O_EXCL flag requires the file to not already exist. By failing to use the O_NOFOLLOW, Netscape is vulnerable to symlink attacks. This is where any user guesses what file name will be used and places a symbolic link there pointing to anywhere in the file system.

If the user invoking Netscape has write permission, an existing file at wherever the symbolic link points will be truncated. If there was not a file before, one will be created. If root invokes Netscape, the interloper can truncate or create a file anywhere in the file system. As knowledge of this bug was brand new when this chapter was written a fixed version number cannot be quoted; check the Web.

Additionally, "Configuring Netscape for Higher Security" on page 261 covers other ways to increase security of this very heavily used and complex program. The latest information on Netscape security is available from

http://home.netscape.com/security/notes/index.html

New versions of Netscape may be downloaded from:

http://home.netscape.com/download/

Larry Gee reports that having installed the Java plugin from:

www.blackdown.org/

much better operation was achieved than with the standard Java that comes with Netscape.

2.13.8 Blocking Web Ads

graphics/threedangerlevel.gif

Although a Web site providing useful information cannot be faulted for trying to recover costs through advertising, there seems to have been an explosion of advertising since early 1999. Much of this is through DoubleClick, which does not seem to have the bandwidth to "get this pain over with quickly." Additionally, there have been believable allegations of DoubleClick abusing the information that it receives; these allegations are serious enough that currently it is under investigation by the New York State Attorney General's office.

Although a site has a right to advertise, you have a right to block it. The following IP Chain commands will block the requests. (It is important to block the requests originating from your browser rather than the replies because the latter will simply cause your browser to wait for a reply that never comes.)

 
 ipchains -A output -i eth0 -d 199.95.207.0/24  -j REJECT ipchains -A output -i eth0 -d 199.95.208.0/24  -j REJECT ipchains -A output -i eth0 -d 204.253.104.0/24 -j REJECT ipchains -A output -i eth0 -d 208.184.29.0/24  -j REJECT ipchains -A output -i eth0 -d 208.211.255.0/24 -j REJECT ipchains -A output -i eth0 -d 209.67.38.0/24   -j REJECT 

These are based on information from:

 
 comp.os.linux.security FAQ: www.geocities.com/swan_daniel/colsfaq.html 

Because these addresses are not set for all of eternity, you will want to look at the source of frequently visited pages for links to advertisers and watch the URLs that flash at the bottom of the Netscape window. Then you can add ipchains invocations with the IP addresses of these host names to chase away these demons. You can determine the IP address of any host by invoking ping. You do not need to wait for a packet to return, just for the address to be shown.

An excellent solution for many Web problems is the use of Squid, Squidguard, and Junkbuster, discussed in "Stateful Firewalls" on page 540.


   
Top


Real World Linux Security Prentice Hall Ptr Open Source Technology Series
Real World Linux Security Prentice Hall Ptr Open Source Technology Series
ISBN: N/A
EAN: N/A
Year: 2002
Pages: 260

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net