Re: [PLUG] pop3 server?

[gabriel rosenkoetter <gr@eclipsed.net>]

On Fri, May 02, 2003 at 08:41:59AM -0400, Martin DiViaio wrote:
> I once managed to convince an UW-IMAP server to dump the system password
> file. I used no special tricks, just standard IMAP commands. While this 
> wasn't the shadow password file, it was still a complete list of users on 
> the box.

Let me guess. You didn't chroot(8) imapd, and then you chdir(2)ed
to /etc and downloaded passwd. So? You were running imapd insecurely.
That's your fault as an administrator. And, in any case, that's no
more scary than giving users login accounts. You're effectively
doing this, even if their login shell is /bin/false, unless you
restrict which IMAP commands they're allowed to execute (which I
understood to be permissible to the standard, but I wouldn't swear
to it).

If that's not what you did, could you provide some more detail,
please? These accusations without grounding are awfully hard to
believe.

> Admittedly, this can be easily corrected by hacking the source code to 
> force a user into their mailstore but to me, it's a problem at the 
> protocol level that even allows this. (Also, such a hack violates the IMAP 
> specification.)

Well, the hack I'd use would be for imapd to do a chroot(2) for each
user login. That's perfectly legal as far as the standard goes, as
far as I can see. Quite a few ftp daemons function this way
(lukemftpd, NcFTPd, I think even wuftpd can be told to).

But you don't have to hack the source. Just chroot(8) imapd in its
rc script, run it as non-root (important because of the next step),
and give it access via sym links (or automounts!) to users' mail
stores.

On Fri, May 02, 2003 at 08:24:58PM -0400, Martin DiViaio wrote:
> specifications is the problem. If Cyrus or Courier do the same thing is
> really a moot point.

No, it really isn't. An inherent (well, STRONGLY advised) part of
the Cyrus install procedure (as for *any* responsibly maintained
daemon software) is to tell it to use its in-source code for
chroot(2). (This is preferable to using a daemon that runs under
chroot(8), as you don't have to use >1024 ports or find some hackish
way to give it the default IMAP port.)

> to chroot environments. The fact that these changes are (mostly) required 
> points to problems at the protocol level.

I don't agree. The IMAP protocol is designed to provide access to a
logical system. Limiting the access that daemon has to the real
system is what a responsible sysadmin does; present the logical
system to users that they actually need without compromising other
users' security.

> - Support for binary files

And? Unless you can show some way to force an imapd to JMP (or
similar) into an uploaded file, that's irrelevant. I suppose you're
also against ftpd and scp on similar grounds?

> - Ability to UPLOAD files to the server

Ditto. A protocol that involves server-stored mailboxes to which
remote users can write changes necessistates this. Why is it a
problem?

> - Ability to run programs on the server

Of this I was unaware. Can you show us how, please?

> Reality Check: Most of these "features" are not implimented in most of
> the IMAP programs currently available (except for maybe UW-IMAPd). I know
> this. That doesn't make IMAP any less dangerous.

Yes it does. Implementing a subset of a standard that still gets the
job done without leaving the system insecure precisely makes the
protocol less dangerous.

-- 
gabriel rosenkoetter
gr@eclipsed.net

Attachment: pgpP2wFRaI4Dx.pgp
Description: PGP signature