Leak of past and future room recordings

[defnull]

Greenlight (and probably most of the other frond-ends for BBB) uses a fixed meetingID per room. This results in predictable internalMeetingID and recordID values (sha256(meetingID) + '-' + epoch_seconds). Any user that joined the room at least once, or got a presentation link, knows the static part of the recordID and can try to guess the correct timestamp to find past or future recordings. Probing presentation links does not require a login and is not rate-limited. Knowing the rough starting time of a meeting is enough to get access rather quickly.

For the user, it may not be obvious that keeping a recording on "not listed" does not actually make it private. If a room is used for interviews or other sensible topics, this may lead to serious data breaches. This risk is not reflected enough by the UI I think.

[farhatahmad]

Hi @defnull

Although it the id has been fixed in 2.5.3 (See #1242), this will only apply to newly created rooms. Off the top of my head, the only way to fix the issue you're describing above is to generate a new id for every room and somehow update the recordings of that room to match the new id

[defnull]

Not an easy fix, but what about: Generate a new random meetingID each time a meeting is (re-)created, so a room will have a new and unpredictable internalMeetingID (and thus recordID) for each new session. Attach the Greenlight room name to meetings (and recordings) via some new metadata flag (would be useful for debugging anyway). The recordings importer can then match recordings with Greenlight rooms based on this metadata flag of the meetingID.

[farhatahmad]

Making a change like that probably isn't the ideal way to go. It would require tons of changes to the recording part of a BigBlueButton server and to the BigBlueButton API.

This would be more an issue for BigBlueButton then Greenlight since BigBlueButton generates the recordID. Either way, brute forcing a recording ID should be easily noticeable since it would require a ton of guesses to get 1 correct.

[ichdasich]

@defnull If you are looking for a temp-fix, take a look at #1402 / https://github.com/ichdasich/bbb-rec-perm / https://github.com/ichdasich/greenlight/tree/rec_restrictions

[defnull]

Making a change like that probably isn't the ideal way to go. It would require tons of changes to the recording part of a BigBlueButton server and to the BigBlueButton API.

The change I proposed would not require any changes on BBB side, only in Greenlight. The idea was: Greenlight should create a new BBB meeting (with a new meetingID) every time a Greenlight room is started, instead of re-using the old meetingID. Greenlight can use meeting/recording metadata instead of the meetingID to track which meeting/recording belongs to which Greenlight room, or just remember which meetingIDs were used for a room.

The issue could also be fixed in BBB directly by randomizing recordID, sure. But I think it is actually easier to fix in Greenlight, and also more appropriate. BBB does not have a concept of persistent 'rooms'. BBB meetings are volatile. Re-creating a meeting with the same (external) meetingID has no benefits in BBB and is not required or recommended. Greenlight does that, which causes this issue.

But you guys speak to each other, I suppose. If you find that fixing this directly in BBB is doable, than that would be great.

[farhatahmad]

The idea was: Greenlight should create a new BBB meeting (with a new meetingID) every time a Greenlight room is started, instead of re-using the old meetingID.

This presents its own challenges when it comes to get the recordings for a room. Greenlight does not store any recordings in its database, it simply pulls them from the BigBlueButton server using the API. Since the API doesn't support getting a recording based on it's metadata, we would need to pull all recordings and then filter through them individually to find which recordings match the room we're currently viewing. The other option you mentioned was multiple meetingIDs. The issue there is now you would have to do an insane amount of getRecordings calls instead (1 for each time the room has been started). This makes views like Server Recordings and All Recordings basically impossible to use.

Re-creating a meeting with the same (external) meetingID has no benefits in BBB and is not required or recommended.

It's actually (as far as I know) the way that every front-end does it.

[ichdasich]

Actually, the more you talk about it, the more this sounds like a BBB issue. It should not be too difficult for BBB to randomize the recording URL and store that in the recording's metadata (and return the recording URL along with all other metadata). Contrary to randomizing the whole meeting ID this should be a (relatively) simple change (apart from the question of how to upgrade older setups).

[defnull]

Since the API doesn't support getting a recording based on it's metadata

Huh? https://docs.bigbluebutton.org/dev/api.html#getrecordings supports getting recordings based on metadata just fine, if I read that correctly? Greenlight could store the room ID in meeting metadata and then query BBB for all recordings with that medatata attribute. It is all there.

[farhatahmad]

Ah my mistake. Either way, this seems like it would be tons of work in Greenlight when it can be easily (I think) fixed in BigBlueButton. The only change that would need to be done is to change the random portion of the recordID to use a better random number generator instead of a hash based on the time. This will also fix the issue for all front-end applications and not just one

[ichdasich]

Agreed; And such a change should also be easily backward compatible (only generate new form of record IDs for new meetings).

For the record: It is not a hash of a timestamp, it is actually the unix timestamp of the meetings' starttime ;-)

[farhatahmad]

Going to close this in favor of bigbluebutton/bigbluebutton#9443