GNU bug report logs - #66245
[PATCH] ; Silence macOS 14 warning

Previous Next

Full log

Message #17 received at 66245 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Eshel Yaron <me <at> eshelyaron.com>
Cc: 66245 <at> debbugs.gnu.org
Subject: Re: bug#66245: [PATCH] ; Silence macOS 14 warning
Date: Thu, 28 Sep 2023 15:16:21 -0700

Alan Third <alan <at> idiocy.org> writes:

> Eli, Stefan, any thoughts? Does this look bad enough to force a new
> Emacs 29 release?
>
> The link with the in-depth explanation again:
>
>     https://sector7.computest.nl/post/2022-08-process-injection-breaking-all-macos-security-layers-with-a-single-vulnerability/

Let's see if I understand this right.

Without this code, are we enabling malicious processes to escape the
macOS sandbox, and gain the same privileges as the Emacs process?

It is presumably easy for some malware to just test all processes on the
machine until one is found to be vulnerable, right?  So they don't have
to specifically target Emacs?

The full exploit chain there is not very easy to understand, but it
seems like several techniques are used for some of the more nasty stuff,
and some of the steps have been fixed already.  There can be other ways
to do the same thing of course.  So I'm not sure what to say about the
urgency of fixing this; it could be urgent, or it could wait until 29.2.
What is your view?

Another thing.  The link says:

    Nevertheless, if you write an Objective-C application, please make
    sure you add -applicationSupportsSecureRestorableState: to return
    TRUE and to adapt secure coding for all classes used for your saved
    states!

Do we use "secure coding for all classes used for saved states", or does
that also need to be fixed?

BTW, any idea why we're only hearing about it now?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.