Through exploiting a combination of seemingly low-risk vulnerabilities in sendmail, it is possible for a malicious local user to have an arbitrary program inherit (or "hijack") the file descriptor for the socket listening on (priviliged) port 25. The problem begins with the way sendmail handles the failure of an accept() call. The accept() call is made when a tcp syn packet is recieved by a listening tcp socket. When the three-way handshake does not complete (as is the consequence of a half-open tcp "stealth scan"), accept() fails and sendmail closes all listening sockets and sleeps for 5 seconds. The second problem is that a user can start the sendmail daemon if a more obscure argument is passed (-bD). The -bD flag tells sendmail to run as a daemon, but in foreground. User priviliges are not checked against for this option, allowing any user to start sendmail. The third problem is how sendmail reacts to a HUP signal. When a HUP is recieved, sendmail calls execve(argv[0],..) to...
Through exploiting a combination of seemingly low-risk vulnerabilities in sendmail, it is possible for a malicious local user to have an arbitrary program inherit (or "hijack") the file descriptor for the socket listening on (priviliged) port 25. The problem begins with the way sendmail handles the failure of an accept() call. The accept() call is made when a tcp syn packet is recieved by a listening tcp socket. When the three-way handshake does not complete (as is the consequence of a half-open tcp "stealth scan"), accept() fails and sendmail closes all listening sockets and sleeps for 5 seconds. The second problem is that a user can start the sendmail daemon if a more obscure argument is passed (-bD). The -bD flag tells sendmail to run as a daemon, but in foreground. User priviliges are not checked against for this option, allowing any user to start sendmail. The third problem is how sendmail reacts to a HUP signal. When a HUP is recieved, sendmail calls execve(argv[0],..) to restart itself. The problem here is obvious, since argv[0] can be changed to anything. The bigger problem here though, is that the fourth file descriptor is not closed before this is done (which happens to be the one for the listening tcp socket), thus any argv[0] which is executed via the execve() call will inherit the descriptor. The steps required to exploit this are as follows: - From another machine, use nmap to do a "half open scan" on port 25 of the target host. (this will make sendmail go to sleep for five seconds, unattached to port 25) - In the 5 seconds that sendmail spends sleeping, call sendmail -bD as a user locally on the target box with noexec and set argv[0] to the program of your choice. (noexec is a program which allows you to set argv[0] to whatever you'd like). - Send the process a HUP, which is ok since you own the process. (The program you specified in the noexec command which is to be argv[0] now has the file descriptor for the socket listening on port 25). The consequences of this are full compromise of the mail server. An attacker could write a trojan "mail server" that would respond on port 25 to legitimate smtp connections.
