[asterisk-bugs] [JIRA] (ASTERISK-29260) sRTP Replay Protection ignored; even tears down long calls

[Friendly Automation (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253895#comment-253895 ] 

Friendly Automation commented on ASTERISK-29260:
------------------------------------------------

Change 15456 merged by George Joseph:
rtp:  Enable srtp replay protection

[https://gerrit.asterisk.org/c/asterisk/+/15456|https://gerrit.asterisk.org/c/asterisk/+/15456]

> sRTP Replay Protection ignored; even tears down long calls
> ----------------------------------------------------------
>
>                 Key: ASTERISK-29260
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29260
>             Project: Asterisk
>          Issue Type: Security
>      Security Level: None
>          Components: Resources/res_srtp
>    Affects Versions: 13.38.1, 16.16.0, 17.9.1, 18.2.0
>            Reporter: Alexander Traud
>            Severity: Blocker
>              Labels: patch, security
>         Attachments: srtp_replay_protection-13.patch, srtp_replay_protection-17.patch
>
>
> The fix for ASTERISK-16867, commit [085b7b2|https://github.com/asterisk/asterisk/commit/085b7b212a1ff3a343b16a7b803527f2afd6ac1f] ignores [sRTP Replay Protection…|http://tools.ietf.org/html/rfc3711#section-3.3.2]
> libSRTP has [no API for this|https://github.com/cisco/libsrtp/issues/424]. 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|https://www.traud.de/voip] 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|https://tools.ietf.org/html/rfc5359#section-2.1]).
> In ASTERISK-16867, I mentioned a bug with VTech and [SIP Session Timers|https://tools.ietf.org/html/rfc4028]. 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)