You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2008/04/04 00:24:59 UTC
Re: [IMAP] Securing IMAP?
On Sun, Mar 30, 2008 at 4:21 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Sun, Mar 30, 2008 at 3:35 PM, Robert Burrell Donkin
> <ro...@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
Re: [IMAP] Securing IMAP?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Apr 4, 2008 at 5:50 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
> Robert Burrell Donkin wrote:
<snip>
> > in terms of blacklisting IPs, this is probably more naturally done at
> > the JAMES bio framework level.
> >
> > opinions?
> >
>
> +1. for the sake of re-usability, configurability, yes.
ideas about algorithms, designs etc?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Robert Burrell Donkin wrote:
> On Sun, Mar 30, 2008 at 4:21 PM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> On Sun, Mar 30, 2008 at 3:35 PM, Robert Burrell Donkin
>> <ro...@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?
sounds pretty good, +1
>
> in terms of blacklisting IPs, this is probably more naturally done at
> the JAMES bio framework level.
>
> opinions?
+1. for the sake of re-usability, configurability, yes.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org