This vulnerability has been fixed in Bridgy Fed version 20241209t222928, deployed at 2024-12-09 22:32 UTC. Huge thanks to @Tamschi and @warriordog for reporting and helping debug and mitigate it!

Summary

Bridgy Fed allows bridged actors to submit and persist activities with arbitrary @ids. This is exploitable with two distinct effects:

• By racing or predicting an activity @id used by a bridged user, an actor can prevent the bridging of specific activities by some other actors. (DoS)
• By submitting a post with an activity @id belonging to another user's post (either unbridged or winning the race), an actor can mistarget later object references by bridged users to the post to be interpreted as to the manipulated post. This affects likes, boosts and replies.

Details

When Bridgy Fed receives a new activity through its ActivityPub inbox, it doesn't check whether the signing actor is allowed to create activities on the host specified by the received activity id:

• bridgy-fed/protocol.py

  Line 909 in b6ae184

  obj = Object.get_or_create(id, authed_as=actor, **orig.to_dict())

  
  (no domain authorisation above this call)

• bridgy-fed/models.py

  Lines 1074 to 1076 in b6ae184

  	else:
  	obj = Object(id=id)
  	obj.new = True

  
  (no domain authorisation on this path)

PoC

• Given ActivityPub users A, B and C, where
• B and C are bridged but A is not and
• A and B are located on distinct hosts (for example distinct subdomains):

1. Create a new post a as A. (Bridgy Fed does not usually receive this post even before filters.)
2. Create a new post b as B but with a's @id. (Bridgy Fed receives and persists this post.)
3. Boost a as C. C will appear to have boosted b on remote networks.

Impact

Whether an actor is susceptible as DoS target depends on whether their activity @ids are predictable or can be raced.
An attacker may cause partial but persistent interruption of service targeting specific actors or ActivityPub instances.

More seriously, an attacker is able to misdirect bridged interactions on remote networks to a post that damages the reputation of actors whose interactions were misdirected. This can't easily be targeted individually, but it is possible to select for example a specific actor's audience as target by copying their posts' @ids. The manipulation can't easily be proven by the affected users in many cases as likes and boosts normally don't have their IDs exposed to observers.
Mitigating any such exploit would require active cleanup of misdirected bridge activities on remote networks.

Context

This was essentially pointed out by @warriordog here: #1570 (comment)