0

As I pointed out here in February 2022, people who gained brief direct or remote access to a machine can change the volume step or other things regarding sudden large changes to the sound volume (for example via xbindkeys or shortcuts).

This can directly cause lasting physical harm via ear damage to one or many people at once or damage speakers/headphones. I don't know why it's not considered a severe urgent vulnerability. Root access is not even required for the pactl command(s). However, nothing is being done about it at this repo which I think is very irresponsible.

Which measures, other than building in some mitigation in the pulseaudio code, could be done to prevent exploits of this from actually occurring in the wild (it seems unknown if they already have)?

I'm of course not asking about which measures could help prevent malicious actors from gaining access to machines or have pactl commands being run at certain times. This is from the standpoint of physical security (protection from harm to people's bodies) and also from the stance that more lines of defense would be better even if volunteer devs of that repo finally engage with this issue for a new package upgrade so that if one measure fails or is vulnerable, another one still holds.

Improve this question
9
  • 1
    Because people gaining direct access to any system means they can change settings on said system. The way people got access is the vulnerability, not the ability to change settings. Commented Nov 3, 2023 at 12:11
  • As I wrote, a) they don't need direct access and also harm mitigation is not irrelevant just because b) unauthorized access as well as c) authorized malicious access should be mitigated as well. Commented Nov 3, 2023 at 12:17
  • 1
    And suddenly I want to play some audio with very low recording volume. How do you plan on handling that? Or I use a headset with a different characteristic, so that what's unbearably loud in one headset is barely hearable in a different headset? How should PA handle this? The answer is simple: It can't be handled in software. Commented Nov 3, 2023 at 12:29
  • 3
    "Which measures, other than building in some mitigation in the pulseaudio code, could be done to prevent exploits of this from actually occurring in the wild" - limit the possible output of the attached hardware. "However, nothing is being done about it at this repo which I think is very irresponsible." - there is a comment in the post you link to which explains that its kind of impossible to set appropriate limits. To cite: "I do not think that this problem can be solved in a general way because PA does not have any information about how loud the hardware actually is." Commented Nov 3, 2023 at 12:33
  • @vidarlo Hence this question (there are some complications). SteffenUllrich You should also read my reply to that there: it is irrelevant in regards to limiting the pace of volume increases. In addition to that, this question is about measures in general, not only my proposed code change of limiting the pace of volume change. Commented Nov 3, 2023 at 13:30

2 Answers 2

Reset to default
6

However, nothing is being done about it at this repo which I think is very irresponsible.

Because the "issue" that you're reporting is essentially "users can change the audio volume". That's not a vulnerability (outside of a few very specific threat models), it's an essential feature.

And as others have said (both here and in that ticket), PulseAudio has no idea if it's outputting to a pair of 2.5W desktop speakers or an 80,000W stack of concert speakers - so any kind of arbitrary cap like "20%" is useless.

Which measures, other than building in some mitigation in the pulseaudio code, could be done to prevent exploits of this from actually occurring in the wild (it seems unknown if they already have)?

In order cause harm to someone using this issue you need three conditions:

  • The ability to control the output volume from the computer.
  • An audio output device (speaker, headphones, etc) that is sufficiently powerful to cause physical damage to someone's hearing.
  • The victim to be close enough to the output device that their hearing is damaged.

If we're not talking about preventing the attacker gaining access or putting mitigations in Pulseaudio (which are problematic, as that issue you linked to talks about), then your prevention should focus on the other two points.

From an individual level, that would include things like:

  • Using hardware controls to lower the volume of audio devices (e.g, keeping the PulseAudio volume at 100% and using the volume dial on the speaker to lower it to a reasonable level).
  • Using lower power output devices that can't cause physical damage.
  • Placing a hardware device between PulseAudio and the speakers/headphones that limits the maximum volume.
  • Keeping a reasonable distance between yourself and the output devices.
  • Avoiding the use in headphones.

At a broader or legislative level, it could include things like:

  • Restricting access to higher-powered speakers.
  • Banning headphones (especially in-ear ones) that can produce volumes high enough to cause immediate hearing damage.
Improve this answer
9
  • ►1. You assume the only measure is a code change and even more a specific one which is a misunderstanding of what I proposed. I never said the volume should be limited, I said limiting the pace of volume change would be one way of addressing this.►2. Furthermore, this question is about other measures, not my proposed code change.►3. The three conditions are often met, the latter two probably in estimated half of all case (but nobody tested this).►4. These are great useful points but more specific info how would be good.A problem with these is that they're not viable for most vulnerable Commented Nov 3, 2023 at 13:37
  • @mYnDstrEAm who are the "most vulnerable", and why are none of those suggestions viable for them? What are you basing that assessment on? And in terms of the "how" that will vary greatly depending on the individual's setup and circumstances, so there aren't really generic answers beyond the very obvious ones. Which points specifically are you unsure how you would implement? Commented Nov 3, 2023 at 13:58
  • @mYnDstrEAm limiting the rate of chance of the volume would not solve this issue either, because again, it depends on the hardware after PulseAudio. A 5% increase in the PulseAudio volume could be the difference between comfortable listening and permanent heading damage. Commented Nov 3, 2023 at 14:01
  • Those with little computer skills or security protections as well as anybody around such when connected to powerful speakers (many music venues). They're not viable for example because people won't buy extra hardware just to mitigate this issue. There are further reasons such as it being unknown which output devices can or can't cause the problems. How to implement "hardware controls to lower the volume" (listed twice)? No, limiting the max-speed of volume change may not make it impossible but heavily mitigate the risk...cases where the sound is that loud at 2% vol are rare. Commented Nov 3, 2023 at 14:13
  • @mYnDstrEAm so the "most vulnerable" people are those who are running PulseAudio on Linux, but with no computing skills, with an expensive profession-grade audio equipment in a setup where one person adjusting the software volume control would cause permanent hearing damage to people, but no hardware between PulseAudio and the speakers that allows them to control or limit the volume? That's far too much of an edge case to be able to cover with generic recommendations, and PulseAudio is the last of their problems in that case. Have you ever encountered this, and can you describe their setup? Commented Nov 3, 2023 at 14:21
4

The short answer is that you can't handle this in software.

I have a couple of headsets I use. One has a built in amplifier and noise cancelling; having my volume at 10% is perfectly fine for a audio conference, and I can hear things just fine.

Another headset doesn't, and have rather large drivers. Admittedly I should probably use it with an external amplifier, but it works without one. Cranking up to 100% volume yields OK sound level. With my noise cancelling one it'd be deafening. And with external amplifier, it would depend on the volume setting (gain) of the amplifier.

So in short: limits to physical outputs can't be handled in the system software that has no knowledge of the properties of the audio speakers.

In a couple of bluetooth headsets I have, the software running in the headsets do perform peak volume shaving; they can do it, because the software is written for a specific headset, containing a specific speaker element. PulseAudio can't.

Improve this answer
3
  • Of course you could handle it in software, if you wanted to, for example by defining some presets for every device or scenario. The real question is: is it worth it? And without defining a specific threat model first, it looks like any mitigation is not worth it at all. Commented Nov 3, 2023 at 13:25
  • Again a misunderstanding: you assume the only measure is a code change and even more a specific one which is a misunderstanding of what I proposed. I never said the volume should be limited, in the issue I proposed limiting the pace of volume change would be one way of addressing this regardless of device. That is one way how it could be handled in software (and that doesn't have to be pulseaudio but could also be GNU/Linux/Debian for example). This question is mainly about other measures, not my proposed code change. Commented Nov 3, 2023 at 13:42
  • So you prepare binaries that refuse change quicker than a certain slope/pace - an attacker with access can replace said binary with one without that code path. It can't be solved in software against an attacker with access to the system. Solving security when you assume an attacker has control over the device is at best difficult. Commented Nov 4, 2023 at 12:37

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.