On Mon, Jun 23, 2003 at 04:08:11PM -0500, Jonathan Angliss wrote:
> Why? If they were bugs in SquirrelMail, you'd be able to replicate it
> in every imap client... yet you cannot... So it's IMAP specific, which
> means it's the fault of the IMAP server, and an INVALID accusation
> against SquirrelMail saying that "we" can move/delete/download files,
> when all we do is provide the functionality of what the IMAP server is
I consider it an insufficient input validation. There is no reason to have
a full/parent path in the mailbox name, therefore it should be disallowed.
While I agree SM isn't doing the damage here, it is acting as a conduit.
Closing that conduit is partially SM's responsibility and partially UW's.
> So how do we sanity check values? How are we supposed to tell the
> difference between a mailbox, or a real file? How are we supposed to
> know that the user is requesting a file that they shouldn't have
> access to? UW IMAP doesn't give us that kind of option to identify, it
> just serves everything... If you have access to a UW IMAP server,
> login, and take a look at the LIST "" "*" command... what do you see?
> Now how are we supposed to sanitize it, when UW is returning all
> files? I know where you are coming from, it's one of the many reasons
> I stopped using UW imap... but it's not realistic (in my views) for us
> to try second guessing what is being entered.
Yes, I agree that UW IMAP is not doing the right thing in this case, and that
SM can't eliminate all of the underlying problems in the MTA it relies on.
However, SM should also be doing checking and throwing out known bad values.
Mailbox names matching ^(/|../) should be thrown out.