[HN Gopher] You Can't Spell WebRTC Without RCE - Part 1
       ___________________________________________________________________
        
       You Can't Spell WebRTC Without RCE - Part 1
        
       Author : ementally
       Score  : 33 points
       Date   : 2024-08-04 10:54 UTC (12 hours ago)
        
 (HTM) web link (margin.re)
 (TXT) w3m dump (margin.re)
        
       | kelnos wrote:
       | This honestly doesn't surprise me all that much. More than 10
       | years ago I had to dive into Chrome's WebRTC stack for interop
       | and reverse-engineering purposes (at the time, the WebRTC specs
       | were changing all the time, and were poorly documented). The code
       | was _massive_ ; it turns out it's a fairly complicated protocol,
       | and dealing with audio and video and handling sessions (even
       | without including a signaling protocol) requires a lot of code
       | (not to mention the use of the then-obscure DTLS security
       | protocol on top of UDP). And that was 12 years ago; I'm sure
       | WebRTC's surface area has only increased since then.
       | 
       | I assume Signal uses a different implementation, but I'm sadly
       | not surprised there are security issues lurking inside it.
       | 
       | This bit at the beginning made me chuckle, though:
       | 
       | > _It's another average Friday morning and my iPhone shows 705
       | unread Signal messages_
       | 
       | I feel like I'm doing communications wrong... if I wake up and
       | find 20 unread messages across all my chat apps, that's on the
       | high side for me.
        
         | upon_drumhead wrote:
         | My personal phone is lucky to get more than 5 a day. My work
         | phone gets hundreds a day, due to automation and slack ops.
         | 
         | Regardless, I think a handful of high quality meaningful
         | messages is well worth hundreds of low value ones.
        
         | cwillu wrote:
         | To be clear, they are not demonstrating issues in the code,
         | they are providing a walkthrough of how one _could_ exploit an
         | issue if one existed and the mitigations weren't in place, as
         | an concrete introduction to how this is done against a mobile
         | app.
         | 
         | e.g. "Given a vulnerability, this is what crafting an exploit
         | looks like"
        
       | jauntywundrkind wrote:
       | > _Next, let's give ourselves an arbitrary write. To make the
       | exploit a bit simpler, we'll give ourselves an arbitrary memcpy._
       | 
       | They took Signal-webrtc & added a vulnerability to it.
       | 
       | Maybe maybe maybe there's some other means to exploit the lack of
       | time check, but this feels like such a massive & overwhelmingly
       | staked out nothing burger.
        
         | BobbyTables2 wrote:
         | I'm also surprised by this...
         | 
         | They're usually known for high quality research, not fluff like
         | this...
        
           | cwillu wrote:
           | "Now that we have 0-click parsing available, we need some
           | vulnerabilities. As mentioned previously, we are not
           | reporting any Signal 0-days in this post; the point of this
           | series is a crash course in Signal, WebRTC, and iOS research.
           | Let's leverage Signal-WebRTC's source code to inject our own
           | vulnerability primitives and keep our research moving."
        
       | ec109685 wrote:
       | Signal should separate WebRTC handling into its own process so
       | that an exploit doesn't have access to its critical database.
       | 
       | A messaging app has almost all the same security concerns as a
       | browser, so the recommendations here apply:
       | https://developer.apple.com/documentation/browserenginekit
        
       ___________________________________________________________________
       (page generated 2024-08-04 23:01 UTC)