On Sun, Mar 30, 2008 at 3:35 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > On Sun, Mar 30, 2008 at 2:13 PM, Bernd Fondermann > > > <[EMAIL PROTECTED]> wrote: > > > > On Sat, Mar 29, 2008 at 11:06 AM, Robert Burrell Donkin > > <[EMAIL PROTECTED]> wrote: > > > 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. > > > > 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. > > depends on how you approach the parsing problem. AIUI there are some > complete parsers for IMAP which create a complete object model (but > these have difficulties of their own). JAMES parses the first two > productions and then passes the rest of the line to a parser > specialised for the task of decoding a command of the given type. so, > i don't think it would work given our approach to parsing.
ok, I see. <snip/> > > 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. > > IMAP does not set such limits. the protocol specifies that a BYE must > be sent on termination. ... and I agree it is reasonable to adhere to the spec this way. > > 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. > > IMAP is old fashioned and lacks a well-formedness layer mmh. > 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. :-/ Bernd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
