bug#44018: Don't consider play-sound-file to be a 'safe' function

["Mattias Engdegård" <mattiase@acm.org>]

15 okt. 2020 kl. 21.20 skrev Eli Zaretskii <eliz@gnu.org>:

> Any specifics, though?  Surely, if the risks are known, there should
> be some vulnerabilities recorded somewhere?  Is it possible to give a
> couple of examples, or refer to known vulnerabilities?

Sorry for being unclear. This is not about known vulnerabilities (which we hope are not present!) but about reducing risks -- ie, exposure to unknown present and future security holes.

Security thinking takes some getting used to; risks have to be motivated by clear needs. In this case, the needs for calls to play-sound-file with arbitrary input data seem very small but the risks aren't commensurate.

> I'm not sure I understand: what's unsafe in playing sound?

A fair question! Safe parsing and handling of binary file formats can be surprisingly difficult, especially in an unsafe language; the slightest mistake can be exploited by an intelligent adversary. It could be a buffer overrun, an unsufficiently checked parameter, signedness confusion, nonsensical combination of values, unexpected alignment, legal but untested values, text encoding traps in string fields (oh yes)... I have written many sound and image file parsers over the years, most of which would be completely unsuitable in a hostile environment.

And new attack vectors keep turning up. Inaudible sound streams carrying covert instructions to always-on voice-activated assistants? Maybe all they can do is to turn off the lights or order you more rolls of toilet paper but don't count on it.

Most weaknesses are likely to have been fuzzed and patched out of existence by now but it does not change the fact that playing arbitrary audio is an activity that will always carry more inherent risk than, say, calling ding or split-string, also in the same list of safe functions.

But, someone objects, I play arbitrary sound files in my web browser all the time! Yes, and that is not free of risk either -- but that web browser is likely to have undergone more care and hardening of these code paths than Emacs: more careful selection of libraries and APIs used, fewer obscure or obscure file formats supported, and even measures taken to contain breaches, such as sandboxing.

Finally, Emacs must be completely trusted as a tool for inspecting arbitrary files, even ones prepared with malicious intent.

> Do you understand why 'message' was removed?

I can only guess, but that function could be used to display deceptive messages that mislead the user to take actions against his or her own interest. Removing it looks like a wise decision.