On Wed, Mar 26, 2008 at 11:28 PM, Bernd Fondermann
<[EMAIL PROTECTED]> 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.

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.

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

opinions?

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to