-----BEGIN PGP SIGNED MESSAGE----- 

                   File Locking Local Denial of Service 
                            Impact on sendmail 
                    Reported by lumpy <dynamo@ime.net> 
                                      
Introduction 
============ 
Any application which uses either flock() or fcntl() style locking or 
other APIs that use one of these locking methods (such as open() with 
O_EXLOCK and O_SHLOCK) on files readable by other local untrusted users 
may be susceptible to local denial of service attacks. 

Since this attack requires a user to use their own account to lock 
a file, it is extremely easy to find the user responsible. In all 
likelihood, users would not be foolish enough to use this type of denial 
of service. 

The Problem 
=========== 
Both locking types allow users who can open a file to apply a shared 
(read) lock on that file. This prevents any other process from 
obtaining an exclusive (write) lock on that file. 

Additionally, the flock() method allows users to obtain exclusive locks 
on files which they can open for reading. fcntl() locks require the file 
to opened for writing which offers somewhat better protection. While a 
process holds an exclusive lock on a file, no other process can obtain 
an exclusive or shared lock on that file. 

Although both flock() and fcntl() locks are advisory, their use to avoid 
data corruption makes them essentially compulsory for many programs. 

Detection 
========= 
The process holding locks can be found using tools which read process 
file descriptor tables. One such tool is lsof, available from: 

        ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/ 

With this tool, you can find the process or processes holding a shared 
or exclusive lock on a file: 

        # lsof /etc/settings 
        COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME 
        lockit 25472 badguy 3rW VREG 116,131072 1841 292 /etc/settings 

In this example, user badguy's lockit process (pid 25472) has 
/etc/settings opened for 'r'eading and has obtained an exclusive 
('W'rite) lock as shown by the FD column. If this were an attack, the 
administrator could kill the offending process to drop the lock. 

Workaround 
========== 
Since both locking methods are susceptible to a denial of service 
attack, simply switching to fcntl() based locking on all systems would 
not solve the problem. However, as long as a user can not open a file, 
they can not lock it. Therefore, the workaround is to protect all files 
which are locked by applications such that they can not be opened by 
untrusted users. 

Sendmail File Locking 
===================== 
File locking is used throughout sendmail for a variety of files 
including aliases, maps, statistics, and the pid file. Any user who 
can open one of these files can prevent sendmail or it's associated 
utilities, e.g., makemap or newaliases, from operating properly. This 
can also affect sendmail's ability to update status files such as 
statistics files. For system which use flock() for file locking, a 
user's ability to obtain an exclusive lock prevents other sendmail 
processes from reading certain files such as alias or map databases. 

You can determine which locking system is used by sendmail from the 
output of: 

        sendmail -bt -d0.10 < /dev/null | grep HASFLOCK 

If HASFLOCK is in the output, your system is using flock() for locking. 
Otherwise, it is using fcntl() for locking. On the following operating 
systems, sendmail uses flock() by default: 

        SunOS 4, Ultrix, Tru64 UNIX 4.X and earlier, NeXTstep, Darwin, 
        Mac OS X, Mach386, Convex OS, RISC/OS, Linux 1.3.95 and later, 
        Sony NEWS, and all BSD-based systems 

On all other operating systems, sendmail uses fcntl() for locking by 
default. 

Since queue files should already have restricted permissions, the only 
files that need adjustment are alias, map, statistics, and pid files. 
These files should be owned by root or the trusted user specified in the 
TrustedUser option. Changing the permissions to be only readable and 
writable by that user is sufficient to avoid the denial of service. For 
example, depending on the paths you use, these commands would be used: 

        chmod 0640 /etc/mail/aliases /etc/mail/aliases.{db,pag,dir} 
        chmod 0640 /etc/mail/*.{db,pag,dir} 
        chmod 0640 /etc/mail/statistics /var/log/sendmail.st 
        chmod 0600 /var/run/sendmail.pid /etc/mail/sendmail.pid 

If /var/run/ is cleared on reboots, you will need to place the last 
chmod command for the pid file in the sendmail startup script after 
sendmail is started. 

If the permissions 0640 are used, be sure that only trusted users belong 
to the group assigned to those files. Otherwise, files should not even 
be group readable. 

Note that the denial of service on the plain text aliases file 
(/etc/mail/aliases) only prevents newaliases from rebuilding the 
aliases file. The same is true for the database files on systems which 
use fcntl() style locking. Since it does not interfere with normal 
operations, sites may chose to leave these files readable. Also, it is 
not necessary to protect the text files associated with map databases as 
makemap does not lock those files. 

sendmail 8.12.4 will change the default permissions for newly created 
map and alias database files to mode 0640. Also, the installation 
process will create the statistics file with mode 0600 if it does not 
already exist. Finally, the pid file will be created with mode 0600 as 
well. A future version of sendmail will introduce a feature to limit 
the amount of time spent waiting for a file lock. 

-----BEGIN PGP SIGNATURE----- 
Version: GnuPG v1.0.7 (FreeBSD) 

iQCVAwUBPO162cApykAW9MzpAQG4gQP+PUDUr4h+J62M1SylpaN31QabVN8eo51g 
Q8JwR57vu4udqiCDuKUulzO4V6ZvZak79XeKqZBR55J6cVfD1nMz5UXKfHKaa3Yt 
NucCYywQvyRFGQUF5aKZKMBRBxpn8xgm7r8bhUX6T0oxdMk7iAic/V5cv5CjY0ER 
AbAl3Rru/YE= 
=Unr9 
-----END PGP SIGNATURE-----