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

Previous Next

Full log

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

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

On Thu, Sep 28, 2023 at 03:16:21PM -0700, Stefan Kangas wrote:
> 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?

As I understand it, yes.

I'm not sure that Emacs has any particularly noteworthy privileges,
though. The example they give is an application that has installer
type privileges, which I doubt Emacs would ever have or need.

> 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?

Possibly. I'm not entirely clear. I think the process is to create a
fake "state" file and put it in the right place on the users machine
and the next time they reboot it will use that file.

> 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?

I'm not sure either. Is there a rough timeline for the release of
29.2? I feel like this is perhaps not very urgent, but if we're
talking, say, three or four months or more we maybe don't want to wait
that long.

> 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?

I believe that's what Eshel's patch does.

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

I guess Eshel's the first person to try building with the relevant
version of xcode who's noticed and reported the message. However that
version of xcode must have come out over a year ago (going by the date
on that article) so I don't know why nobody's noticed it before now.

My Mac is years behind, and I rarely build Emacs on it, so I don't get
these messages at all.
-- 
Alan Third

Previous Next

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