Details
Description
The fix for ASTERISK-16867, commit 085b7b2 ignores sRTP Replay Protection…
libSRTP has no API for this. Therefore, the fix went even further and re-creates the connection to the library. That has the side-effect that the sRTP-ROC is reset to zero. Normally, the sRTP-ROC is incremented each time the remote RTP-SEQ wraps from 0xffff to 0x0000. If you reset the sRTP-ROC, you cannot authenticate the remote RTP packets anymore at all. Consequently, a remote attacker is even able to tear down long-lastest calls (20 milliseconds × 0xffff ~ 21 minutes and 51 seconds).
In the past, Asterisk has seen several enhancements when it comes to sRTP, like ASTERISK-20194, which handles re-INVITEs with new key material. Therefore, it is questionable whether this change is still needed nowadays. I went through my collection of sRTP implementations and found just two software platforms affected: Akuvox and VTech, both in the Call Hold/Resume scenario (see RFC 5359 section 2.1).
In ASTERISK-16867, I mentioned a bug with VTech and SIP Session Timers. That got fixed just days after. And this can be workarounded in Asterisk by refusing timers. However, in my recent test, I found that bug in hold/resume. That was reported via Snom and acknowledged under the ID VTECHDEV-350.
Attached are two patches – hopefully, I am allowed to see/edit/attach those – one for Asterisk 13 and one for Asterisk 17. I went for approach C, with a new configuration setting to change the state of Replay Protection at runtime in general via the configuration file rtp.conf. However, because of the severity of this issue, Replay Protection is enabled on default. Therefore, when applying those patches, a note in CHANGES is required because, on default, Asterisk is going to break compatibility with broken remote parties.
This way, the administrator is able to roll-back until the user-agent manufacturer reacts. If you do not like that approach, because even such a configuration option would be too much risk for your users, you can simply revert the fix for ASTERISK-16867 and achieve the same effect.
Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.
A good first step is for you to review the Asterisk Issue Guidelines if you haven't already. The guidelines detail what is expected from an Asterisk issue report.
Then, if you are submitting a patch, please review the Patch Contribution Process.
Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at https://www.asterisk.org/terms-of-use/.