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

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Thu, 15 Oct 2020 21:01:20 +0200
> Cc: 44018@debbugs.gnu.org
> 
> 15 okt. 2020 kl. 19.26 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> > Any details for the uninitiated, or pointers to the info?
> 
> You are definitely not uninitiated but others may be so please bear with me.
> 
> There are many things that can go wrong:
> 
> Playing sound files involves lots of code and libraries, sometimes even 
> executing external processes.
> Sound file formats are complex and a player typically needs to understand 
> several different ones; security-related bugs are not uncommon.
> Sound file players may also need access to the hardware, which can greatly 
> amplify the severity of any breach.

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?

> > Are the risks the same on all the supported platforms, or just on
> > some?
> 
> The security fundamentals (as above) are the same everywhere; details 
> obviously differ. Even if we could pronounce one platform as entirely 'safe' 
> for audio-playing, which I don't think is feasible, I don't see the gain from 
> doing so.

I asked because I looked for any known security risks associated with
the MCI interface we use on MS-Windows to implement
play-sound-internal, and couldn't find any.  Maybe I overlooked
something, or used sub-optimal search phrases, so I'd love to see
something about the risks.  Otherwise it sounds (pun intended) like we
are afraid of a danger that doesn't exist.

> Obviously 'safe' has to be understood in context. Can Emacs be tricked to 
> call play-sound-file with the name of a crafted file as argument? Maybe; as 
> far as I can tell, unsafe is only used by SES in Emacs proper, but it seems 
> feasible to create a .ses file that calls play-sound-file without asking the 
> user. To assume otherwise would be imprudent.

I'm not sure I understand: what's unsafe in playing sound?  I thought
you were talking about the danger of using a malicious file that is
disguised as a sound file, but in that case the fact that we invoke
the function is not the problem, the problem would be (AFAIU) if the
sound device failed to recognize the file as corrupted or of wrong
format, and caused whatever damage that was supposed to do.  Those are
the kind of details about the vulnerabilities I expected to see.  Is
any information along these lines available?

> It is true that the hostile Internet has hardened audio file code 
> considerably over the years but why would we explicitly make a security 
> exception for a function with large attack surface in an application (Emacs) 
> that may very well be used for inspection of potentially harmful files?

I'm struggling to understand what is the attack surface.  Can you (or
someone else) help in understanding that?