From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#44018: Don't consider play-sound-file to be a 'safe' function Date: Thu, 15 Oct 2020 22:20:13 +0300 Message-ID: <83r1pzwb2q.fsf@gnu.org> References: <5A2CDAEA-03CF-4F92-AF9D-40421A9B362E@acm.org> <83zh4nwgbs.fsf@gnu.org> <024E3091-EB4E-419F-847B-CDB2FF3C96CC@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30593"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44018@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 15 21:21:24 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kT8oV-0007qC-S3 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Oct 2020 21:21:23 +0200 Original-Received: from localhost ([::1]:53858 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kT8oU-0000uE-Gt for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Oct 2020 15:21:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50538) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kT8oA-0000to-8e for bug-gnu-emacs@gnu.org; Thu, 15 Oct 2020 15:21:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45057) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kT8o9-0003UW-VX for bug-gnu-emacs@gnu.org; Thu, 15 Oct 2020 15:21:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kT8o9-0006l2-RF for bug-gnu-emacs@gnu.org; Thu, 15 Oct 2020 15:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Oct 2020 19:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44018 X-GNU-PR-Package: emacs Original-Received: via spool by 44018-submit@debbugs.gnu.org id=B44018.160278962425907 (code B ref 44018); Thu, 15 Oct 2020 19:21:01 +0000 Original-Received: (at 44018) by debbugs.gnu.org; 15 Oct 2020 19:20:24 +0000 Original-Received: from localhost ([127.0.0.1]:56603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kT8nY-0006jn-28 for submit@debbugs.gnu.org; Thu, 15 Oct 2020 15:20:24 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kT8nW-0006jX-UV for 44018@debbugs.gnu.org; Thu, 15 Oct 2020 15:20:23 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57158) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kT8nR-0003KS-Iv; Thu, 15 Oct 2020 15:20:17 -0400 Original-Received: from [176.228.60.248] (port=2321 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kT8nR-0004MJ-2J; Thu, 15 Oct 2020 15:20:17 -0400 In-Reply-To: <024E3091-EB4E-419F-847B-CDB2FF3C96CC@acm.org> (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Thu, 15 Oct 2020 21:01:20 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:190628 Archived-At: > From: Mattias Engdegård > Date: Thu, 15 Oct 2020 21:01:20 +0200 > Cc: 44018@debbugs.gnu.org > > 15 okt. 2020 kl. 19.26 skrev Eli Zaretskii : > > > 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?