Issues with the Keberos codec

[Emmanuel Lecharny <el...@apache.org>]

Hi,

the way we decode the Kerberos is not good, as I said in a previous mail. We
can't process a fragmented PDU.


I suggested that we manipulate the State in order to pick the right
container, but this is really too complex, and brittle.

I have one other solution :
pre-read the PDU size. As we are using TLV, the Length once read will let us
read the Value as an opaque element, then once completely read, we will be
able to process the PDU

This seems a minimal cost to get the codec working with the grammars we have
defined.

thoughts ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Issues with the Keberos codec

[Emmanuel Lecharny <el...@gmail.com>]

On 11/16/10 1:52 PM, Alex Karasulu wrote:
> On Tue, Nov 16, 2010 at 5:14 AM, Kiran Ayyagari<ka...@apache.org>wrote:
>
>
>> sounds good to me, OTOH what are the disadvantages of reading whole
>> PDU and processing it?
>>
>>
> Increases potentials for large PDU attacks to overflow memory but we can
> mitigate that with limits on the PDU size we're willing to process.
The potential for PDU attack is the same. At least, we avoid creating a 
data structure immediately.

However, I think we will need to define a dedicated KRB_PDU 
configuration parameter, because Kerberos PDU are very likely to be 
smaller than LDAP PDU.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Issues with the Keberos codec

[Alex Karasulu <ak...@apache.org>]

On Tue, Nov 16, 2010 at 5:14 AM, Kiran Ayyagari <ka...@apache.org>wrote:

> On Tue, Nov 16, 2010 at 4:48 AM, Emmanuel Lecharny <el...@apache.org>
> wrote:
> > Hi,
> > the way we decode the Kerberos is not good, as I said in a previous mail.
> We
> > can't process a fragmented PDU.
> >
> > I suggested that we manipulate the State in order to pick the right
> > container, but this is really too complex, and brittle.
> > I have one other solution :
> > pre-read the PDU size. As we are using TLV, the Length once read will let
> us
> > read the Value as an opaque element, then once completely read, we will
> be
> > able to process the PDU
> > This seems a minimal cost to get the codec working with the grammars we
> have
> > defined.
> > thoughts ?
> sounds good to me, OTOH what are the disadvantages of reading whole
> PDU and processing it?
>
>
Increases potentials for large PDU attacks to overflow memory but we can
mitigate that with limits on the PDU size we're willing to process.

Otherwise it sounds like a good idea if the grammar in the current situation
is getting too cumbersome to deal with. Really KRB PDU sizes are not that
large AFAIK so this is not that bad. It does not follow with zero copy
principles of building good performing network servers but for now we need
to go this route until we find a better way later.

-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Re: Issues with the Keberos codec

[Kiran Ayyagari <ka...@apache.org>]

On Tue, Nov 16, 2010 at 4:48 AM, Emmanuel Lecharny <el...@apache.org> wrote:
> Hi,
> the way we decode the Kerberos is not good, as I said in a previous mail. We
> can't process a fragmented PDU.
>
> I suggested that we manipulate the State in order to pick the right
> container, but this is really too complex, and brittle.
> I have one other solution :
> pre-read the PDU size. As we are using TLV, the Length once read will let us
> read the Value as an opaque element, then once completely read, we will be
> able to process the PDU
> This seems a minimal cost to get the codec working with the grammars we have
> defined.
> thoughts ?
sounds good to me, OTOH what are the disadvantages of reading whole
PDU and processing it?

-- 
Kiran Ayyagari