Subject: [secdir] WebRTC

From: Hank Nussbacher <[email-masked]>
Date: Sun, 08 Apr 2012 12:11:22 +0300

Dear Security Area people,

Quick intro:

WebRTC http://www.webrtc.org/ is a free, open project that enables web 
browsers with Real-Time Communications (RTC) capabilities via simple 
Javascript APIs.   It is supported by Google, Mozilla and Opera.  One can 
test it already in Chrome. Basically, it is meant to be a Skype replacement 
technology (no app to download - all built-in to the browser).  But there 
are many other ideas that can be used here with this technology.

Now we get to the security part.  As stated here: 
http://www.webrtc.org/blog/webrtcnowavailableinthechromedevchannel
one has to specifically enable "--enable-media-stream" in order to get it 
to work. That is now, but the future plan is to have this "on" by default 
in FF and Chrome by the end of 2012.

So what does the IETF have to say:

Security Considerations for RTC-Web
http://tools.ietf.org/html/draft-ietf-rtcweb-security-01
which caused:
RTCWEB Security Architecture
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01
Section 5.2:
"Clients MAY permit the formation of data channels without any direct user 
approval."

I can just see new apps all over the place using this technology opening a 
huge can of worms for data stealing from the PC running the app that did 
NOT ask permission for the formation of a data channel without the direct 
user's permission.  This is similar in concept to ActiveX:
http://en.wikipedia.org/wiki/ActiveX
"This made the web "richer" but provoked objections (since such controls 
ran only on Windows) and security risks (especially given the lack of user 
intervention). Microsoft subsequently introduced security measures to make 
browsing including ActiveX safer[6] . For example:

     digital signing of installation packages (Cabinet files and executables)
     controls must explicitly declare themselves safe for scripting
     increasingly stringent default security settings
     Internet Explorer maintains a blacklist of bad controls"

Microsoft didn't envision the security issues of a "lack of user 
intervention" and it took them 3 years to add the appropriate knobs to make 
ActiveX more secure.

I am not involved in WebRTC or the IETF group - I only found out about this 
incidentally.  I raise this issue to you guys and leave it the Security 
Area to decide whether section 5 needs to be changed or not.

Regards,
Hank Nussbacher

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 08 Apr 2012 13:37:32 +0100

Hi Hank,

This might be more appropriate for the security area
list [1] rather than the security directorate list.
(This one.)

Cheers,
S.

[1] https://www.ietf.org/mailman/listinfo/saag

On 04/08/2012 10:11 AM, Hank Nussbacher wrote:
> test it already in Chrome. Basically, it is meant to be a Skype
> replacement technology (no app to download - all built-in to the
> browser). But there are many other ideas that can be used here with this
> technology.
>
> one has to specifically enable "--enable-media-stream" in order to get
> it to work. That is now, but the future plan is to have this "on" by
> default in FF and Chrome by the end of 2012.
>
> "Clients MAY permit the formation of data channels without any direct
> user approval."
>
> I can just see new apps all over the place using this technology opening
> a huge can of worms for data stealing from the PC running the app that
> did NOT ask permission for the formation of a data channel without the
> direct user's permission. This is similar in concept to ActiveX:
> ran only on Windows) and security risks (especially given the lack of
> user intervention). Microsoft subsequently introduced security measures
> to make browsing including ActiveX safer[6] . For example:
>
> intervention" and it took them 3 years to add the appropriate knobs to
> make ActiveX more secure.
>
> I am not involved in WebRTC or the IETF group - I only found out about
> this incidentally. I raise this issue to you guys and leave it the
> Security Area to decide whether section 5 needs to be changed or not.
>
> Regards,
> Hank Nussbacher
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 8 Apr 2012 06:51:01 -0700

It also might be more appropriate for the rtcweb WG, which has been discussing this actively since the beginning. Instead of security folks forming opinions based on a post like this, it might be beneficial for us to look through the WG archives first.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 10 Apr 2012 08:10:28 -0700

On Sun, Apr 8, 2012 at 2:11 AM, Hank Nussbacher <[email-masked]> wrote:
> one has to specifically enable "--enable-media-stream" in order to get it to
> work. That is now, but the future plan is to have this "on" by default in FF
> and Chrome by the end of 2012.
>
> huge can of worms for data stealing from the PC running the app that did NOT
> ask permission for the formation of a data channel without the direct user's
> permission.  This is similar in concept to ActiveX:
> "This made the web "richer" but provoked objections (since such controls ran
> only on Windows) and security risks (especially given the lack of user
> incidentally.  I raise this issue to you guys and leave it the Security Area
> to decide whether section 5 needs to be changed or not.

FWIW, I am the person who wrote the text in question and though Hank
doesn't say so he privately contacted me and the RTCWEB chairs, and
what I told him is that the specific feature he is complaining about, the
data channel, is simply a direct channel between the browsers in question.
Since that channel is created and controlled by JavaScript under control
of the Web site, that JS can just as easily tunnel data through the site
via WebSockets/XHR, etc. I.e., this is just an optimization that allows
a direct connection. Thus, requesting user consent for the use of this
feature isn't really helpful, since this feature doesn't introduce new
risks of data exfiltration. [0]

Obviously, I'd be more than willing to listen to any security analysis that
indicated that this was wrong, but the handwaving above about
ActiveX doesn't really add anything as far as I can tell.

-Ekr

[0] Note that there are risks in terms of cross-protocol attacks, and
thus we require a handshake to prevent them; see
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01#section-5.3

Similarly, we require user consent prior to transmitting data derived from
the camera and microphone because that data is not otherwise available
prior to these features.
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01#section-5.2