Not that I use Jitsi, but I suddenly feel more embarrassed about my number of open tabs. Some other exploit could have silently been launched long ago.
Maybe my Mac is set to be paranoid, but can you share video without being asked to give the mic and camera permission to operate? I chat with jitsi all the time and have to give jitsi explicit permission to use the mic/camera each time.
This is clearly a major vulnerability and not a feature, it's a permissions/credentials hijack.
The user has given permission for audio and videos recording to the jitsi domain during a previous meeting, and the domain is using those permissions to start an unsolicited meeting initiated by a 3rd party, who is given access to the video and audio of the victim.
config (which implicitly decides weather or not a prejoin dialog is shown)
but this makes me wonder
1. why can you set that config in a URL? Allowing users to set it for them-self seems fine, but allowing rooms or URL to use it seems ... off.
2. how many other sites have this attack surface (e.g. MS Teams) just more obscure
3. actually the moment the attacker controls JS probably *all* other video conference systems have the feature, through potentially needing a lot of additional work. In which case maybe just being straightforward and open about it is fine? But the cost of such an attack is just a very bit too low compared to other conference systems.
Jitsi dev here. We are currently revisiting this. It exists because in cases such as when Jitsi Meet is being embdeed there are pre-join pages provided externally by the "host" site. We will be limiting how this can be used going forward.
I mean, I get the idea that you want to skip the whole configure step for webcam/mic if it's embedded somewhere, but I still expect cam/mic to be muted on join. Isn't that what most conferencing tools do, no matter whether you get a config dialog after clicking the join link...
16 comments
[ 2.8 ms ] story [ 41.5 ms ] thread(As in during the pandemic -- long ago in vuln times.)
I am willing to discuss it, off the record, if someone provides their signal information.
The user has given permission for audio and videos recording to the jitsi domain during a previous meeting, and the domain is using those permissions to start an unsolicited meeting initiated by a 3rd party, who is given access to the video and audio of the victim.
config.prejoinConfig.enabled=false
config (which implicitly decides weather or not a prejoin dialog is shown)
but this makes me wonder
1. why can you set that config in a URL? Allowing users to set it for them-self seems fine, but allowing rooms or URL to use it seems ... off.
2. how many other sites have this attack surface (e.g. MS Teams) just more obscure
3. actually the moment the attacker controls JS probably *all* other video conference systems have the feature, through potentially needing a lot of additional work. In which case maybe just being straightforward and open about it is fine? But the cost of such an attack is just a very bit too low compared to other conference systems.