Under certain conditions, an attacker might receive SETs for subjects without being authorized to access information on these subjects. We give the details in the following.
Please note that this issue is part of the ongoing formal security analysis of the SSF specification. We already created a formal model of the specification, identified and formalized security properties, and described the assumptions (as also agreed upon with the Working Group) upon which the analysis is based here: https://github.com/openid/sharedsignals/files/15014966/2024-04-09_WP4.1a-Report.pdf
Setting
We start with a brief summary of the relevant assumptions from our report.
There is no Receiver authentication, as the SSF specification has no requirements on authentication of the Receiver at the Transmitter.
Transmitters identify Receivers by dynamically created nonces which the Transmitter issues during configuration discovery. More precisely, we assume that the Transmitter provides different endpoints for each configuration discovery request, with the URLs containing a unique part u, which is also used as the audience value for this Receiver. However, this issue also applies more generally to cases in which the identifier is chosen by the Transmitter for the Receiver out-of-band and transmitted from the Receiver to the Transmitter in a way that the parties agreed upon.
Subjects are added to a stream based on authorization tokens contained in the request to the add subject endpoint. We assume that these tokens are pre-shared and that receivers select the appropriate token to include in a request based on the service, i.e., the endpoint to which the request is sent.
Detailed Description
The attacker receives a SET with information on a subject that the attacker is not authorized to receive (i.e., breaking the authorization property described in Section 4.4 of our report). This happens by a mix-up in which the attacker acts as a Receiver towards an honest Transmitter t and as a Transmitter towards an honest Receiver r.
At first glance, it might seem unreasonable to expect security guarantees if a Receiver is interacting with a malicious Transmitter. However, even in this case, the malicious Transmitter should not be able to compromise the security guarantees between the Receiver and any other Transmitter that the Receiver is using.
Let iss_t be an issuer identifier of the Transmitter t and iss_att an issuer identifier of the attacker. Furthermore, let at_subID be an access token that the Receiver r shares with the Transmitter t, and which authorizes access to the subject subID, i.e., upon receiving this access token at the add subject endpoint, the Transmitter would add subID to the corresponding stream. Furthermore, we assume that only r is authorized to access information about subID.
In a nutshell, the attacker tricks the honest Receiver r to add the subject subID to a stream of the attacker at the honest Transmitter t. This is shown in the following diagram (with a detailed description following the diagram):
Configuration Discovery
The attacker sends a configuration discovery request to t (Step 1 of the diagram) and obtains the transmitter configuration metadata, including the configuration endpoint and the add subject endpoint (Step 2). As noted above, t chooses a fresh identifier u_att (for identifying the Receiver) that is part of the endpoints. The retrieval of the JWKS is omitted from the diagram.
The Receiver r sends a configuration discovery request to the attacker att (Step 3) and obtains the transmitter configuration metadata (Step 4). Here, the attacker provides the add subject endpoint of t and re-uses the identifier that it received in Step 2 . The retrieval of the JWKS is again omitted.
Stream Creation
The attacker creates a stream at t, which responds with the stream id s_att (Steps 5 and 6). Details related to the delivery method are omitted as they do not affect the outcome.
The Receiver r creates a stream at the attacker, and the attacker responds with the stream identifier that it obtained from the honest Transmitter (Steps 7 and 8). Details related to the delivery method are again omitted.
Adding Subjects to Stream
The Receiver r selects the add subject endpoint from the configuration metadata of the attacker, which is the endpoint of t. As previously noted, we assume that the Receiver selects an access token based on this endpoint, in this case, the token at_subID, and the subject identifier subID. When receiving the request, t adds the subject id to the stream s_att . As a result, the attacker can get a SET with this subject id without being authorized to receive information about this subject (not shown in the diagram).
Possible Fixes
One possible fix is to ensure that the create stream and the add subject requests come from the same party, e.g., via proof-of-possession of some key pair or via a suitable authentication mechanism (i.e., the Receiver would need to authenticate both at the configuration endpoint for stream creation and at the add subject endpoint). Another potential fix is to require that Receivers choose subjects (for the add subject request) based on the issuer identifier.
Under certain conditions, an attacker might receive SETs for subjects without being authorized to access information on these subjects. We give the details in the following.
Please note that this issue is part of the ongoing formal security analysis of the SSF specification. We already created a formal model of the specification, identified and formalized security properties, and described the assumptions (as also agreed upon with the Working Group) upon which the analysis is based here: https://github.com/openid/sharedsignals/files/15014966/2024-04-09_WP4.1a-Report.pdf
Setting
We start with a brief summary of the relevant assumptions from our report.
u, which is also used as the audience value for this Receiver. However, this issue also applies more generally to cases in which the identifier is chosen by the Transmitter for the Receiver out-of-band and transmitted from the Receiver to the Transmitter in a way that the parties agreed upon.Detailed Description
The attacker receives a SET with information on a subject that the attacker is not authorized to receive (i.e., breaking the authorization property described in Section 4.4 of our report). This happens by a mix-up in which the attacker acts as a Receiver towards an honest Transmitter
tand as a Transmitter towards an honest Receiverr. At first glance, it might seem unreasonable to expect security guarantees if a Receiver is interacting with a malicious Transmitter. However, even in this case, the malicious Transmitter should not be able to compromise the security guarantees between the Receiver and any other Transmitter that the Receiver is using. Letiss_tbe an issuer identifier of the Transmittertandiss_attan issuer identifier of the attacker. Furthermore, letat_subIDbe an access token that the Receiverrshares with the Transmittert, and which authorizes access to the subjectsubID, i.e., upon receiving this access token at the add subject endpoint, the Transmitter would addsubIDto the corresponding stream. Furthermore, we assume that onlyris authorized to access information aboutsubID. In a nutshell, the attacker tricks the honest Receiverrto add the subjectsubIDto a stream of the attacker at the honest Transmittert. This is shown in the following diagram (with a detailed description following the diagram):t(Step 1 of the diagram) and obtains the transmitter configuration metadata, including the configuration endpoint and the add subject endpoint (Step 2). As noted above,tchooses a fresh identifieru_att(for identifying the Receiver) that is part of the endpoints. The retrieval of the JWKS is omitted from the diagram.rsends a configuration discovery request to the attackeratt(Step 3) and obtains the transmitter configuration metadata (Step 4). Here, the attacker provides the add subject endpoint oftand re-uses the identifier that it received in Step 2 . The retrieval of the JWKS is again omitted.t, which responds with the stream ids_att(Steps 5 and 6). Details related to the delivery method are omitted as they do not affect the outcome.rcreates a stream at the attacker, and the attacker responds with the stream identifier that it obtained from the honest Transmitter (Steps 7 and 8). Details related to the delivery method are again omitted.rselects the add subject endpoint from the configuration metadata of the attacker, which is the endpoint oft. As previously noted, we assume that the Receiver selects an access token based on this endpoint, in this case, the tokenat_subID, and the subject identifiersubID. When receiving the request,tadds the subject id to the streams_att. As a result, the attacker can get a SET with this subject id without being authorized to receive information about this subject (not shown in the diagram).Possible Fixes
One possible fix is to ensure that the create stream and the add subject requests come from the same party, e.g., via proof-of-possession of some key pair or via a suitable authentication mechanism (i.e., the Receiver would need to authenticate both at the configuration endpoint for stream creation and at the add subject endpoint). Another potential fix is to require that Receivers choose subjects (for the add subject request) based on the issuer identifier.