-
Notifications
You must be signed in to change notification settings - Fork 1
Potential Amplification Attack or DDoS #39
Comments
Are you referring to the |
Hi @kevinmkane, This comes up in the document in lots of places. Samples of the required URLs that point to remote services: Section 6.3: required": ["url", "hash"] followed by the required URL. Section 7.3: The examples use "self:" for the URL method to the credential information, but I see nothing indicating that it cannot be "https://", "http://", etc. Section 8.2.1: Permits an optional URL to a remote service for specifying assertions. This is demonstrated in the example in section 9.2. Section 10.3.2.7: Explicitly permits URLs that point to remote services. Section 14.6.3: Talks about how to get assertion data from remote services via URL. The exception in 2(a) says it must be local -- unless it is defined as cloud-data in 2(a)(i) or hashed data in 2(a)(ii). Section 14.6.4: Covers remote URL access for external hashes. Section 14.7: Permits remote access to assertions via URL. (See the paragraph that begins with "Resolve the URI reference in the url field to obtain the ingredient claim’s manifest.") Section 17.3.1.1: Permits remote access via URL to additional information from a remote provider. Section 17.5, 17.5.1: Permits remote access to the hash via URL. (This brings up another interesting problem... Can a hostile attacker specify a service that always provides the correct hash?) Section 17.6.1: I love this part because it is ripe for abuse: "uri, ; (optional) a file or http(s) URL to where the bytes that are being hashed lived. This is useful for cases where the data lives in a different file chunk or side-car than the claim." Section 17.7 and 17.7.1: Soft bindings can use remote URLs. (Same issue as 17.6.1.) This even includes an example with a remote URL: Section 17.8 and 17.8.1: "Cloud Data" -- yeah, all remote URLs. (Surprisingly, 17.10 is safe because the URL must be "self#". But I think this is more safe-by-coincidence than intent. In contrast, 17.11.6 is explicit that the URLs must be local.) Section 17.15.2: The example shows URLs to reference materials on remote services. In each of these remote URL instances: This is fine, until someone creates a validation tool that checks every URL, resulting in the amplification attack. If this validation becomes a wide-spread practice, then it scales from amplification attack to DDoS. |
Thanks @hackerfactor - a number of these were restricted to JUMBF URIs only in the final 1.0 specification through the use of hashed-uris and jumbf-uris 6.3 - we no longer support external assertions or claims 10.3.2.7 is a feature of BMFF, not anything C2PA-specific 14.6.3 and 14.6.4 are both noted as being optional ("not part of standard validation") for the reasons that you raise concerning their presence. |
The metadata structure permits defining URLs that are required for validation. These URLs could be used to retrieve a certificate for validation or some other required information.
The result:
The text was updated successfully, but these errors were encountered: