Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

The Reason IMAP Has Not Caught On

By bgp4 in Culture
Tue Apr 18, 2000 at 08:01:40 AM EST
Tags: Security (all tags)

Ask your local admin what they think of IMAP. I'll bet dollars to doughnut's his answer will be "It's really nice to use, and is very flexible, but it's a security hole the size of the Lincoln Tunnel." In the past, I'd say that was very true. For most admins, IMAP == University of Washington's IMAPD server. It is the most fully functional, well known, open source IMAP server out there. And it's historically been chock full of holes. Looking through SecurityFocus' sploits archive digs up at least 4 vulnerabilities in the last 3 years for IMAP-UW. However, in the last year things seemed on the up and up. No new problems, and lots of new features. One would have thought they had the code under control.

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.

    Subject: imapd4r1 v12.264
    From: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
    Newest RH:

    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.
*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.

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.

    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 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.

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.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o SecurityFo cus'
o bugtraq
o post
o response
o Also by bgp4

Display: Sort:
The Reason IMAP Has Not Caught On | 24 comments (24 topical, editorial, 0 hidden)
Good stuff, although I'm not a syso... (1.00 / 2) (#2)
by FlinkDelDinky on Tue Apr 18, 2000 at 04:13:02 AM EST

FlinkDelDinky voted 1 on this story.

Good stuff, although I'm not a sysop and have no idea what imap is, why it's important, and whatever else.

Lots of good info for those who do know though.

Very well spoken. ... (none / 0) (#1)
by ramses0 on Tue Apr 18, 2000 at 04:37:05 AM EST

ramses0 voted 1 on this story.

Very well spoken.

Doing (personal) internet development work, I'd like to be very interested in security, but so far have concentrated more on getting my damned programs working than getting them to be secure.

I know I've posted a few security related items here, but how soon should I start worrying about security in my application?

I plan on auditing all my code once my progress has stabilized, and I think it's feature complete. Is this a bad time to do it or should I start now?

My plan is to change most variable names to "$user_blah_variable_name", and run all of those through "$safe_blah = make_safe( $user_blah );" before using, displaying, etc... Does anyone have any good advice? (especially a good "remove nasty characters regular expression" thing :^)=

[ rate all comments , for great justice | sell.com ]

Re: Very well spoken.... (none / 0) (#6)
by inspire on Tue Apr 18, 2000 at 08:43:58 AM EST

Security, of course, should be considered in the fundamental design of any application.

Usually running variables through a sanitiser is a good idea, but that isnt the only thing you should be considering. In the design schema of an application you must have considered what could possibly break at each step of the way - its not good enough just to put everything through a sanitiser. No amount of patching can fix a flawed design.

As for a remove nasty characters regex, the strictest would be

if (/[^A-z0-9]/) { print "$_ contains nasty characters." }

Of course once you've determined it contains nasty characters you be very careful with it (such as possibly not printing it).

You usually have to add punctuation and stuff to the regex, depending on your input. Note that this regex will deal with HTML input very poorly, but you have to be extra super careful about allowing HTML in your input (as rusty found out a couple of stories back).
What is the helix?
[ Parent ]

Re: Very well spoken.... (none / 0) (#8)
by henrik on Tue Apr 18, 2000 at 09:10:05 AM EST

If you don't write the app with security built in from the beginning, you'll have holes. No amount of going back and looking for holes will fix what you should have done from the beginning. (Not to mention it's a lot easier to do it right the first time around). If you're doing CGI's - don't assume that the forms on the page won't be edited by an attacker.

Here's what i usually do:
1) Implement new feature
2) See that it's working with valid data
3) Pound at it with invalid input. Good things to try are: null length input, huge input, border conditions, and borders +1, -1 (0, 127, 256, 65536, etc..). Most bugs will be there.

Atleast insert a # fix me - check input data here. This problem isn't as bad with perl as with C though. It's a lot easier to check for bad data (something like: next if (/[^0-9A-z]/);)


PS. See my sig =)

Akademiska Intresseklubben antecknar!
[ Parent ]

Re: Very well spoken. ... (none / 0) (#14)
by bgp4 on Tue Apr 18, 2000 at 11:33:49 AM EST

Thanks :)

The biggest security problems tend to be high level one's, not buffer overflows. A buffer overflow can be fixed with a patch. A gaping hole in some protocol your program uses can cause an entire rewrite and can doom your software through bad PR. Security must be thought of at every level of writing software.

You may want to check out http://www.shmoo.com/securecode. It's some references I've gathered to help folks write and design good code. It's a start on what I hope to be a growing resource. I'm about to start a new job as a software security consultant/researcher. Part of my goal there is to produce more literature on designing good programs to help the people in the open source community lock things down.

May all your salads be eaten out of black hats
[ Parent ]
Re: Very well spoken.... (none / 0) (#19)
by Inoshiro on Tue Apr 18, 2000 at 04:59:38 PM EST

I know I've posted a few security related items here, but how soon should I start worrying about security in my application?

The moment you are designing the parts of the program that either accept input, produce output, or manipulate data. Those are the spots where security problems occur. Unchecked sprintf, strcpy, etc, all lead to problems.

[ イノシロ ]
[ Parent ]
Re: Very well spoken.... (none / 0) (#21)
by Dangermouse on Tue Apr 18, 2000 at 10:42:08 PM EST

I know I've posted a few security related items here, but how soon should I start worrying about security in my application?

Right from the very start. You should be thinking about security issues as you begin designing the *specifications* of the the application, let alone the code.

No one has "Rights", neither machines nor flesh-and-blood. Persons...have opportunities, not rights, which they do or do not use. - Lazarus Long
[ Parent ]
The other reason, of course, is tha... (none / 0) (#3)
by inspire on Tue Apr 18, 2000 at 05:02:29 AM EST

inspire voted 1 on this story.

The other reason, of course, is that users are familiar with POP, and usually loathe to change their established clients and stuff just to fulfill some sysadmin's dream of running the perfect system...
What is the helix?

Frankly I like this story because I... (none / 0) (#5)
by stompro on Tue Apr 18, 2000 at 06:12:17 AM EST

stompro voted 1 on this story.

Frankly I like this story because I can't stand IMAP and this is fuel for my fire against it.

Re: Frankly I like this story because I... (none / 0) (#17)
by fluffy grue on Tue Apr 18, 2000 at 01:49:00 PM EST

Why not explain why you can't stand IMAP? I personally *love* it. The excuses I've always heard for hating the protocol are based on the implementation (which is a problem, yes, but why hasn't anyone programmed anything better?) and the bandwidth requirements (which are really overstated, IMO).
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Oh man, and IMAP is my favorite mai... (none / 0) (#4)
by kovacsp on Tue Apr 18, 2000 at 07:37:34 AM EST

kovacsp voted 1 on this story.

Oh man, and IMAP is my favorite mail access protocol! I'd really hate to go back to POP.

Re: The Reason IMAP Has Not Caught On (none / 0) (#7)
by Matthew Guenther on Tue Apr 18, 2000 at 08:45:53 AM EST

Slightly offtopic...

Has anyone tried CourierIMAP? I'd be curious to hear how it stacks up compared to the UW daemon.


Re: The Reason IMAP Has Not Caught On (none / 0) (#9)
by Anonymous Hero on Tue Apr 18, 2000 at 09:43:40 AM EST

CourierIMAP is for Maildir systems only. Under that, its a wonderful daemon; it's easy to set up and use, and I've never had a problem with. While we're on the subject, Maildirs are great too. There's no Mailbox locks at all.

[ Parent ]
Re: The Reason IMAP Has Not Caught On (none / 0) (#15)
by Matthew Guenther on Tue Apr 18, 2000 at 12:47:35 PM EST

Yes; Maildir rules, in fact I would've asked why Maildir hasn't caught on before I asked about IMAP's popularity. :)


[ Parent ]
SUSECompatment is your friend. (none / 0) (#10)
by nictamer on Tue Apr 18, 2000 at 10:14:47 AM EST

See http://www.suse.de/~marc/ . Basically, it's a chroot on steroids, with the added benefit of being able to set/drop capabilities. That's basically what I'm going to install IMAPd with on my next machine. Note that I'm probably going to use Courier IMAP anyway.
Religion is for sheep.
Re: The Reason IMAP Has Not Caught On (none / 0) (#11)
by prevostjm on Tue Apr 18, 2000 at 10:53:36 AM EST

This is kind of sad, because there are a couple of servers out there which are
not at all as crappy as the uwash server.  I've been using Cyrus imapd (which
provides a very good pop server as well) for years now, both as a user and an
admin.	It does a great job.

As far as the protocol is concerned, well, it's utter crap.  Someday, the IETF
needs to get a fucking clue and start defining languages/text protocols in
terms of a separate lex and parse phase.  That said, IMAP does provide a lot
better protocol than POP, at least when people want to store mail on the
server.  And it makes a great tool for storing mail for things like mailing
list archives.	(I periodically scan for webmail tools that can be used as just
a mail archive reader, but never find any.  :( )

Anyway, it has its warts, but IMAP works okay.	And if you care, there *are*
servers that don't suck.  You can blame the protocol badness on Crispin, and
you can probably blame uwash's server's badness on him, too.  But don't avoid
the protocol just because everybody thinks of Crispin's server and "client
library" when they think IMAP.

Re: The Reason IMAP Has Not Caught On (3.00 / 1) (#13)
by ebunga on Tue Apr 18, 2000 at 11:18:49 AM EST

Cyrus IMAP is definitely the way to go.  I've never had any troubles with it. 
However, if you want to use the cyrusbb (not the cyrus mailer) mailer with
sendmail, you'll have to add a LOCAL_RULE_0 on your own for it so it will catch
messages sent to bb+something, well, atleast under Sendmail 8.9.3 and Sendmail
Pro.  The cyrusbb mailer is very great, especially if your organization wants
to setup an archive for, say, an internal mailing list. 

For example, your admin mail gets sent to admin@yourdom.com.  That would be an
alias for all your admin people, and bb+staff.admin@yourdom.com.  Then, you can
just use cyradm to give the people you want to have read access to the archive
the right permissions, and you have a wonderful archive setup.

Cyrus really is a wonderful IMAP and POP server.  I have yet to see something
else that performs as well as it does.

[ Parent ]
IMAP != UW (3.00 / 1) (#12)
by megacz on Tue Apr 18, 2000 at 11:14:36 AM EST

I think a lot of people here are forgetting Carnegie Mellon's Cyrus server. It provides POP3 and IMAP access to the same mailboxes. It's a hell of a lot more secure than the UW server -- CMU's been running it on a campus full of immature 31337 h4x0rs for four years now.

I run the Cyrus server without root privs on a shell account; it's fast and not incredibly hard to set up (MUCH easier if you have root privs).

About the only downside of the server is that it does *not* use the standard /var/mail format (which is terribly inefficient, both in cases of large mailboxes and cases of a large number of users on the system). So you can't use elm, etc to read your mail once you make the switch to Cyrus.

IMAP itself is a pretty ass protocol to write code for, but featurewise it kicks the crap out of POP3 (stuff like getting the server to grep through your mail for you and having multiple outstanding transactions over the connection are pretty sweet).

Search pricewatch, streetprices, and others all at once with lowerbound.org

Search pricewatch, streetprices, and others all at once with lowerbound.org (now with discussions!)
Re: IMAP != UW (none / 0) (#16)
by Anonymous Hero on Tue Apr 18, 2000 at 01:04:26 PM EST

Ok, ok, we get the point about lower bound already!!! :P

Just kidding. I liked LB, great work, and if you get around to making huge improvements to it (or feel like explaining some of your 'adaptive learning techniques' in a programming type article) I wouldn't mind hearing about it again.


[ Parent ]

Washington University Software only.. (none / 0) (#18)
by Inoshiro on Tue Apr 18, 2000 at 04:54:59 PM EST

I hate to say this, but IMAP is living well and fine, thanks to the Cyrus development team. It's only Washington University software that suffers from this regrettable development team/unadited code combination.. If you admin a box, don't use software from that insitution. It's that simple ;-)

[ イノシロ ]
U-Wash != Washington University (none / 0) (#24)
by Anonymous Hero on Tue May 09, 2000 at 06:04:32 PM EST

U-Washington is in Seattle. Washington University is in St. Louis. They are very different institutions.

[ Parent ]
an important question (none / 0) (#20)
by xah on Tue Apr 18, 2000 at 05:26:40 PM EST

This is an important question because IMAP's lack of popular acceptance has fed Microsoft Exchange's popular acceptance. When I was still sysadminning full time (a little less than a year ago), the argument to move from the antiquated Novell/Mercury/Pegasus solution to NT/Exchange/Outlook was motivated in large part by the MAPI remote access to mailboxes from individual clients. This is of course what IMAP provides, and I kept bringing up IMAP in response. (There is actually a somewhat free IMAP server for Novell boxen, based on the Netscape mail server, from Novonyx.) I don't know of any superb IMAP servers, however. Cyrus was mentioned, but apparently that isn't available on many platforms. Are there NT or Novell versions, for example?

I don't know what it is about mail servers, but their developers are typically idiosyncratic. For example, David Harris, who created Mercury/Pegasus, is not one to listen to reasonable suggestions, such as "port to Linux." The author of sendmail is renowned for his distinct style. And then there is Mark Crispin of IMAP, whose "exploits" are described above. AFAIK, when I'm considering what software to install on the Internet, security is of prime importance.

The official IMAP is hosted at imap.org, but that is only a reference standard, albeit a working one.

Re: The Reason IMAP Has Not Caught On (none / 0) (#22)
by scriptkiddie on Tue Apr 18, 2000 at 11:50:33 PM EST

IMAP *has* caught on, at least here in Seattle. I guess that could be expected....

Personally, I think both the mail protocols need to be scrapped. They're simultaneously way too complicated and poor in features. We need a mail delivery protocol that has built-in support for PGP, has a single, well-defined rich text format (unlike the current HTML mess), can support attachments without breaking things half the time, is extensible, and is integrated with some kind of directory system.

I'm constantly surprised by how persistent users are in getting things like rich text and encryption to work weel in every MUA and MTA, but if the world had an efficient and extensible way to send mail, I think people would make use of these features more often. Maybe someday.

Re: The Reason IMAP Has Not Caught On (none / 0) (#23)
by Erno on Wed Apr 19, 2000 at 12:03:53 PM EST

The problem with IMAP is that there is only one free (free speech sense) mature server implementation. And the free software people probably don't like UW much (remember when they changed the pine license to a more restrictive one and then threatened to sue the people who planned to fork it and make a free version? (too bad we didn't have slashdot then (imagine "ssh.fi sends cease-and-desist letter to openssh developers")))

POP is a much simpler protocol, so there are many more good servers. I would also guess that many experienced users who would make use of the nice features of IMAP probably prefer shell accounts anyway, and POP is good enough for the rest...
-- erno

The Reason IMAP Has Not Caught On | 24 comments (24 topical, 0 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!