Question re: Origin Based Security Model (FEP-fe34)

I received a security vulnerability report regarding NodeBB's handling of Update and Delete activities.

tl;dr

  • NodeBB implementes FEP fe34, and treats Update and Delete activities as valid if the activity's actor and the object's attributedTo differ but the origins are identical.
  • e.g. @[email protected] is allowed to federate Delete(Note) on @[email protected]'s Note.
  • The origin-based security model allows for moderator-style actions (third-party post editing and deletions) in the absence of explicit moderator claims.
  • The reporter disagrees that this should be allowed.

Are they right? [...]

https://activitypub.space/post/1919

Question re: Origin Based Security Model (FEP-fe34)

I received a security vulnerability report regarding NodeBB's handling of Update and Delete activities. tl;dr NodeBB implementes FEP fe34, and treats Update...

⁂ ActivityPub.Space

I agree out of principle that the security implications exist, but if you follow through with the exploit, it requires a non-compliant server to allow users to publish Update and Delete for other users on the same instance, and even then the exposure is limited to users of that origin only (e.g. your server cannot arbitrarily delete my posts). This is the foundation of the Origin-based security model.

Correct. FEP-fe34 is based on the assumption that originating servers enforce boundaries between actors. This is stated in the section "Assumptions":

The origin-based security model is designed for use in a network where a server is resposible for enforcing security boundaries between the hosted actors. Servers that publish objects without validation are not supported.

In some cases, FEP-fe34 recommends same-actor policy as an additional protection against implementation bugs and against implementations that don't enforce actor boundaries on purpose. Update/Delete authorization is one of those cases (admittedly, the wording is a bit confusing in that paragraph...)

Is the assumption on which FEP-fe34 is based valid?

Of course, it is primarily a philosophical question. Who should be responsible for enforcing boundaries between actors hosted on the same server, the sender or the recipient? In my opinion, the answer is clear: the sender should be responsible.

As far as I know, the majority of existing implementations do enforce boundaries between actors. I am not aware of any implementation that doesn't do that.

Enforcement of boundaries is challenge for generic ActivityPub servers, but it's not insurmountable.

fep/fep/fc48/fep-fc48.md at main

fep - Fediverse Enhancement Proposals

Codeberg.org

@[email protected] said:

In some cases, FEP-fe34 recommends same-actor policy as an additional protection against implementation bugs and against implementations that don't enforce actor boundaries on purpose. Update/Delete authorization is one of those cases (admittedly, the wording is a bit confusing in that paragraph...)

Does this mean NodeBB is wrong is allowing different actors on the same origin to publish Updates and Deletes? I do not know of a way to reconcile this with the ability to have moderators carry out their actions.

⁂ ActivityPub.Space

⁂ ActivityPub.Space

No, it's not wrong.

I think the good of group moderation currently outweighs the theoretical bad of same-origin impersonation.

@julian I've done a review on FEP-fe34 and here's a more nuanced answer.

The same-origin assumption is necessary for authentication, because it is not possible to not trust the server of origin.

But it is not necessary for authorization. It is desirable, because that makes authorization procedures aligned with authentication procedures. But we can shift the burden of permission checks to the recipient.

We might even have to do this, if we discover that servers accepting arbitrary payloads (C2S, FEP-ae97) can't reliably enforce the isolation of actors.

But for the time being, you can accept same-origin admin deletions.