Recently, some of my company's IMAP servers were unwitting
participants in a cross-site scripting exploit demonstration. You can
read more about it here:
http://resources.enablesecurity.com/resources/the%20extended%20html%20form%20attack%20revisited.pdf
But in this mesasge, I'm speaking only for myself.
Some HTTP clients (okay, Internet Explorer) can be tricked into
sending an HTTP request over port 993, imaps. They're too smart to
use 143, but 993 is no problem.
IMAP has the quirk that some of the client's request is blindly echoed
back--that is, the command tag.
If that tag is <script>...</script>, it is possible for the result
page to have a small amount of JavaScript that can acquire a user's
cookies. I don't believe anyone actually used this to steal cookies,
just to demonstrate that it's possible.
Our server had the additional flaw that we did not perform careful
parsing on the tag, allowing characters outside the already generous
range permitted by IMAP. In particular, our server allowed '(' and
')'.
When I tried this exploit against a Cyrus server, it didn't work, at
least in part because () are not allowed, but the Cyrus the server was
still forced to process about 15 invalid commands. I didn't check the
UW server because I didn't have one handy.
The protocol clearly allows <>;/&#!$, etc., all valuable characters
that could contribute to a JavaScript-based attack
I recognize that, in some sense, this isn't an IMAP problem, but it
remains a problem that can be fixed in IMAP, and can harm users if you
have HTTP and IMAP servers in the same domain.
I recommend the following be implemented in IMAP servers:
protocol legal:
Make sure '%', '(', and ')' can't occur in tags that are
echoed back. This is just enforcing the protocol carefully.
creative interpretation of protocol:
hang up after multiple consecutive invalid commands
hang up if the first command looks like HTTP
(either the tag is POST or PUT,
or the line ends with HTTP/1.1, etc.)
I want to claim that the latter two are technically protocol legal,
based on the position that an IMAP server can say NO to any command,
but that's a stretch.
I have implemented some of these hacks without apparent consequence,
except our security people like me.
I'm looking for additional heuristics to hamper this type of attack.
I belive a future IMAP specification should restrict tags to
[a-zA-Z0-9]+, since this would preclude all of the characters likely
to trigger problems.
For HTTP clients, perhaps the best way to work around attacks like
this is to treat invalid HTTP responses as errors, or if you must
interpret them as pages, show them as text/plain, or
JavaScript-disabled, not as HTML. Firefox 1.5 appears to display such
pages in text/plain, although newer versions block access on port 993
entirely.
Speaking only for myself, of course.
Tim