james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: [IMAP] Securing IMAP?
Date Sun, 30 Mar 2008 13:13:20 GMT
On Sat, Mar 29, 2008 at 11:06 AM, Robert Burrell Donkin
<robertburrelldonkin@gmail.com> wrote:
> On Wed, Mar 26, 2008 at 11:28 PM, Bernd Fondermann
>
> <bernd.fondermann@googlemail.com> wrote:
>
> > On Wed, Mar 26, 2008 at 11:40 PM, Robert Burrell Donkin
>
>  <snip>
>
>
>  >  >  >  >  it seems a little foolish to allow an untrusted client to try
>  >  >  >  >  arbitrary input against the complexity of the fully featured
parser
>  >  >  >  >  before logging in. perhaps a secure encoder could be used before
the
>  >  >  >  >  client has logged on.
>  >  >  >
>  >  >  >  right. in the best case, only a reduced range of inputs is considered
>  >  >  >  by the server during handshake. this is what I tried in Apache Vysper.
>  >  >  >  this should not reduce spec compliance.
>  >  >
>  >  >  how did you approach this problem from a design perspective?
>  >  >
>  >  >  (i've been turning over the idea of using a optional wrapper for the
>  >  >  initial handshake)
>  >
>  >  the parser is 'abstract' and only identifies command boundaries. every
>  >  handler receives a full representation of the command text. only then
>  >  comes interpretation into play. but before the command handler can
>  >  kick in, a processor checks if the command is valid for the current
>  >  state of the session. this effectively guards from execution of
>  >  unauthorized code.
>
>  hmmm...
>
>  IMAP is tricky to parse. the structure is
>
>  TAG<SPACE>COMMAND<SPACE>REST-OF-LINE
>
>  where REST-OF-LINE command dependent and often quite complex. i would
>  like to protect the command parsers from arbitrary input.

what I did in my XMPP implementation is to parse the command into a
command data structure (this is easy, since XMPP uses a subset of
XML). the handlers do not receive a String, but a ready-to-use object.
they only have to check nodes, attributes and so on.
I have no idea how to accomplish something similar for IMAP, where it
is depending on the command if  REST-OF-LINE is well-formed.

>  a similar schema could be adopted by rewriting the parser for TAG and
>  COMMAND more securely. ATM unlimited stringbuffers are used and will
>  continue to add more characters until whitespace is encounted. then
>  the command parser is looked up by command. a separate handler with a
>  limited charbuffer could be used for the TAG and a bytewise tree for
>  commands. more complex and may take a little while to write but should
>  be more secure.

+1.
any protocol profits from defining
a. well-formed-ness
b. syntactical correctness
c. semantical correctness

a. should cover command lengths and the set of all legal characters.
protocols (and implementations) should be strict in the sense that if
a client fails to comply to this, the communication is terminated
immediatly, even without sending a BYE.
this is my opinion. don't know how easy this is to accomplish in IMAP.
b. is where the handler should come into play, only.

so if an implementation does not deal with a.) in the first place, it
is probably cumbersome and error-prone to deal with it in every
handler.

>  prior to LOGIN, it is probably not unreasonable to use a BYE when an
>  overlong TAG or inappropriate COMMAND is encountered.
>  opinions?

+1, but could even be more strict, see prev statement.

HTH, but maybe it doesn't, sorry ;-)

  Bernd

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