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

[Mattias Engdegård]

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.