Potential Amplification Attack or DDoS

[hackerfactor]

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.

1. I can make the URLs point to any location on the internet, such as a target that I want to knock offline.
2. I can make a picture with hundreds of URLs that are required for validating the various claims. For this attack, the URLs do not need to point to a valid certificate or other information. They just need to point to the target for the attack. If the URLs are not available for authenticating the claims, then the validator will assume that the claim cannot be validated and it will move on to the next URL for validation. The validator may also retry or resubmit the URL request before giving up and moving on.
3. I can then submit the image with the hostile claims to a validation service and ask it to check if the claims are valid.

The result:

• If the validation service accesses each URL, then it becomes an amplification attack against the unsuspecting target.
• If the picture is submitted to lots of validation services, or becomes popular on large social media platforms like Reddit, news.ycombinator.com, Facebook, or Twitter, then the attack becomes a distributed denial of service attack (DDoS).

[kevinmkane]

Are you referring to the reference field of assertion-metadata-map in section 17.3?

[hackerfactor]

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: "url": 32("http://example.c2pa.org/media.mp4"),

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.

[lrosenthol]

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 7.3 - all credentials have to be embedded 8.2.1 & 9.2 & 14.7 - again, no external assertions or claims 17.3.1.1 isn't resolved - it's an identifier (technically an IRI vs. a URI)

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.