New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 5 users

Issue metadata

Status: Verified
Email to this user bounced
Closed: Jun 2014
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Sign in to add a comment

Issue 2172: PeerConnection accepts SDP offer/answer with ICE credentials longer than 256 characters

Reported by, Aug 4 2013

Issue description

What steps will reproduce the problem?
1. Create a PeerConnection
2. Let it create a SDP offer.
3. Feed it a SDP answer with ICE u-frag/pwd longer than 256 characters.

What is the expected result?
setRemoteDescription() should fail, because ICE credentials have a length limit of 256 characters (see

What do you see instead?
setRemoteDescription() succeeds and turns Chrome into a STUN gun, see

What version of the product are you using? On what operating system?
Chrome 28.0.1500.95 (Official Build 213514) on Linux
I am pretty sure this applies to other versions, too.

Please provide any additional information below.

Comment 1 by, Aug 5 2013

the attached patch should accomplish that. Not sure whether it would be more appropriate during operations like PushdownTransportDescription, it seems like something that should be enforced at a lower layer.
1.8 KB View Download

Comment 2 Deleted

Comment 3 by, Aug 5 2013

slightly updated patch
2.2 KB View Download

Comment 4 by, Aug 5 2013

While you are at it, you might also enforce the minimum length for ufrag (4) and pwd (22).

Comment 5 by, Aug 5 2013

mh... while I am at it ;-)

One might also enforce the alpha|digit|"+"|"/" ice-char rule, but that isn't checked in other places either and I did not find any string util to do so.
2.6 KB View Download

Comment 6 by, Aug 5 2013

Splendid. :-) Now the question remains when this will make it into a Chrome version?

Comment 7 by, Aug 5 2013

Status: Available
We will try to fix it in M30, otherwise for sure in M31. Thanks Philipp for the patch, I will take a look at it.

Comment 8 by, Aug 5 2013

Labels: Mstone-30

Comment 9 by, Aug 5 2013

mallinath: thanks. The unittests need also need fixes (because they're actually wrong), wait for a new patch.

Comment 10 by, Aug 5 2013

Enforcing a length of 4+ breaks lots libjingle_peerconnection unittests, some of them in a nontrivial way (things that serialize and reparse).

I'd go for the second ufragpdw256.patch first and solve the 4+ problem later (along with ice-char possibly).  Issue #1895  should prevent empty ufrag/pwd in the meantime (review appreciated, too :-)

Comment 11 by, Aug 8 2013

I think these changes should go in at a lower layer, i.e. SetRemoteIceCredentials down in P2PTC. Then they will still work with non-SDP use cases.

Comment 12 by, Aug 8 2013

Labels: Area-PeerConnection

Comment 13 by, Aug 14 2013

Project Member
Labels: Area-Transport

Comment 14 by, Aug 14 2013

Project Member
Labels: -Mstone-30 Mstone-31

Comment 15 by, Aug 14 2013

Project Member
Labels: -Pri-2 Pri-1

Comment 16 by, Aug 15 2013

Justin: for webrtc-usage this is somewhat difficult, since SetRemoteIceCredentials is called in the worker thread after PushdownTransportDescription has returned. See the attached patch (not fully ready yet, can submit later if desired)

Catching this in Transport::SetLocalTransportDescription or SetRemoteTransportDescription seems more appropriate to me.
11.6 KB View Download

Comment 17 by, Aug 15 2013

wrt comment 10, enforcing a length of 4+ breaks several unittests because BuildMediaDescription in doesn't check for empty ufrag/pwd and therefore adds "a=ice-ufrag:\r\n" lines.

Comment 18 by, Aug 17 2013 should take care of comment 17.

Comment 19 by, Jan 8 2014

Any idea on when/if this will be fixed? This is a serious DoS opportunity.

Comment 20 by, May 7 2014

Project Member
Labels: -Mstone-31 Mstone-37
Moving to M37 for now.

Comment 21 by, May 28 2014

There is already a rate limiter in Chrome that prevents this being used for DoS. If you think there is still a problem here, please supply a example page.

Comment 22 by, May 29 2014

Chrome is rate limiting this to 2 Mbit/s which is 16x more than you would be able to create with RFC compliant credentials. This looks pretty DoSy to me.

If you want to give it a try see my example at:

Comment 23 by, May 29 2014

Fix is available in WebRTC trunk, this issue will be fixed in next libjingle roll into Chrome.

Comment 24 by, May 29 2014

Nice. Can you point me to the change? I can't seem to find it.

Comment 25 by, May 29 2014

Never mind. I thought that you fixed it just now. I tested again with Chrome 37 dev and it's fine. Thanks.

Comment 26 by, Jun 2 2014

Project Member
Status: Fixed

Comment 27 by, Jul 10 2014

Project Member
Status: Verified
lgtm in 37.0.2062.15

Comment 28 by, Oct 5 2016

Project Member
Components: Network

Comment 29 by, Oct 5 2016

Project Member
Components: -Transport

Sign in to add a comment