[HN Gopher] Exploiting QUIC's Path Validation
       ___________________________________________________________________
        
       Exploiting QUIC's Path Validation
        
       Author : BitPirate
       Score  : 35 points
       Date   : 2024-01-13 13:13 UTC (9 hours ago)
        
 (HTM) web link (seemann.io)
 (TXT) w3m dump (seemann.io)
        
       | imperialdrive wrote:
       | Good write up. Thank you for explaining the fix as well!
        
       | iforgotpassword wrote:
       | I guess we're gonna see a lot of these issues over the years.
       | Even TCP still has some novel attack vector for a DoS once a
       | decade or so today, and it is a dinosaur conceived when the
       | default assumption was that everyone is playing nice on the
       | Internet.
       | 
       | Surprising to see that a protocol designed today still allows for
       | such trivial resource exhaustion attacks. And thanks to the
       | protocol living in user space, we're guaranteed that vulnerable
       | implementations will live on for years to come in docker
       | containers, smartphone apps, etc. (Granted in this case it seems
       | not that bad at least for the latter since this affects servers.)
        
         | BitPirate wrote:
         | I'd argue that the decision to keep it in userspace was the
         | right one. If an application doesn't get security updates, a
         | broken QUIC stack is probably the least of your worries.
         | 
         | You also mention Android, which is notorious for having a lot
         | of devices that don't get OS updates because they've reached
         | end-of-life.
         | 
         | Protocol ossification at the OS level is also a valid concern.
         | 
         | https://http3-explained.haxx.se/en/quic/quic-userspace
        
       | 10000truths wrote:
       | Good writeup, but can you point to _where_ in the spec this
       | behavior is mandated? I 'm looking at section 8.2 of RFC 9000,
       | and I see nothing implying a requirement to maintain an unbounded
       | queue of un-acked PATH_CHALLENGE packets. The closest I can find
       | is the final sentence in 8.2.1:
       | 
       | > Unlike other cases where datagrams are expanded, endpoints MUST
       | NOT discard datagrams that appear to be too small when they
       | contain PATH_CHALLENGE or PATH_RESPONSE.
       | 
       | But I don't read it as saying never to discard PATH_CHALLENGE
       | packets, only that the implementation should refrain from
       | filtering out such packets on the basis of them being too small.
       | 
       | So this strikes me as an implementation flaw, not an inherent
       | weakness of the protocol.
        
         | Veserv wrote:
         | Yeah, seems suspicious. PATH_CHALLENGE frame is used to
         | determine if a path is valid in the first place. It seems like
         | the correct operation of a client can not possibly depend on
         | lossless responses since, by its very nature, the client must
         | expect that it might be sending packets on a path to the void.
         | 
         | There is no way for a client to distinguish between a invalid
         | path and a server packet drop, so a server that randomly drops
         | such frames seems externally indistinguishable from a
         | "compliant" one. For that matter, you can even characterize
         | that as a path to the server that is "temporarily invalid"
         | which follows the letter of the spec.
         | 
         | The only problem that may exist here is if the spec actually
         | demands such a undetectable, unenforceable, irrelevant
         | requirement.
        
       ___________________________________________________________________
       (page generated 2024-01-13 23:01 UTC)