Postfix Linux-only local denial of service

2008-09-02 / 2008-09-03
Credit: Wietse Venema
Risk: Low
Local: Yes
Remote: No
CWE: CWE-20

An on-line version of this announcement is available at http://www.postfix.org/announcements/20080902.html Summary: ======== Postfix 2.4 and later, on Linux kernel 2.6, is vulnerable to a denial of service attack by a local user. There is no breach of data confidentiality or data integrity. This problem was found by the Postfix author during routine source code maintenance. Discussion: =========== Postfix is an open-source mail transfer agent (MTA) that runs on multiple types of UNIX systems. Postfix 2.4 (released 2007) introduces input/output event handling based on high-performance primitives: BSD kqueue (also present in MacOS X), Linux epoll, and Solaris /dev/poll. These implement more scalable event handling than the older select() and poll() primitives. With 2.6 Linux kernels, Postfix 2.4 and later has an epoll file descriptor leak when it executes non-Postfix commands in, for example, a user's $HOME/.forward file. A local user can access a leaked epoll file descriptor to implement a denial of service attack on Postfix. The attack may result in reduced Postfix performance, or in automatic Postfix shutdown when an internal safety mechanism triggers. Some possible attacks are discussed in the last paragraph of this section. Not affected is Postfix input/output event handling based on BSD kqueue and Solaris /dev/poll. There, the kernel effectively revokes access to the underlying kernel object when it creates a child process with fork(), keeping the kernel object normally accessible only by the process that creates it. The above approaches could help to improve the consistency of Linux input/output event notification. Currently, 1) different Linux processes may make conflicting updates to a shared epoll instance; 2) therefore, the Linux kernel may report input/output events to processes that didn't ask for those events; and 3) those events may involve activity on pipes, sockets, etc. that aren't open in those processes. Such inconsistency could be avoided when an epoll instance were normally accessible only by the process that creates it. Workaround: =========== Allow only trusted users to control delivery to non-Postfix commands. In the following example, the directory /var/forward is not writable by users, and Postfix is configured to search for /var/forward/username (plus optional address extension) instead of the default location ~username/.forward (plus optional address extension). /etc/postfix/main.cf: forward_path = /var/forward/${user}${recipient_delimiter}${extension}, /var/forward/${user} Other workarounds would be required for other mail filtering software that executes commands in user-controlled configuration files. Solution: ========= Apply the source code patch below, or install an updated Postfix version. Postfix versions 2.4.9, 2.5.5, and 2.6-20080902 are made available via http://www.postfix.org/. Vendors will make updated versions available according to their own support policies. Patch: ====== Begin of patch *** src/util/events.c.orig Mon Mar 24 13:19:23 2008 --- src/util/events.c Tue Aug 26 17:43:41 2008 *************** *** 426,431 **** --- 427,433 ---- #define EVENT_REG_INIT_HANDLE(er, n) do { \ er = event_epollfd = epoll_create(n); \ + if (event_epollfd >= 0) close_on_exec(event_epollfd, CLOSE_ON_EXEC); \ } while (0) #define EVENT_REG_INIT_TEXT "epoll_create" End of patch

References:

http://www.postfix.org/announcements/20080902.html
http://www.securityfocus.com/bid/30977
http://www.securityfocus.com/archive/1/archive/1/495894/100/0/threaded
http://secunia.com/advisories/31716


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top