james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [IMAP] Securing IMAP?
Date Thu, 03 Apr 2008 22:24:59 GMT
On Sun, Mar 30, 2008 at 4:21 PM, Bernd Fondermann
<bernd.fondermann@googlemail.com> wrote:
> On Sun, Mar 30, 2008 at 3:35 PM, Robert Burrell Donkin
> <robertburrelldonkin@gmail.com> wrote:

>  >  unfortunately being more strict probably means bending the
>  >  specification a little too far
>
>  ... or, in contrast, being unable to control/counteract out-of-memory
>  exploits and more generally attacks which exploit well-formendness
>  related issues. :-/

TAG and COMMAND could be checked for well-formedness. IMAP is a
line-based protocol. each line starts with a TAG.

from the spec:

  tag             = 1*<any ASTRING-CHAR except "+">
  ASTRING-CHAR   = ATOM-CHAR / resp-specials
  ATOM-CHAR       = <any CHAR except atom-specials>
  atom-specials   = "(" / ")" / "{" / SP / CTL / list-wildcards /
                  quoted-specials / resp-specials
  CHAR is any 7bit ASCII (0-127)

when a session is unauthenticated, a specialist handler could check
each octet and issue a BYE if the octet is outside the acceptable
range. tags should also be small: there seems no reason why
unauthenticated clients should be allowed to send tags bigger than a
reasonable buffer size. so, issue a BYE in this case too.

commands need to be extensible at assembly time so that developers can
extend JAMES by adding new implementations. each COMMAND is an case
insensitive ASCII alphabetic word. so using some sort of linked tree
seems natural. begin by mapping any legimate octet -> 0...25, issuing
a BYE if any is outside the range.

L -> O -> G -> I -> N
X      X         -> O -> U -> T
C -> A -> P -> A -> B -> I -> L -> I -> T -> Y
X

potentially the space is pretty large so need to think about doing
this efficiently. the tree is going to be sparse so probably worth
distinguishing between the single entry (eg CAPABILITY above) and
bucket case (LOG-IN/OUT). when the link is a single entry, just check
it's value. when it's a bucket, use an array indexed by mapped
character value. whenever a value is missed, BYE would be issued.

different handlers can be used for unauthenticated and authenticated
protection the majority of commands. the strict handler would just
contain those commands appropriate for the unauthenticated state and
so issue a BYE if the client tried to send them.

(sounds like some more baroque coding will be required)

opinions?

in terms of blacklisting IPs, this is probably more naturally done at
the JAMES bio framework level.

opinions?

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message