Summary: | ASTERISK-20578: sip handle_incoming needs more calls to sec. framework | ||||||||
Reporter: | Walter Doekes (wdoekes) | Labels: | |||||||
Date Opened: | 2012-10-18 02:02:27 | Date Closed: | |||||||
Priority: | Trivial | Regression? | |||||||
Status: | Open/New | Components: | Channels/chan_sip/Security Framework | ||||||
Versions: | 10.10.0 13.18.4 | Frequency of Occurrence | |||||||
Related Issues: |
| ||||||||
Environment: | Attachments: | ||||||||
Description: | From ASTERISK-20506:
{quote} You do have a valid point there. auth_options_requests=no (the default) does mitigate the OPTIONS problem. But there are indeed a couple of other methods that do get the authentication process working and they should be sent to the security framework. \[Make new bug report #1] {quote} Two issues here: - handle_incoming() sports the magic number 9: if (res < 9) { sip_report_security_event(p, req, res); } should be fixed using extra constants in sip/include/sip.h - handle_incoming() calls other methods which can be used for brute forcing (OPTIONS, MESSAGE, ...). the calls to sip_report_security_event() are missing there. (perhaps it should be moved to check_auth) | ||||||||
Comments: | By: Matt Jordan (mjordan) 2012-10-18 08:50:53.965-0500 Added a new component "Channels/chan_sip/Security Framework" to help categorize issues liek this. By: Michael L. Young (elguero) 2012-10-18 13:30:58.452-0500 Since I am familiar with this code, do you want me to take a stab at this at all? Should it go into 10 the second part about reporting other SIP methods? If I recall, it was crunch time for Asterisk 10 when we tried to get this in and what prompted the addition was an email on the -dev list looking for registration events. So, that is what the original patch focused on and didn't include the other methods. By: Walter Doekes (wdoekes) 2012-10-18 14:47:41.917-0500 Go right ahead. My personal opinion is that it should be included in 11 LTS. Logically one would include it in 10 (dev) as well then. By: Matt Jordan (mjordan) 2012-10-18 16:02:32.534-0500 Agreed - you could argue either way that this is a bug versus an improvement, but I personally think the value added of covering all of the SIP requests makes it worthwhile. |