Martin DiViaio on Wed, 7 May 2003 00:27:08 -0400


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] pop3 server?


On the 5th day of May in the year 2003 you wrote:

> Date: Mon, 5 May 2003 11:02:43 -0400
> From: gabriel rosenkoetter <gr@eclipsed.net>
> To: plug@lists.phillylinux.org
> Subject: Re: [PLUG] pop3 server?
> 
> 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.


Question: Why couldn't imapd just tell me that the passwd file wasn't a 
valid mail spool file?

Answer: IT CAN'T ACCORDING TO THE SPECIFICATION! Non-spool file types are 
supposed to be supported and available.


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


It depends on the command. Some are optional, others are not.


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


As I said before, my problem is not that I did it but that the response
was CORRECT ACCORDING TO THE SPECIFICATION.


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


chroot was not an option at the time due to the mail spool files crossing 
several filesystems. I eventually went with the code hack as the best 
solution at the time. (Especially since I couldn't switch to Courier or 
Cyrus.)


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


Messages are really nothing but blocks of text. Why would you need binary
support at the protocol level?

As for jumping into an uploaded file, all you need to do is open the file,
select a byte position and start writing (if you have write access to the
file).

FTP and SCP are exactly what they claim, file access protocols. IMAP has 
file access abilities because of poor protocol design. There is a 
difference there.


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


I could agree with this if the upload was strictly limited to messages. 
It's not.


> > - Ability to run programs on the server
> 
> Of this I was unaware. Can you show us how, please?


My mistake, I was distracted at the time and accidentally called up an 
older version of the IMAP specs to verify this bit. It did support an EXEC 
command.


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


Ok, what happens when your favorite IMAP server's developers decide to do 
a full implimentation of the protocol specification?



_________________________________________________________________________
Philadelphia Linux Users Group        --       http://www.phillylinux.org
Announcements - http://lists.netisland.net/mailman/listinfo/plug-announce
General Discussion  --   http://lists.netisland.net/mailman/listinfo/plug