Potential security vulnerability: Remote JSON-LD contexts may be used to bypass restrictions when arbitrary objects are allowed to be created

[silverpill]

In a hypothetical actor-based security model, servers would be hostile entities. But if objects have HTTP(S) IDs, server operators can do anything they want. The solution to this problem would look like FEP-ef61, but actor-based (FEP-ef61 is origin-based).

[trwnh]

@silverpill

I’d like to emphasize that this issue only affects “generic” ActivityPub servers

The issue affects anyone fetching key resources from any HTTP server and blindly assuming the keys are controlled by a single entity, instead of checking for an explicit controller and then checking for a backlink to the same key.

If I set up Apache or Nginx or Caddy to serve resources from a root folder, I can copy a file into that folder and serve it with the appropriate Content-Type header. Anyone can do this! It’s normal! This is how the vast majority of the web works! The issue is not on the publisher’s side, it’s on the naive consumer’s side (which is assuming certain claims regardless of what is actually being claimed).

@silverpill

Only few such implementations exist, and all of them are research projects.

It’s not just a “few” servers or “research projects”. There’s nothing special about an “ActivityPub server” – it’s just an HTTP server for handling fetch requests and also outbox/inbox submissions, plus an HTTP agent for posting activities to inboxes.

@silverpill

Actors sharing an origin are assumed to trust each other because all their interactions are mediated by a single piece of software operated by a single person or an organization.

“A single piece of software” can serve requests for multiple origins, just like it can serve requests for multiple actors. I’m using the same Nginx instance to serve 6 different domains right now, not all of which are mine.

The thing that makes the origin concept work is TLS. The certificate authenticates sessions with the host server on behalf of the entity who was issued the certificate. When you fetch something over HTTPS, you can authenticate with TLS that the response is from a Common Name (CN) which should match the origin. This does not mean that the origin/CN authored all resources! It’s the difference between an author and a publisher – and if you allow user-generated content, these are not always the same entity.

Also, “actors trust each other” is not a valid thing to assume, and it’s also not what you’re assuming – the real assumption being made (incorrectly) is not that “actors trust each other”, but that “keys represent the origin”, which they clearly do not. Under this assumption, if Alice and Bob are both users on a certain Origin, then you assume that A represents O, and you assume that A represents B. If you assumed this, and if your software supports multiple users, then each user should get their own origin. Otherwise, you might as well do away with the actor system entirely, because it’s unnecessary overhead if you only recognize origins.

@silverpill

A server might not be interested in impersonating actors. But it can do that, and other servers have no way of knowing how it works, because from their perspective, it is a black box that responds to requests. Therefore, a server is considered a trusted entity, and actors are not considered to be autonomous.

A “server” as described here is not the same as an origin. The “black box that responds to requests” is actually the software running on the machine assigned the IP address that the DNS record specifies (and listening to a certain port, by default port 443). Again, this is not something that should factor into your trust considerations – it is a trust consideration for the person who controls the DNS domain to only create DNS records pointing to entities that they trust. Your “black box” boundary should be the HTTPS identifier and the TLS certificate, and you have no idea which software is handling your request; you only verify that the response is authenticated for the authority component of the HTTPS identifier. To verify the resource for the attributed entity, you can use an associated key to create a signed proof for the appropriate purpose (authentication for verifying identity, or assertionMethod to make claims).

@silverpill

Given these assumptions, any object served at origin is valid (the section Fetching from an origin). This includes public keys.

Again, the key resource being “valid” does not mean that it represents the origin. The key explicitly tells you who the controller is. If you establish a bidirectional link, then you can associate the key and the controller as equivalent for a specific purpose. Don’t assume the controller is always the origin. The origin can host someone else’s keys.

@silverpill

if objects have HTTP(S) IDs, server operators can do anything they want

The controller of the HTTPS authority component (origin) implicitly accepts this when they delegate responsibility for responses to the “server operator”. Actually, there are multiple trust decisions happening:

• The DNS registrar is trusted by the entity registering the domain.
• The registrant of a DNS domain can grant controllership of their account with the registrar to someone else they trust.
• The registrant of a DNS domain trusts authoritative DNS name servers.
• Authoritative name servers return trusted records pointing to trusted entities, like an A/AAAA record pointing to a trusted IP address or a CNAME record pointing to a trusted DNS name.
• The IP address is assigned by a network operator to a machine they trust.
• The admin of the machine runs trusted software.
• The software uses TLS certificates which are provided or generated when a certificate authority can verify a challenge and thus trust you control the Common Name (CN).

And that’s not even the end of it – your HTTP request might be met with a redirection response, or it might pass through any number of proxies before a response is returned to you.

But none of these things are your responsibility. All of this is happening inside a black box as far as you are concerned. You only have an HTTPS identifier, and you establish a TLS session using that.

What matters at the end of the day is that you don’t make invalid assumptions about what’s happening inside that black box. Don’t assume that any/every resource on an origin is authored by that origin. Don’t assume that any/every key on an origin is controlled by that origin.

[silverpill]

I created an issue for tracking the problem identified by the OP: #12 - [FEP-fe34] JSON-LD consumers and public keys - silverpill/feps - Codeberg.org
We can continue there, because this thread is clearly not the place where a productive discussion can happen.