[asterisk-dev] Asterisk 1.4.20-rc1 Now Available

Tim Panton thp at westhawk.co.uk
Mon May 5 08:03:08 CDT 2008


On 2 May 2008, at 19:02, Russell Bryant wrote:

> Steve Davies wrote:
>> Does this mean that the security fix in 1.2.28 suffers from the same
>> performance issues and needs a similar fix? The use of the word
>> "Critical" would suggest that if it exists in 1.2.x it needs fixing.
>> Or perhaps 1.4 got an "enhanced" version of the security fix?
>
> That's a good point ... hrm!
>
> The security fix really kills performance of chan_iax2 in such a way  
> that it
> pretty much makes it unusable under any reasonable load.   
> Backporting this fix
> is certainly possible, but it is pretty invasive to do to 1.2.  It  
> means
> backporting astobj2 to Asterisk 1.2.
>
> But, if chan_iax2 isn't very usable, I guess that's what we have to  
> do ...


Well, perhaps not.
The original security problem was to to do with using unauthenticated  
IAX accounts
as ddos amplifiers, send 2 carefully crafted packets with a spoofed  
from address
(a NEW and an ACK), and asterisk would send  50 packets a second for  
30 seconds
at the spoofed address.

Removing unauthenticated IAX accounts prevents this from happening.

If we really feel the need to protect 1.2 against this, one way would  
be to do something
tricksy with the timestamp in the 'ACCEPT' packet. ACK's are supposed  
to carry the same
stamp as the packet they ACK, so if you put a random timestamp in the  
ACCEPT, then checked
for the same value in the ACK, you'd be protected.

I don't think anything cares about the timestamp in an ACCEPT, (the  
jitterbuffer only cares
about media frames if I remember right)

Yep, it is a hack, but it might be worth considering instead of the  
effort of trying to backport
the ast2obj fix, which is (of course) a much better fix.

Whilst we are on that- how random are the new call numbers ? If I  
recall, we are only talking about 14 bits
is that right?

Tim.

>
>
> -- 
> Russell Bryant
> Senior Software Engineer
> Open Source Team Lead
> Digium, Inc.
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev




More information about the asterisk-dev mailing list