[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