julianMay 20

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
Show threadjulianMay 20

My thoughts:

I don't necessarily think FEP fe34 is strict enough to be a guiding principle for security across federated instances. The reporter said:

"at minimum" means same-origin is the floor, not the ceiling.

... and he's right, there's more you should do to verify that only the owner or a designated moderator can update and delete an object.

However we don't have a widely-used ability to determine who the moderators or admins are for any given instance. Mastodon may have an endpoint (in their API), threadiverse software use their own (as directed by 1b12, and even then it's optional), other software  ?

So we fall back to origin-based security model and hand off the responsibility of determining who can and cannot alter somebody else's objects to the sending server.

That's a risk we take with this model. Not sure if there is more that can be done to tighten this up.

Show threadinfinite love ⴳMay 20

@julian You're making a very strong assumption that the remote server is necessarily checking for things it might not actually be checking for.

Neither the "instance" model nor the "same origin" model are enshrined in ActivityPub. This technically falls under "undefined behavior", because AP doesn't define an authorization model. (It suggests ("may") same origin, but that's about it. A lot of things are "at the receiving server's discretion".)

Show threadjulian

@[email protected] on the flip side, I could argue that if the sending server doesn't enforce boundaries between actors, then there's no need to enforce the boundary on my end.

For example, if the sending server is a federated wiki where anyone™️ can edit, then it would actually be incorrect for me to enforce a boundary.

May 20 at 11:49pmWeb
Show threadinfinite love ⴳMay 20

@julian The sending server might not have boundaries to enforce. Especially not along "same origin" lines. This requires agreement on what the authorization model is.

Say for example everyone gets a subdirectory that they "own" -- /~alice/ and /~bob/ have their spaces on the same origin. One authorization model is "anything within this container is authorized". If you don't recognize this, you can't detect that alice and bob have a boundary between them.

Show threadinfinite love ⴳMay 20
@julian Really, taking "same origin" to its logical conclusion would mean that every actor MUST have their own origin and therefore their own FQDN. It doesn't make sense for origins hosting user-generated content unless the UGC is very tightly controlled and sanitized. And even that's not a guarantee of safety.
Show threadinfinite love ⴳMay 20
@julian oh dear, these couple of mentions seem not to have made it across. do i need to also mention @technical-discussion too?
Show threadjulianMay 21
@[email protected] ...! That sounds like a bug. They all came in after you mentioned the category.