[asterisk-dev] Permit/deny with negation patch

Matthew Jordan mjordan at digium.com
Tue Mar 20 14:52:58 CDT 2012


<snip>

> > So I'm asking the developer community for opinions.  Ostensibly,
> > this
> > would otherwise only go into trunk, as a new feature.  However, if
> > it's only a bug fix, it could go into 1.8 forwards, and if it's a
> > security fix, it could go into 1.4, 1.6.2, and forward, and
> > generate
> > the release of a security document and new releases for these
> > branches
> > that are in security support mode.

This is one opinion, and I'm more then open to debate on this.

I think we could justify it as a bug fix, given that a change in the
presentation of fields - which is independent of Asterisk - causes a
behavioral change in Asterisk.

I'm less sold on it as a security vulnerability, simply because I
can't figure out how someone outside of the administrator would cause
the behavior to occur.  Sure, the administrator could reorder the
realtime fields, causing a behavioral change in how Asterisk
interprets the ACLs, but I'm not sure how that's any different from
an administrator adding a bad rule to their firewall, or some other
poor configuration choice (other then this one would be much harder
to anticipate).

If someone can come up with an attack vector that doesn't involve
an administrator mis-configuring a realtime backend and submit it to
security at asterisk.org, I'd change my mind about it.

> > I don't consider this a high security issue, as nobody has yet
> > demonstrated that this is vulnerable in the wild.  It is likely
> > that
> > only certain systems _might_ be vulnerable in very limited
> > circumstances, so the developer community (specifically those who
> > use
> > permit/deny in realtime peers) are encouraged to voice their
> > opinions
> > and even to try out the patch.
> >
> > So in summary, is this a security fix?  Or only a bug fix?  Or just
> > a
> > new feature?
> 
> So seeing no objection, we'll make this a security issue and patch
> 1.4, right?  Bueller?  Bueller?

We have 30 days to decide :-)

> -Tilghman
> 
> --
> _____________________________________________________________________
> -- 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