-
Task
-
Resolution: Won't Do
-
Undefined
-
None
-
None
-
None
-
False
-
None
-
False
-
Testable
-
?
-
RHELBU-2233 - Cockpit security enhancements
-
?
-
?
-
-
From https://github.com/cockpit-project/cockpit/pull/19132, spotted by allison.karlitskaya:
| The shell doesn't currently seem to verify that a non-"open" message (control or data) is coming from the frame that "owns" the open channel. That means that if we can guess the names of channels in other frames (pretty easy considering they're sequentially numbered) we can inject data into them. If the channel we choose to hijack is an open dbus channel, for example, then we can do practically anything with that... |
This is a special case of https://issues.redhat.com/browse/COCKPIT-945 . Once we figured out how a frame can authenticate to the shell (and bridge), this should fall out automatically. But let's make sure that this is the case afterwards.
With the updated plan this becomes relevant again. The shell needs to check the origin of a channel data/control message.