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

[julian@activitypub.space]

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. @alice@example.org is allowed to federate Delete(Note) on @bob@example.org'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?

I responded that FEP fe34 allows for this behaviour because we do not have ready access to an instance's admin or moderator list. By conducting same-origin checks and allowing Update and Delete through for same-origin (but different identifier), we allow for moderators to federate their actions across instances.

Their response:

> I respectfully disagree that FEP-fe34 permits this behavior. Below are direct quotes from the specification that contradict your assessment.
>
> 1. ActivityPub spec (quoted in FEP-fe34 Rationale, Section 7.3 Update Activity):
>
> ▎ "The receiving server MUST take care to be sure that the Update is authorized to modify its object. At minimum, this may be done by ensuring that the Update and its object are of same origin."
>
> Note: "at minimum" means same-origin is the floor, not the ceiling. Authorization must still be verified.
>2. FEP-fe34 — Authorization > Ownership:
>
> ▎ "The actor that creates an object MUST be its owner."
> ▎ "The owner of an object is permitted to modify and delete it."
> ▎ "Update and Delete activities, and objects indicated by their object property are expected to have the same owner."
>
> "Same owner" means the same specific actor — not any actor on the same domain.

I responded back with the following:

> "The actor that creates an object MUST be its owner."
>
>
> Correct, the creator must be an owner, no impersonation allowed.
>
>
> "The owner of an object is permitted to modify and delete it."
>
>
> A strict reading of this does not preclude the ability of a same-origin moderator to modify and delete the object. This is my argument.
>
>
> "Update and Delete activities, and objects indicated by their object property are expected to have the same owner."
>
>
> Again, "expected to" does not rise to the level of MUST.
>
> 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.

So we are at an impasse as to whether my strict reading of the FEP is adherent to the spirit of the FEP itself. Here's where you come in... do you agree with me, or the reporter?

Directly tagging @silverpill@mitra.social (as FEP author), @trwnh@mastodon.social and @evan@cosocial.ca (both subject matter experts) for their thoughts.

[nutomic@lemmy.ml]

We also got the same type of vulnerability reports. Good that you bring it up, because I wasnt aware of the FEP.

To answer your question we can look at it the other way. Imagine we implement a way to federate admin/moderator status and then check it for every incoming mod action. First of all we get problems with older platforms which dont implement this feature yet, it means all their mod actions will be rejected and we end up with spam. Or we add a way to bypass the check, then the whole security feature becomes pointless.

Even if we assume that all platforms correctly federate the admin/mod status, there would still be problems. Federation is not perfect, sometimes things get lost. Or someone gets appointed as admin and immediately removes some spam. At this point the admin status is not federated yet (if its part of the user profile and only updated every 24h). Then again valid mod actions are rejected and we end up with spam that is not deleted.

On the other hand, whats exactly is the exploit here? Some platform lets a normal user (no admin/mod rights) send Update or Delete activites for another user on the same instance. That is clearly not our problem, but its a problem of the remote platform which allows such actions. Besides it cannot affect users from other instances so the impact would be very limited.

Overall, adding such stricter checks would create more problems than it solves.

[thisismissem@activitypub.space]

Well, yeah, that's why I linked what T&S is doing here to fix the moderator use case. At present I don't know of anyone sending cross-actor delete/update actions, so we'd be adding capability with the moderatedBy

[julian@activitypub.space]

@thisismissem hmm, I believe Lemmy and Piefed send cross actor Deletes, but they might be Announces by the group actor.

They (and I) don't use moderatedBy but rather the group actor's attributedTo

Just want to make sure you're aware of that existing prior art.

[julian@activitypub.space]

@nutomic@lemmy.ml @rimu@piefed.social @bent0_b0x@norden.social — do y'all send Delete activities with the moderator actor?

(Announce wrapping aside.)

[rimu@piefed.social]

Yes.

This is easy in FEP 1b12-land because each community has a list of moderators so receiving instances know who to allow.

Getting a list of instance admins requires calling the Lemmy API, unfortunately. So PieFed has a cron job that does that once per day for all instances. Admins rarely change.

[julian@activitypub.space]

> @rimu@piefed.social said:
>
> Getting a list of instance admins requires calling the Lemmy API, unfortunately.

Wait, why don't we write a mini FEP to extend this? attributedTo on the instance/application actor?

• https://codeberg.org/fediverse/fep/src/branch/main/fep/2677/fep-2677.md
• extending 1b12

[rimu@piefed.social]

That sounds fine to me.

On communities the moderators are just an array of strings which are the activitypub actor IDs of the mods. I think NodeBB has an array of actor objects though?

Anyway whatever it is, consistency with how the communities do it would be nice.

[julian@activitypub.space]

> @rimu@piefed.social said:
>
> I think NodeBB has an array of actor objects though

Is this causing problems for you? I can send just the IDs instead.

[rimu@piefed.social]

It's fine, I've already adjusted the code at my end. I don't know about Lemmy though.

[nutomic@lemmy.ml]

Lemmy doesnt even federate admin status in any way, instead we trust that actions which are coming from the same instance as the community or post are valid. So essentially origin-based security model.

[nutomic@lemmy.ml]

Looks like this, only IDs: https://github.com/LemmyNet/lemmy/blob/main/crates/apub/apub/assets/lemmy/collections/group_moderators.json

[julian@activitypub.space]

Right, that's the "Group Moderation" section of FEP 1b12, right?

It may be a good idea to extend this concept to the instance/application actor as well. There's no urgent need to implement and consume, but it would be fairly simple thing to serve on our respective softwares I think.

[nutomic@lemmy.ml]

Yes exactly that FEP. Federating admin status would make sense for informational purposes, but rejecting mod actions based on that could cause problems as I mentioned in my previous comment.

[julian@activitypub.space]

> @nutomic@lemmy.ml said:
>
> but rejecting mod actions based on that could cause problems as I mentioned in my previous comment.

So to confirm then, you serve the moderator collection but you don't use it to determine whether an actor is able to modify/delete content on that instance, is that right?

Curious to know what those problems are.

[nutomic@lemmy.ml]

We use the moderator collection. But if that fails we check if the mod is from the same instance as the community or the post/comment being removed. If thats true we also allow the action.