#79 finding 6 (MEDIUM): raise require_room_authority bar + re-check authority at commit #86

New issue

Closed

opened 2026-07-11 09:08:06 +00:00 by robocub · 1 comment

robocub commented

2026-07-11 09:08:06 +00:00

Collaborator

From the #79 review. Not fixed (design-sensitive — could affect legitimate moderators, so wants a deliberate decision).

evaluate_sender_authority treats sender power >= the room's state_default as authority. In a room whose owner legitimately lowered state_default (e.g. 0, letting members set topic/widgets) or raised users_default, any joined member satisfies this with NO real moderator role over m.room.power_levels.
Authority is a one-time probe snapshot: commit_link at approval time re-checks only bans, never re-reading PL/membership, so transient authority (temporary promotion then demotion/kick before approval) still spawns the bridge.

Fix (needs a call on the bar)

Require sender power >= the room's power_levels CHANGE power, or an explicit per-user users[] entry above users_default (not merely state_default). Re-run the room-authority probe inside commit_link before writing tenants.toml. Note two-sided auth still requires Discord Manage-Server approval, which bounds the blast radius — hence MEDIUM.

Severity MEDIUM.

From the #79 review. **Not fixed** (design-sensitive — could affect legitimate moderators, so wants a deliberate decision). - `evaluate_sender_authority` treats sender power >= the room's `state_default` as authority. In a room whose owner legitimately lowered `state_default` (e.g. 0, letting members set topic/widgets) or raised `users_default`, any joined member satisfies this with NO real moderator role over `m.room.power_levels`. - Authority is a one-time probe snapshot: `commit_link` at approval time re-checks only bans, never re-reading PL/membership, so transient authority (temporary promotion then demotion/kick before approval) still spawns the bridge. ## Fix (needs a call on the bar) Require sender power >= the room's power_levels CHANGE power, or an explicit per-user `users[]` entry above `users_default` (not merely `state_default`). Re-run the room-authority probe inside `commit_link` before writing tenants.toml. Note two-sided auth still requires Discord Manage-Server approval, which bounds the blast radius — hence MEDIUM. Severity MEDIUM.

robocub referenced this issue

2026-07-11 09:08:28 +00:00

Pre-launch adversarial security + abuse review of the open-registration surface (run on Fable) #79

robocub referenced this issue

2026-07-11 16:59:12 +00:00

Pre-launch adversarial security + abuse review of the open-registration surface (run on Fable) #79

robocub referenced this issue from a commit

2026-07-11 18:10:12 +00:00

fix(mgmt): #86 explicit-moderator authority bar + commit re-check

robocub referenced this issue from a commit

2026-07-11 18:12:59 +00:00

test(mgmt): offline approval tests skip the #86 live authority re-check

robocub referenced this issue from a commit

2026-07-11 18:20:41 +00:00

release: 0.3.0-alpha.20

robocub commented

2026-07-11 18:45:20 +00:00

Author

Collaborator

Fixed + shipped in v0.3.0-alpha.20 (master c92cfcc, deployed to prod 2026-07-11). require_room_authority now requires an explicit individual moderator grant — a users[sender] power-level entry above users_default AND >= 50 (Element Moderator) — instead of just sender_pl >= state_default. This closes both #79 finding-6 vectors: a lowered state_default or a raised users_default can no longer make every member look authorized. Authority is also re-checked at Discord-approval time (not just the probe) to catch a promote-then-demote TOCTOU. Verified: 7 unit tests (both attack vectors + floor + explicit-above-default), and the live mgmt_self_serve_link scenario PASS (negative users refused, @nvbtest_mgr with an explicit PL-50 grant over users_default 0 accepted). README + config.example updated.

Fixed + shipped in **v0.3.0-alpha.20** (master `c92cfcc`, deployed to prod 2026-07-11). `require_room_authority` now requires an **explicit individual moderator grant** — a `users[sender]` power-level entry above `users_default` AND >= 50 (Element Moderator) — instead of just `sender_pl >= state_default`. This closes both #79 finding-6 vectors: a lowered `state_default` or a raised `users_default` can no longer make every member look authorized. Authority is also re-checked at Discord-approval time (not just the probe) to catch a promote-then-demote TOCTOU. Verified: 7 unit tests (both attack vectors + floor + explicit-above-default), and the live `mgmt_self_serve_link` scenario PASS (negative users refused, @nvbtest_mgr with an explicit PL-50 grant over users_default 0 accepted). README + config.example updated.

robocub closed this issue

2026-07-11 18:45:20 +00:00

robocub referenced this issue from a commit

2026-07-11 23:15:42 +00:00

docs: retire the shipped roadmap, fix moderator-check wording, live policy links