[asterisk-dev] Permit/deny with negation patch

[Kevin P. Fleming]

On 03/20/2012 03:09 PM, Mark Murawski wrote:
> On 03/20/12 14:59, Tilghman Lesher wrote:
>> On Thu, Mar 8, 2012 at 11:11 AM, Tilghman Lesher<tilghman at meg.abyt.es>
>> wrote:
>>> https://reviewboard.asterisk.org/r/1592/
>>>
>>> I have a patch that has been languishing on the review tracker, even
>>> though it got a "Ship It" several months ago, and someone pointed out
>>> that it could plausibly be a bug fix, because permit/deny in realtime
>>> is incredibly difficult to use properly, because it depends upon the
>>> columns coming back from the database in a particular order. There's
>>> a plausible argument that this, therefore, could be a bug fix for
>>> realtime. Furthermore, since permit/deny controls a security aspect
>>> of realtime peers, if a realtime backend (such as LDAP) was not
>>> consistent in returning columns in a particular order, it could be
>>> considered a possible security issue.
>>>
>>> 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.
>>>
>>> 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?
>>
>> -Tilghman
>>
>
>
> This is a great looking feature, but I think it's hard to classify
> whether it's a security issue. People running 1.4 have most likely came
> up with ways to secure their systems. The patch doesn't fix a
> vulnerability per-say, and the other thing is that just downloading the
> next release won't fix screwed up setups. Someone will have to actively
> take advantage of this new syntax (ie: using a new feature).

There is a precedent for that though; requiring people to modify their 
configurations in order to take advantage of the vulnerability 
mitigation mechanism (say that 3.1415 times fast!) is reasonable.

> But then again, the iax calltokens were a new feature but also was a
> security update if I remember right.

Yes.

> For me, I use permit/deny from a database but I have my data returned
> back in specific orders so I have expected results every time.
>
> I would call it a "new security feature", which... depending on how
> badly people want it, might make sense to put into 1.4.
>
> No doubt it will sure make writing the permit/deny rules much easier
> when configured from a db though.

My vote is to treat it as a security vulnerability of 'low' severity and 
merge it into 1.4 and later release branches.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org