Re: [quicwg/base-drafts] Document request forgery (#3996)

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.



> +lack proper authentication. Endpoints MAY prevent connection attempts or
+migration to a loopback address. Endpoints SHOULD NOT allow connections or
+migration to a non-loopback address if the same service was previously
+available over a different interface or the address was provided by a service
+at a non-loopback address. Endpoints that depend on these capabilities could
+offer an option to disable these protections.
+
+Similarly, endpoints could regard a change in address to link-local address
+{{?RFC4291}} or an address in a private use range {{?RFC1918}} from a global,
+unique-local {{?RFC4193}}, or non-private address as a potential attempt at
+request forgery. Endpoints could refuse to use these addresses entirely, but
+that carries a significant risk of interfering with legitimate cases. Endpoints
+SHOULD NOT refuse to use an address unless they have specific knowledge about
+the network that indicates that sending datagrams to unvalidated addresses in a
+given range is not safe.
+

I agree with David.  I don't see any way that the MDNS thing would make sense except in a very narrow domain (which WebRTC is).  Nothing stopping someone from defining an extension, of course.

> +A client MUST NOT send non-probing frames to a preferred address prior to
+validating that address; see {{address-validation}}. This greatly reduces the
+options that a server has to control the encrypted portion of datagrams.
+
+This document does not offer any additional countermeasures that are specific
+to use of preferred addresses and can be implemented by endpoints. The generic
+measures described in {{forgery-generic}} could be used as further mitigation.
+
+
+### Request Forgery with Spoofed Migration
+
+Clients are able to present a spoofed source address as part of an apparent
+connection migration to cause a server to send datagrams to that address.
+
+The Destination Connection ID field in any packets that a server subsequently
+sends to this spoofed address can be used for request forgery.

No, this is general, but it is mentioned above.  I will add a reminder.

> +
+Therefore, clients SHOULD NOT send a token received in a NEW_TOKEN frame from
+one server address in an Initial packet that is sent to a different server
+address. As strict equality might reduce the utility of this mechanism, clients
+MAY employ heuristics that result in different server addresses being treated
+as equivalent, such as treating addresses with a shared prefix of sufficient
+length as being functionally equivalent (for instance, /24 in IPv4 or /56 in
+IPv6). In addition, clients SHOULD treat a preferred address that is
+successfully validated as equivalent to the address on which the connection was
+made; see {{preferred-address}}.
+
+Sending a Retry packet ({{packet-retry}}) offers a server the option to change
+the Token field. After sending a Retry, the server can also control the
+Destination Connection ID field of subsequent Initial packets from the client.
+This also might allow indirect control over the encrypted content of Initial
+packets. However, the exchange of a Retry packet validates the server's

> The design of QUIC relies on endpoints retaining a stable address for the duration of the handshake. An endpoint MUST NOT initiate connection migration before the handshake is confirmed, as defined in section 4.1.2 of [QUIC-TLS].

Not sure if that is enough, as [this](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-9-2) is not directly a requirement, but more of an assumption.

> +the Token field. After sending a Retry, the server can also control the
+Destination Connection ID field of subsequent Initial packets from the client.
+This also might allow indirect control over the encrypted content of Initial
+packets. However, the exchange of a Retry packet validates the server's
+address, thereby preventing the use of subsequent Initial packets for request
+forgery.
+
+
+### Request Forgery with Preferred Addresses
+
+Servers can specify a preferred address, which clients then migrate to after
+confirming the handshake; see {{preferred-address}}. The Destination Connection
+ID field of packets that the client sends to a preferred address can be used
+for request forgery.
+
+A client MUST NOT send non-probing frames to a preferred address prior to

I think that repetition will do.

> +
+This document does not offer any additional countermeasures that are specific
+to use of preferred addresses and can be implemented by endpoints. The generic
+measures described in {{forgery-generic}} could be used as further mitigation.
+
+
+### Request Forgery with Spoofed Migration
+
+Clients are able to present a spoofed source address as part of an apparent
+connection migration to cause a server to send datagrams to that address.
+
+The Destination Connection ID field in any packets that a server subsequently
+sends to this spoofed address can be used for request forgery.
+
+A server that only sends probing packets ({{probing}}) to an address prior to
+address validation provides an attacker with only limited control over the

I considered it, but thought that the generic text was enough.  Note also that there is no guarantee that PATH_RESPONSE is sent on the same path.

> +Services offered over loopback interfaces (that is, the IPv6 address ::1 or the
+IPv4 address 127.0.0.1) often lack proper authentication. Endpoints MAY prevent
+connection attempts or migration to a loopback address. Endpoints SHOULD NOT
+allow connections or migration to a loopback address if the same service was
+previously available at a different interface or if the address was provided by
+a service at a non-loopback address. Endpoints that depend on these
+capabilities could offer an option to disable these protections.
+
+Similarly, endpoints could regard a change in address to link-local address
+{{?RFC4291}} or an address in a private use range {{?RFC1918}} from a global,
+unique-local {{?RFC4193}}, or non-private address as a potential attempt at
+request forgery. Endpoints could refuse to use these addresses entirely, but
+that carries a significant risk of interfering with legitimate uses. Endpoints
+SHOULD NOT refuse to use an address unless they have specific knowledge about
+the network indicating that sending datagrams to unvalidated addresses in a
+given range is not safe.

Yes, it acknowledges the problem, but this explicitly does not fix it (I don't know how you might read otherwise).  The SHOULD NOT exists to prohibit reactionary solutions that don't work.

Do you have a solution you would prefer?

> +what packets the peer sends and where these packets are sent. If an attacker
+can target a vulnerable service with a controlled payload, that service might
+perform actions that are attributed to the attacker's peer, but decided by the
+attacker.
+
+For example, cross-site request forgery {{?CSRF=DOI.10.1145/1455770.1455782}}
+exploits on the Web cause a client to issue requests that include authorization
+cookies {{?COOKIE=RFC6265}}, allowing one site access to information and
+actions that are intended to be restricted to a different site.
+
+As QUIC runs over UDP, the primary attack modality of concern is one where an
+attacker can select the address to which its peer sends UDP datagrams and can
+control some of the unprotected content of those packets. As much of the data
+sent by QUIC endpoints is protected, this includes control over ciphertext. An
+attack is successful if an attacker can cause a peer to send a UDP datagram to
+a host that will perform some action based on content in the datagram.

I don't have anything concrete.  Any example would be hard to describe with anything other than "this person/organization did something really unwise".  Given the absence of a news-worthy example that would be easy to reference, this is really just a request to search for someone to shame.

> +frames in packets prior to completing address validation. Note that this does
+not prevent an attacker from using the Destination Connection ID field for an
+attack.
+
+Endpoints are not expected to have specific information about the location of
+servers that could be vulnerable targets of a request forgery attack. However,
+it might be possible over time to identify specific UDP ports that are common
+targets of attacks or particular patterns in datagrams that are used for
+attacks. Endpoints MAY choose to avoid sending datagrams to these ports or not
+send datagrams that match these patterns prior to validating the destination
+address. Endpoints MAY retire connection IDs containing patterns known to be
+problematic without using them.
+
+Note:
+
+: Modifying endpoints to apply these protections is more efficient than

I must be very confused, but your round trip point seems wrong.  The key point here is that the round trip is not safe, so any time you attempt that you are exposing services to a potential attack.  The point of this text is to describe heuristics that *might* block attacks without sending a packet at all.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3996#discussion_r479839185