Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mute functionality still records and transmits audio to server (FreeSWITCH) #8951

Closed
guerby opened this issue Apr 1, 2020 · 44 comments
Closed

Comments

@guerby
Copy link

guerby commented Apr 1, 2020

Hi,

While playing around with settings following #8944 I found out that wether I mute the microphone in bigbluebutton interface or not it doesn't change the upload bandwidth from the client to the bbb server which stays around:

  • around 50 kbit/s with chrome 80
  • around 80 kbit/s with firefox 70

With microphone unmuted I added music near the microphone and upload bandwith didn't change so I think bbb HTML5 client is always sending some kind of audio stream to the bbb server.

Client and server: debian 10 amd64. Server running 2.2.0-5 installed with the provided script.

@paulmenzel
Copy link
Contributor

paulmenzel commented Apr 22, 2020

In newer Firefox versions (at least 75.0), with muted audio, there is also a blinking/pulsing red microphone in the URL bar. I guess, that indicates, that data is transmitted. (I think, this also causes the BBB tab to be using more energy as shown in about:performance.)

@ReimarBauer
Copy link

ReimarBauer commented Sep 8, 2020

Isn't that the same as every telephone connection where you decide to mute for a moment instead of calling again?

@fbettag
Copy link

fbettag commented Sep 8, 2020

Isn't that the same as every telephone connection where you decide to mute for a moment instead of calling again?

No, then your phone won’t transmit anything you speak.

This thing apparently is still transmitting.

@paulmenzel
Copy link
Contributor

paulmenzel commented Sep 8, 2020

Isn't that the same as every telephone connection where you decide to mute for a moment instead of calling again?

Interesting view point, but as the receiver also sees if somebody muted, it’s different from “old” telephone.

@psuet
Copy link

psuet commented Sep 8, 2020

This is a substantial problem for us. We have shut down all instances as a result of this. BBB is currently unusable because we would violate privacy laws (GDPR etc)

@matiasilva
Copy link
Collaborator

matiasilva commented Sep 8, 2020

Could you be more specific as to which laws? Audio is sent but not processed by FreeSWITCH.

@iSamof
Copy link

iSamof commented Sep 8, 2020

@matiasilva - This is from Wikipedia re GDPR:

"The General Data Protection Regulation is a regulation in EU law on data protection and privacy in the European Union and the European Economic Area. It also addresses the transfer of personal data outside the EU and EEA areas."

Even non-EU companies who operate within the EU "or" have clients/users in the EU are required to comply. I think the issue raised by @psuet re GDPR is that the user expects that his audio is not transmitted when his mic is muted.

Granted, the audio is not processed as you state and therefore personally I don' t believe this is a serious GDPR issue - though I am not a lawyer. However, the transmission is still a waste of bandwidth and risking a lawsuit in such a situation is not a great idea.

@matiasilva
Copy link
Collaborator

matiasilva commented Sep 8, 2020

@iSamof thanks for the clarification! I am resident in the EU, so I'm well aware of the laws. I was asking more specifically to know exactly which violation is happening.

Agree with you on all other points.

@cyfrax
Copy link

cyfrax commented Sep 9, 2020

@iSamof thanks for the clarification! I am resident in the EU, so I'm well aware of the laws. I was asking more specifically to know exactly which violation is happening.

Agree with you on all other points.

Because you'd need a legal base for this data collection which would in this case be the individual consent of participants.
You couldn't justify a legal base of legitimate interests in this case as there are too many reasons for not wanting microphone audio being transmitted to the server even though the client is set to.mute.
Which then on the other hand makes it practically unusable for any kind of meeting where you need participants to join.
Consent as a legal base is only working if it's really optional. Which it really isn't if you want everyone to be in the meeting.
And even more so it makes it pretty much unusable in schools where individual consent is even more problematic.

@paulmenzel
Copy link
Contributor

paulmenzel commented Sep 9, 2020

Please let’s take one step back.

Is it confirmed, that despite being muted, actually it is recorded but just not processed on the server? A reference to the appropriate code would nice.

My current assumption was, the microphone is indeed muted, and only garbage is transmitted. So my only problem was the wasted bandwidth.

@awlx
Copy link

awlx commented Sep 9, 2020

The audio is still transmitted to the server and with a few lines of language of choice you can record every participant no matter if muted or not.

Those things are not recorded by default. But you just need a small script which does the recording as freeswitch has the audio feeds.

Maybe @lukas2511 can explain even more.

@ReimarBauer
Copy link

ReimarBauer commented Sep 9, 2020

The options we always have:

  • use mute button of headset, than only garbage noise is transmitted
  • remove the access token in the browser to the microphone (no idea how to do that besides manually)
  • on connection choose "Listen only", activate Microphone only on talking, and toggle back to disconnected (we have to optimize that cycle maybe)

If we want to save the time of the reconnection we maybe should find a way to send a garbage noise to the server without having to switch off a line by a physical button. Otherwise with physical buttons we could solve also a wish, push to talk.

@matiasilva
Copy link
Collaborator

matiasilva commented Sep 9, 2020

You can also mute the WebRTC audio in the tab as per usual. The audio is not recorded and by default the audio is received but not processed. There is, of course, nothing stopping a rogue system administrator from collecting all the muted audio sent to FreeSWITCH. Since the mute is server side, you can just pull the audio before it is decoded by mod_conference. If one is willing to do this, though, there are also many other things one rogue sysadmin could do.

@paulmenzel
Copy link
Contributor

paulmenzel commented Sep 9, 2020

  1. Is that behavior documented somewhere?
  2. Could the issue title please be updated? Maybe: Mute functionality still records and transmits audio to server, where it’s dropped

@matiasilva matiasilva changed the title 50-80 kbps audio stream sent to server even when client microphone muted? Mute functionality still records and transmits audio to server (FreeSWITCH) Sep 9, 2020
@uka-support
Copy link

uka-support commented Sep 9, 2020

Oops. I'd also consider this to be a privacy issue. Mute on the client must prevent audio to be transmitted at all - I'm actually surprised that there shoudln't be a simple way to mute the audio stream client-side.

@matiasilva
Copy link
Collaborator

matiasilva commented Sep 9, 2020

Yes, that's true :/

@paulmenzel
Copy link
Contributor

paulmenzel commented Sep 9, 2020

It’s my opinion, that all users have the expectation, when they use the mute functionality in the BBB frontend, that no audio is recorded and transmitted by BBB at all to the server.

Besides the rogue administrator scenario, the audio stream could be recorded on the network, stored and in the future be decrypted. Not transmitting audio at all will prevent that and also save bandwidth.

@paulmenzel
Copy link
Contributor

paulmenzel commented Sep 9, 2020

There is, see below:
image

You are missing the point of the issue. Of course, I can also disconnect the microphone, but if the BBB frontend offers a mute functionality, it should do what the user expects. Otherwise remove that functionality.

@matiasilva
Copy link
Collaborator

matiasilva commented Sep 9, 2020

I agree. Though is the user who mutes themselves concerned if the audio is sent to the server or not, or just that it is not broadcasted to everyone else? The user expects their audio not to be broadcasted to everyone else, and the mute function currently does its job in that regard.

@awlx
Copy link

awlx commented Sep 9, 2020

No, the user expects that there is no audio sent at all and it can't be abused for spying on people on the server side.

@koraa
Copy link

koraa commented Sep 9, 2020

@matiasilva Excuse me for weighing in, but I am having a hard time understanding the motivation behind you even asking this? This seems like an obvious bug, (1) because it wastes bandwidth (2) because it very likely constitutes a security bug & a privacy issue: It would be possible for a server to circumvent the user mute server side only.

Now granted, even if the mute is client side, this could be circumvented by just providing a manipulated client side, so I see how technically it doesn't make as much of a difference as it would seem.

I propose that the following behavior should be the goal, giving two states:

  1. Unmuted/Speaking: The client transmits audio as usual which is audible by other users. The browser indicates that a recording is being made. Bandwidth is used for an audio transmission.
  2. Muted: The client does not transmit audio, no bandwith is used for the upstream transmission of audio. The browsers "recording ongoing" indicator is offline.

I think the point about the browser's recording indicator is really important here; even if the web frontent may not be trustworthy in some installations, the browser should be. I realize though, that this might be a bit hard to implement technically (haven't looked at the available APIs and behaviors in relation to the permissions pop up to check).

@awlx
Copy link

awlx commented Sep 9, 2020

Jitsi has this implemented on the clientside and prevents audio from being transmitted. Might be worth a look.

See frontend code here:
https://github.com/jitsi/lib-jitsi-meet/blob/master/modules/RTC/JitsiLocalTrack.js#L514

@lukas2511
Copy link

lukas2511 commented Sep 9, 2020

For reference: "Spying" is as easy as uuid_setvar <uuid> record_stereo true and uuid_record <uuid> start /tmp/whatever.opus on the freeswitch API. It's also possible to remotely unmute a participant, that's also kinda not-so-great but at least it's clearly indicated that the microphone is being activated.

Stumbled over this on accident while trying to build a multi-track recorder for BBB conferences (making it easier to level speakers in recordings and removing noises etc.)

Listening on the freeswitch API it's also trivial to know when a participant is muted, so it would be very easy to filter for muted sections. Combine with a bit of silcence-filtering, easy tooling for listening to private conversations...

It's one thing if somebody willingly modifies a software to behave like this, but it's something entirely different if it can be abused without any modification.

@lukas2511
Copy link

lukas2511 commented Sep 9, 2020

Jitsi solves this by setting the enabled flag for a user media stream to false on supported browsers. It's limited to Chrome and Safari, but I think I've seen a compatibility matrix somewhere with only Internet Explorer being not support, but maybe I'm remembering the wrong matrix.

Unsupported browsers would need to completely remove the microphone from the session. For that it would be necessary to check if the freeswitch webrtc api allows for that without closing the connection completely, which would otherwise require reconnecting every time the microphone is enabled/disabled. Since it's designed for telephony it may not be able to handle this without problems.

@koraa
Copy link

koraa commented Sep 9, 2020

Would it be possible to just transmit silence? If it's using compression it should compress to pretty much nothing (though power usage would still be higher).

@matiasilva
Copy link
Collaborator

matiasilva commented Sep 9, 2020

@koraa I'm asking these questions to get at the root of the issue, and how a "fix" can be implemented. If it were obvious, such an issue would not exist in the software. There are probably deliberate choices that led to things being the way they are and those may not be apparent to everyone.

@lukas2511
Copy link

lukas2511 commented Sep 9, 2020

Also keep in mind that the freeswitch API and even the configuration file including the API password is reachable/readable by even unprivileged users.

In combination with a RCE in any component (or even third-party software) an attacker would be able to spy on every user of the server. No need to escalate privileges and modifying the software.

@lukas2511
Copy link

lukas2511 commented Sep 9, 2020

See https://bats.science/20557-7481150e3409497aa5fb4bfc46023237-1599650623781-Lukas_Schauer.mp3 for a cringy example recording.

@prlanzarin
Copy link
Member

prlanzarin commented Sep 9, 2020

There's already a fix under testing that will land in the next patch release (2.2.24).

  • It uses the track enabled property.
  • The track enabled property makes the encoder generate silent frames instead of capturing from the input source.
  • It's supported by all major browser for a long time now
  • There will still be a 48kbps (tops, depends on the browser) stream being transmitted to the server, but that'll be silence.
  • For the bandwidth saving folks: only way to do that reasonably would be to remove and re-add the sender track, but that would imply renegotiation which we currently do not support. So, no, we won't save those max 48kbps right now.

Just to clarify something: muted microphones are not recorded right now (* in a default scenario). But yes, it can be an attack surface for a compromised server which could allow that and it doesn't even need privilege escalation by default. But then again, nothing prevents a server admin from securing FreeSWITCH. Nonetheless, a client side mute will be included very soon.

@fadenb
Copy link

fadenb commented Sep 9, 2020

Just to clarify something: muted microphones are not recorded right now.

Just to clarify: You are referring to recordings created using default bbb functonality not the malicious ones? :)

@prlanzarin
Copy link
Member

prlanzarin commented Sep 9, 2020

Of course. I clarified it because the issue title can give the idea that everything is always recorded, which is not correct.

@awlx
Copy link

awlx commented Sep 9, 2020

I think there could be the misunderstanding between always sent to server and always being recorded.

So Microphone audio is always sent to the server even when muted. But to record that you need a script which hooks to freeswitch (which is easy but an extra step).

@prlanzarin
Copy link
Member

prlanzarin commented Sep 9, 2020

@awlx

So Microphone audio is always sent to the server even when muted. But to record that you need a script which hooks to freeswitch

Correct.

which is easy

"Easy" is debatable. You need a compromised server, unsecured freeswitch and/or a willing server admin to do that. It's an attack surface which has to presume those three conditions are met.

@paulmenzel
Copy link
Contributor

paulmenzel commented Sep 9, 2020

There's already a fix under testing that will land in the next patch release (2.2.24).

It’d be great if you could point to that commit, if it’s available in some branch.

[…]

@awlx
Copy link

awlx commented Sep 9, 2020

@awlx

So Microphone audio is always sent to the server even when muted. But to record that you need a script which hooks to freeswitch

Correct.

which is easy

"Easy" is debatable. You need a compromised server, unsecured freeswitch and/or a willing server admin to do that. It's an attack surface.

So, default install of BBB is enough to fulfil most of those requirements.
And one could just sell a plugin for serveradmins to get some "insights" on what people think while being muted.

So thank you already for confirming and working on this issue.

@basisbit
Copy link
Collaborator

basisbit commented Sep 9, 2020

BBB runs as website, so whenever a server is compromised, the attacker can also modify the data which is sent to the clients, thus also "easily" change the implementation of the "mute" button. This attack scenario / "security" issue is imho not important for the issue. Let's instead focus on having the webclient not send the audio data to the server with the intent of reducing CPU load on freeswitch as well as saving bandwidth. On the client side, you still want audio input processing to be done when microphone mode is enabled, even when the mute button is pressed, so that the UI can show to users that they probably forgot to unmute them self.

Please keep the focus on the code improvement, not on any opinions regarding how one interprets certain laws.

Edit: if you as server operator think that the current mute button is not GDPR compliant, one work-around could be to remove the button from the UI. Just don't forget that the user already gave you permission that this speech data is processed by the system (independently from any implementation details).

@prlanzarin
Copy link
Member

prlanzarin commented Sep 9, 2020

It’d be great if you could point to that commit, if it’s available in some branch.

@paulmenzel

#10423.

@DasSkelett
Copy link

DasSkelett commented Sep 9, 2020

BBB runs as website, so whenever a server is compromised, the attacker can also modify the data which is sent to the clients, thus also "easily" change the implementation of the "mute" button. This attack scenario / "security" issue is imho not important for the issue.

There's privacy by default, and then there's privacy-not-at-all-because-someone-could-hack-it-anyway, apparently.

@mariogasparoni
Copy link
Member

mariogasparoni commented Sep 10, 2020

No, the user expects that there is no audio sent at all and it can't be abused for spying on people on the server side.

A few considerations about your comment (and some others comments's).

As mentioned in https://docs.bigbluebutton.org:
"BigBlueButton is an open source web conferencing system ..." , which means this is not a global conferencing service, neither a company interested in collecting your audio data.

You can read more about BigBlueButton privacy in it's Websites (".org" and "demo....org") here

BigBlueButton (BBB) can be freely downloaded and installed by any school, university, institution, etc; and it is licensed under LGPL-3.0; which means anyone is free to use it commercially , to modify, to distribute, etc (more information about LGPL-3.0 can be found here).

This also means BBB comes with no warranty: if you want to use it freely (or commercially), you are on your own.
There are companies around the world that offer BBB as a part of your service and are able to guarantee no one is stealing your data.

If your university or school is using BigBlueButton to steal your data, it is not up to us to prevent that. You should probably speak to a lawyer in your country to discuss about how to proceed in this case. Here in Brazil, for example, our government recently approved a new law (LGPD - L13709) regarding user's privacy.

I am really thankful to BBB Team and @prlanzarin for #10423, but malicious system administrators, for example, could just decide to not to apply this patch and your data would be sent to the server anyways. At this moment, we are not able to prevent this type of privacy violation.

Also, once BigBlueButton can run on any personal server, there's no need to mention how a misconfigured server/OS/network could harm your security/privacy no matter the efforts BBB team could make.
More information on how to correctly install and setup your server can be found here

I believe there's a lot to improve on BBB (the issue on this case is a good example), but i am pretty sure BBB community is not interested in getting your personal data.

Please, don't get me wrong, i am glad you guys found this important issue (and also there's already a proposed solution for that).
My point is, security/privacy also is a responsibility of who is hosting BBB.

Cheers

@lukas2511
Copy link

lukas2511 commented Sep 10, 2020

Again, at least in it's core this issue is not what would be theoretically possible (as in modifying the code so that it just shows it's muted while actually being still active or something like that), it's about what's actually happening: Unknowingly sending audio data to the server. Even though it is not stored, it's still being transmitted.

Thanks to the patch this issue should be fixed with the next update, thanks BBB-devs!

I think everybody here is glad to have this free alternative with a lot more control over their data than e.g. using Webex or Zoom,
but if somebody comes screaming "mimimi the software is broken and violating my privacy" it's an issue that has to be dealt with.

GDPR and similar regulations are a battlefield, especially if working with children, and having a complaint about privacy-issues, notably something like this where data is unnecessarily transmitted, is a really big problem.
It requires immediate action, but most sysadmins don't have insight into the code of a project of this massive scale and it's nearly impossible for them to fix those issues.

Also they'd have to know about them first, with would mean auditing the software.
It's not like there is a list of all of the privacy issues with BBB somewhere on the projects website, or did I not look hard enough?

Those people might be able to fix those small permission issues on config files, which are relatively easy to spot, but you can't expect them to e.g. fully understand how WebRTC works and how they should fix bugs like this themselves. That's what a projects community is for, and that's why bugs like this are reported and pushed to the top of the queue, so everybody gets the fix soon.

I personally spend weeks in the BBB codebase, mostly just to understand how everything is working, and I still don't have a full overview about what's happening where. I reported a few security bugs already, and might report more in the future, and I hope for all of them to be fixed quickly. Not only for me and the services I run for my university, but for all the people out there who don't have the ressources to handle an operation of this scale for themselves.

If that's not in line with the projects goals I'd adwise to put a big warning above the easy-to-use one-script-does-all bbb-install.sh stating that it just installs BBB as some sort of test-environment and you have to read the whole documentation and codebase anway to really configure and patch it as it should be.

@fippo
Copy link

fippo commented Sep 10, 2020

There will still be a 48kbps (tops, depends on the browser) OPUS stream being transmitted to the server, but that'll be silence.

That sounds wrong, opus encodes silence at a very low bitrate. If you check one of the canonical samples, setting localStream.getAudioTracks()[0].enabled = false; drops the payload bitrate (red in the left grahp) to almost nothing.

@prlanzarin
Copy link
Member

prlanzarin commented Sep 10, 2020

There will still be a 48kbps (tops, depends on the browser) OPUS stream being transmitted to the server, but that'll be silence.

That sounds wrong, opus encodes silence at a very low bitrate. If you check one of the canonical samples, setting localStream.getAudioTracks()[0].enabled = false; drops the payload bitrate (red in the left grahp) to almost nothing.

@fippo

That's why I said "tops". I just wanted to make clear that there would still be an OPUS stream being transmitted and it would still be, at the absolute worst case (probably buggy, hence the "depends"; no direct access/little control over the encoder), be constrained to 48kbps.

I'm well aware of the fact that compression will make it lower than that in the majority of cases; I detailed that further in the fix PR (ref #10423) description (I think I specifically stated it should be way under 10kbps, which might not necessarily always be correct).

Edit: I've improved that comment a bit to make that clear (I agree I might've not been clear enough) since folks seem to be referring to that comment a lot.

@ThomasAH
Copy link

ThomasAH commented Sep 22, 2020

It seems this is now fixed in 2.2.24 (and 2.2.25), see https://github.com/bigbluebutton/bigbluebutton/releases/tag/v2.2.24
Should this ticket (and the PRs linked from the release log) be closed?

@ffdixon
Copy link
Member

ffdixon commented Sep 22, 2020

@ffdixon ffdixon closed this as completed Sep 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests