Review of Chrome's migration to WebRTC's Unified Plan, how false metrics may have misguided this effort, and what that means moving forward.
Editor’s Note: This post was originally published on October 23, 2018. Zoom recently started using WebRTC’s DataChannels so we have added some new details at the end in the DataChannels section.
Zoom has a web client that allows a participant to join meetings without downloading their app. Chris Koehncke was excited to see how this worked (watch him at the upcoming KrankyGeek event!) so we gave it a try. It worked, removing the download barrier. The quality was acceptable and we had a good chat for half an hour.
webrtcH4cKS: ~ The WhatsApp RTCP exploit – what might have happened?
As you may have heard, Whatsapp discovered a security issue in their client which was actively exploited in the wild. The exploit did not require the target to pick up the call which is really scary.
Since there are not many facts to go on, lets do some tea reading…
The security advisory issued by Facebook says
A buffer overflow vulnerability in WhatsApp VOIP stack allowed remote code execution via specially crafted series of SRTCP packets sent to a target phone number.
This is not much detail, investigations are probably still ongoing. I would very much like to hear a post-mortem how WhatsApp detected the abuse.
webrtcH4cKS: ~ Finding the Warts in WebAssembly+WebRTC
A while ago we looked at how Zoom was avoiding WebRTC by using WebAssembly to ship their own audio and video codecs instead of using the ones built into the browser’s WebRTC. I found an interesting branch in Google’s main (and sadly mostly abandoned) WebRTC sample application apprtc this past January. The branch is named wartc… a name which is going to stick as warts!
The repo contains a number of experiments related to compiling the webrtc.org library as WebAssembly and evaluating the performance. From the rapid timeline, this looks to have been a hackathon project.
webrtcH4cKS: ~ First steps with QUIC DataChannels
QUIC-based DataChannels are being considered as an alternative to the current SCTP-based transport. The WebRTC folks at Google are experimenting with it:
Looking for feedback: QUIC based RTCQuicTransport and RTCIceTransport API's are available as origin trial in Chrome 73 for experimentation.https://t.co/KVVEVmggms
— WebRTC project (@webrtc) February 1, 2019
Let’s test this out. We’ll do a simple single-page example similar to the WebRTC datachannel sample that transfers text. It offers a complete working example without involving signaling servers and also allows comparing the approach to WebRTC DataChannels more easily.
webrtcH4cKS: ~ Let’s get better at fuzzing in 2019 – here’s how
Fuzzing is a Quality Assurance and security testing technique that provides unexpected, often random data to a program input to try to break it. Natalie Silvanovich from Google’s Project Zero team has had quite some fun fuzzing various different RTP implementations recently.
She found vulnerabilities in:
- WebRTC — mostly issues in the RTP payload
- Facetime – a few out-of-bounds, stack corruption, and heap corruption issues
- Whatsapp and what didn’t work
In a nutshell, she found a bunch of vulnerabilities just by throwing unexpected input at parsers. The range of applications which were vulnerable to this shows that the WebRTC/VoIP community does not yet have a process for doing this work ourselves. Meanwhile, the WebRTC folks at Google will have to improve their processes as well.
webrtcH4cKS: ~ Messenger was not forced to wiretap but…
Back in August, Reuters reported on a “secret legal fight” between the FBI and Facebook about wiretapping Messenger calls. The Verge as they found our old post about reverse-engineering Messenger from 2015 and had a number of follow-up questions on it for a Messenger wiretapping article they ran. Technical details on the case are quite hard to find so I was not able to dig deeper into the specifics around wiretapping.
Reuters now reports that Facebook will not be forced to wiretap Messenger calls with the FBI noting:
webrtcH4cKS: ~ A playground for Simulcast without an SFU
Simulcast is one of the more interesting aspects of WebRTC for multiparty conferencing. In a nutshell, it means sending three different resolution (spatial scalability) and different frame rates (temporal scalability) at the same time. Oscar Divorra’s post contains the full details.
Usually, one needs a SFU to take advantage of simulcast. But there is a hack to make the effect visible between two browsers — or inside a single page. This is very helpful for single-page tests or fiddling with simulcast features, particular the ability to enable only certain spatial layers or to control the target bitrate of a particular stream.
webrtcH4cKS: ~ Chrome Screensharing Blues – preparing for getDisplayMedia
The Chrome Webstore has decided to stop allowing inline installation for Chrome extensions. This has quite an impact on WebRTC applications since screensharing in Chrome currently requires an extension. Will the getDisplayMedia API come to the rescue?
Screensharing in Chrome
When screensharing was introduced in Chrome 33, it required implementation via an extension as a way to address the security concerns. This was better than the previous experience of putting this capability behind a flag which lead to sites asking their users to change that flag… that got those sites an official yikes.
webrtcH4cKS: ~ So your VPN is leaking because of Chrome’s WebRTC…
We have covered the “WebRTC is leaking your IP address” topic a few times, like when I reported what the NY Times was doing and in my WebRTC-Notifier. Periodically this topic comes up now and again in the blogosphere, generally with great shock and horror. This happened again recently, so here is an updated look into this alleged issue.
The recent blog post titled VPN Leak by voidsec highlighting how 19 out of more than 100 VPN services tested “leak” IP addresses via WebRTC is a quite interesting read. Some of the details about WebRTC are not quite correct the results are interesting nonetheless. At is core this is someone who sat down to test a long list of services and their behaviour, one by one. This is not the most exciting research task, but exhaustive studies like this often find something interesting.