[Asterisk-Dev] Re: Inestability with H323

[Mark Spencer]

> All of the below discussion assumes I can listen in to a conversation.
> If you cannot listen in, well, you do not know the conversation is there
> to attack/exploit.

Then this is not a general attack or exploit.  SIP and other protocols are
all susceptible to the same thing (duh!)

> With iax2, control frames are sent as UDP, with information in the clear.

Of course (pending the IAX2 AES stuff).  So are SIP frames and of course
H.323 frames.  If you want them to be invisible, run on a VPN.

> 1)I can send hangup packets, to terminate the discussion.
> 2)I can send additional dtmf packets to cause havoc to an IVR system
> 3)I can send AST_FRAME_VOICE packets with a different codec.
>             This will change the variable specifying which codec to use
>             for decoding voice. Hopefully, the decoders will cope with the
>             wrong codec format, and not crash.

No big surprise.  Yes, the codecs to handle it properly if they're odd
sizes, although you could create annoying audio effects in the call.

>  =>See the point: it is much easier to wreck havoc on iax2 than openh323.
>    Does that mean iax2 has many more exploits than openh323?
>    Hmm, maybe I should have said, it is much easier to attack an iax2 system.

"Exploit" is generally read to indicate that there is some sort of remote
service exploit that allows you to gain root access.  IAX2 uses
information element structure to make buffer overflows effectively
impossible because there is no text parsing that is done.

>   OpenH323 does have that security layer of ssl when registering to a
>   gateway, so I suppose you could regard that as one less vulnerability
>   for openh323.

Hrm...  I've never heard of doing SSL with UDP instead of TCP, but If we
could do UDP+SSL, then we could presumably make IAX work with a pretty
good standards based system without even changing the protocol.
Interesting concept certainly.

> Let us not consider the presence of the asnparser as a security layer. The
> asnparser provides security by obscurity - it makes it harder for malicous
> people to attack. Some malicous people will go elsewhere, cause it is
> easier to attack easy targets. Others will work harder, cause there is a
> challenge.

The "C compiler" does not provide significant security by obscurity when
doing buffer overflow attacks against programs, so i don't see any reason
why the asn.1 one would either.  It's still just finding what you want to
change and changing it.

Anyway, I would strongly suggest you be more careful in selecting the
words you use to describe protocols in the future :)

Mark