My thoughts on IMAP-UW changed drastically this week due to a new thread on bugtraq. It all started with yesterday's post about a vulnerability in the LIST command in the UW server.
To: BUGTRAQ@SECURITYFOCUS.COM*sigh* is right. A sploit to get local access of any level is bad, esp with the number of "local root exploits" running around that admins tend not to fix. Maybe the code isn't as solid as I thought.
Subject: imapd4r1 v12.264
From: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
OK nimue IMAP4rev1 v12.264 server ready
1 login lcamtuf test
1 OK LOGIN completed
1 list "" AAAAAAAAAAAAAAAAAAAAAAAAAAA...[yes, a lot of 'A's ;]
Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
Privledges seems to be dropped, but, anyway, it's nice way to get shell access to mail account, maybe grab some data from memory etc.
Of course, the vulnerability gets a response from Mark Crispin, the author of UW's IMAP. This is where I lose all faith in the system. I'll just quote the good stuff and comment where needed.
As was indicated, all privileges are dropped at that point. There is nothing that can be done by crashing imapd this way that can not also be done (much easier) by logging in to the UNIX shell.The moral of the story? If this is the attitude around the UW development team, keep their software away from me. Security is more than just keeping out root level exploits... it's a process. From the high layer design to each strncpy, it needs to be thought of at every level. Relying on admins to build a secure enough system to not be compromised when your software crashes isn't the answer. Assume the admins are monkeys and not trained in the arts of security. Create monkey proof software.
This of course assumes that the user has a shell account on the server he's getting his mail from. I'd say that 90% of the time, this is not the case, judging from the work I've done at ISP's and talking with other geeks
All imapd security efforts have been focused on eliminating root-level security holes. ... There has not been an equivalent effort to eliminate all possible ways to induce imapd or the c-client library to crash when it is in a non-root state. I am not certain that the results would be worth the effort, particularly since there are alternatives, either one of which is sufficient to neutralize the problem:
If you have a "closed" system (which is the only type of system where this bug matters), a much better solution is to insert the following instruction in routine pw_login() in env_unix.c:
if (chroot (home ? home : ANONYMOUSHOME)) chroot ("/tmp");
Not every machine supports "jailed" processes. And of those that do, sometimes having local privs is enough to break out of the jail. chroot solves some problems in normal execution, but if a program can be exploited, a chroot'd jail may not be enough to stop the bad things from happening
Another important measure is to use StackGuard. I am very surprised at the implication that RedHat doesn't use StackGuard. Is that really true?
As many on bugtraq pointed out, the whole planet isn't run on Linux, so StackGaurd isn't always an option. Plus, it's best to fix the hole and not rely on the OS to catch your mistake
The really unfortunate part of all this is the IMAP-UW server is synonymous with "IMAP" in general. If they continue to develop insecure software, the industry will be reluctant to adopt the IMAP protocol based on the "market leader's" performance. Until UW gets it's act together and starts seriously integrating security into their code, IMAP doesn't have a chance.