[asterisk-dev] AST-2008-010: Asterisk IAX 'POKE' resource exhaustion

Nic Bellamy nicb-lists at vadacom.co.nz
Wed Jul 23 16:30:23 CDT 2008


Asterisk Security Team wrote:
>    +------------------------------------------------------------------------+
>    | Resolution | The implementation has been changed to no longer allocate |
>    |            | an IAX2 call number for POKE requests. Instead, call      |
>    |            | number 1 has been reserved for all responses to POKE      |
>    |            | requests, and ACK packets referencing call number 1 will  |
>    |            | be silently dropped.                                      |
>    +------------------------------------------------------------------------+
>   

Just looking at the patch for this, and am wondering if I've stumbled 
across a potential issue.

New code:
+               if (f.frametype == AST_FRAME_IAX && f.subclass == 
IAX_COMMAND_POKE) {
+                       /* Reply back with a PONG, but don't care about 
the result. */
+                       send_apathetic_reply(1, ntohs(fh->scallno), 
&sin, IAX_COMMAND_PONG, ntohs(fh->ts), fh->oseqno);
+                       return 1;
+               } else if (f.frametype == AST_FRAME_IAX && f.subclass == 
IAX_COMMAND_ACK && dcallno == 1) {
+                       /* Ignore */
+                       return 1;
+               }

So we drop any ACKs to destination callno #1

However, in find_callno() when we allocate a new callno...

start = 1 + (rand() % (TRUNK_CALL_START - 1));
for (x = start; 1; x++) {
...
}

As rand() gives us a number between 0 and RAND_MAX, does this not leave 
a small but non-zero chance that we'll pick a callno of #1 for our side, 
that will then have all its ACKs ignored?

(I'm completely open to the possibility that other code paths prevent 
this, but I didn't see them :-)

Cheers,
    Nic.

-- 
Nic Bellamy,
Head Of Engineering, Vadacom Ltd - http://www.vadacom.co.nz/




More information about the asterisk-dev mailing list