Timeline for Mitigating vulnerabilities in audio libraries that cause physical damage
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 4, 2023 at 12:37 | comment | added | vidarlo | 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. | |
| Nov 3, 2023 at 13:42 | comment | added | mYnDstrEAm | 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. | |
| Nov 3, 2023 at 13:25 | comment | added | reed | 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. | |
| Nov 3, 2023 at 12:33 | history | answered | vidarlo | CC BY-SA 4.0 |