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. > > 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. IMAP does not set such limits. the protocol specifies that a BYE must be sent on termination. > 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 > > 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 unfortunately being more strict probably means bending the specification a little too far - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
