-----BEGIN PGP SIGNED MESSAGE----- File Locking Local Denial of Service Impact on sendmail Reported by lumpy <dynamoat_private> 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-----
This archive was generated by hypermail 2b30 : Fri May 24 2002 - 11:24:22 PDT