Timeline for Mitigating vulnerabilities in audio libraries that cause physical damage
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 3, 2023 at 16:55 | comment | added | mYnDstrEAm | Sure, this concerns both cases and further cases but (mitigating it) does not depend on how this could turn out to be dangerous. I think the problem is not loud volume in general but too fast increases in volume (and maybe increases in volume beyond a certain level without user confirmation). If it is increased only gradually above 100% volume, one can disconnect speakers, stop pressing a key, hold ears, put down the headphones, etc in at least most (maybe not all) cases. The proposed tests per device would probably wear down or destroy them even if they could be done but it's a good idea. | |
| Nov 3, 2023 at 14:29 | comment | added | reed | @mYnDstrEAm, the threat model is useful to understand the threat exactly, because for example, we could talk about a malicious actor trying to suddenly increase the volume in a nightclub, or a simple incident where an user bumps into the volume by mistake and auto-destroys their own ears. If the problem is dangerous volume in general, then it might even be mitigated by running highest-volume tests before setting the volume. Like a beep at maximum perceived volume (by frequency/amplitude) to set the level, so that anything else afterwards is guaranteed to be comfortable. | |
| Nov 3, 2023 at 14:03 | comment | added | mYnDstrEAm | @reed It's certainly an issue that you point out but it doesn't change all that much. Considering impacts of UX is important (it doesn't have to decrease). I don't think the risk is low and in any case the potential direct harm is relatively high and the required effort to fix unknown. The main issue with the "threat model" objection is that a) it doesn't have to be your own machine (it could also be that of a person at a music venue for example where those affected include other people there) and b) many people have little IT skills or protections due to which limiting harm is still good. | |
| Nov 3, 2023 at 13:40 | comment | added | reed | I wrote an answer about the need to define a good threat model, but I deleted it because it was not a real answer, it should have been a comment. What I wanted to say is that without defining a threat model, it's hard to decide if this weakness is serious enough to be considered a vulnerability (it sounds like it's not). There could be software mitigations to this problem (and any other harmful volume-related problems), but they are probably not worth it (because most people don't care enough, risk is low, fixes would introduce unnecessary complexity and degrade user experience, etc.) | |
| Nov 3, 2023 at 13:30 | comment | added | mYnDstrEAm | @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. | |
| Nov 3, 2023 at 13:07 | history | edited | schroeder♦ | CC BY-SA 4.0 | deleted 9 characters in body |
| Nov 3, 2023 at 13:00 | history | edited | schroeder♦ | CC BY-SA 4.0 | edited title |
| Nov 3, 2023 at 12:33 | comment | added | Steffen Ullrich | "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." | |
| Nov 3, 2023 at 12:33 | answer | added | vidarlo | timeline score: 4 | |
| Nov 3, 2023 at 12:33 | answer | added | Gh0stFish | timeline score: 6 | |
| Nov 3, 2023 at 12:29 | comment | added | vidarlo | 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. | |
| Nov 3, 2023 at 12:23 | vote | accept | mYnDstrEAm | ||
| Nov 3, 2023 at 12:23 | |||||
| Nov 3, 2023 at 12:17 | comment | added | mYnDstrEAm | 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. | |
| Nov 3, 2023 at 12:11 | comment | added | ThoriumBR | 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. | |
| Nov 3, 2023 at 12:03 | history | asked | mYnDstrEAm | CC BY-SA 4.0 |