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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 66245 in the body.
You can then email your comments to 66245 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] ; Silence macOS 14 warning
Date: Wed, 27 Sep 2023 21:00:45 +0200

[Message part 1 (text/plain, inline)]

Tags: patch

Hi,

After updating to macOS 14 (and rebuilding Emacs), I see the following
warning whenever I start Emacs:

    WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES.

This patch does exactly what the warning suggests, and it silences the
warning.

TBH I'm not entirely sure I understand the implications of implementing
`applicationSupportsSecureRestorableState`.  IIUC it makes Emacs opt-in
to the "secure state restoration" mechanism in contrast to a former
(supposedly less secure) mechanism, but AFAICT Emacs doesn't opt-in to
state restoration in the NS port in the first place...

[0001-Silence-macOS-14-warning.patch (text/patch, attachment)]

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

From: Alan Third <alan <at> idiocy.org>
To: 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 11:35:29 +0100

On Wed, Sep 27, 2023 at 09:00:45PM +0200, Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
> Tags: patch
> 
> Hi,
> 
> After updating to macOS 14 (and rebuilding Emacs), I see the following
> warning whenever I start Emacs:
> 
>     WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES.
> 
> This patch does exactly what the warning suggests, and it silences the
> warning.
> 
> TBH I'm not entirely sure I understand the implications of implementing
> `applicationSupportsSecureRestorableState`.  IIUC it makes Emacs opt-in
> to the "secure state restoration" mechanism in contrast to a former
> (supposedly less secure) mechanism, but AFAICT Emacs doesn't opt-in to
> state restoration in the NS port in the first place...

A description of what this fixes is here:

    https://sector7.computest.nl/post/2022-08-process-injection-breaking-all-macos-security-layers-with-a-single-vulnerability/

I'm not sure if making this change will affect us, as I don't think we
support saved states, although I could be wrong.

Is it possible for you to try a before and after test of how Emacs
handles saving the state over a reboot? That is, have a running Emacs
with open files and reboot, tick the "reopen windows when logging back
in" option, and see if it behaves differently with this patch applied
and not applied?

If it doesn't then I think this is probably safe and won't affect us,
so we should apply it. Otherwise we'll need to examine what's changed
and see if we can work around it.

Thanks!
-- 
Alan Third

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 66245 <at> debbugs.gnu.org
Subject: Re: bug#66245: [PATCH] ; Silence macOS 14 warning
Date: Thu, 28 Sep 2023 15:46:36 +0200

Hi Alan,

> I'm not sure if making this change will affect us, as I don't think we
> support saved states, although I could be wrong.

Yes, that's what I thought too.

> Is it possible for you to try a before and after test of how Emacs
> handles saving the state over a reboot? That is, have a running Emacs
> with open files and reboot, tick the "reopen windows when logging back
> in" option, and see if it behaves differently with this patch applied
> and not applied?

I tried that now, and I couldn't see any difference.  With and without
my patch, Emacs starts after reboot and shows the usual *scratch*
buffer, with no sign of the buffers/files that I had open before
rebooting.  (That could have been nice though!)

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

From: Alan Third <alan <at> idiocy.org>
To: 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 22:47:34 +0100

On Thu, Sep 28, 2023 at 03:46:36PM +0200, Eshel Yaron wrote:
> > Is it possible for you to try a before and after test of how Emacs
> > handles saving the state over a reboot? That is, have a running Emacs
> > with open files and reboot, tick the "reopen windows when logging back
> > in" option, and see if it behaves differently with this patch applied
> > and not applied?
> 
> I tried that now, and I couldn't see any difference.  With and without
> my patch, Emacs starts after reboot and shows the usual *scratch*
> buffer, with no sign of the buffers/files that I had open before
> rebooting.  (That could have been nice though!)

Thank you for testing that.

I think this should go into emacs-29, but it's unclear to me what the
(security) implications are. This change is required to fix
CVE-2021-30873, which is rated "high", however it's over a year old at
this point, and given that Apple are requiring us to explicitly set
this in our code rather than forcing it on us, does that mean they
don't consider it that big of a deal?

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/

CVE info:

    https://nvd.nist.gov/vuln/detail/CVE-2021-30873
-- 
Alan Third

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?

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

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

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

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

MacOS 14 is just released, I think. I’ve been building Emacs on macOS 13 and haven’t seen this warning.

Yuan

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 66245 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>,
 Eshel Yaron <me <at> eshelyaron.com>
Subject: Re: bug#66245: [PATCH] ; Silence macOS 14 warning
Date: Fri, 29 Sep 2023 11:21:59 +0200

Stefan Kangas <stefankangas <at> gmail.com> writes:

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

Well, not that drastically...  From the release notes of macOS 12 Appkit
(we're now at 14).

https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-12?changes=lat__5_3

Restorable State

    To enable secure coding for a restorable state, implement
    applicationSupportsSecureRestorableState(_:). When opted in:

        The system requires classes passed to restorationClass to
        explicitly conform to NSWindowRestoration.

        ...

I understand that as meaning that this switches on additional checks in
Appkit.  That should be okay for Emacs because it doesn't use this
feature of Appkit, at least AFAIK.

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

I guess Apple is more and more turning on "Secure Coding" stuff in their
libs.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 66245 <at> debbugs.gnu.org, eliz <at> gnu.org, Eshel Yaron <me <at> eshelyaron.com>
Subject: Re: bug#66245: [PATCH] ; Silence macOS 14 warning
Date: Fri, 29 Sep 2023 02:34:52 -0700

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

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

One thing we do commonly have, I think, is access to the Documents
directory.

OTOH, on GNU/Linux we typically don't really have any special protection
for user files.

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

I don't think we have a rough timeline for 29.2 as of now.  I'm leaning
towards just including this in the next release as usual, since the bug
only affects the macOS port, and anyways, and IIUC, depends on other
things being vulnerable to be exploited.

But I'm very open to being convinced otherwise, if anyone sees any
problems with that.

Eli, do you have any comments here?

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 66245 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>,
 Eshel Yaron <me <at> eshelyaron.com>
Subject: Re: bug#66245: [PATCH] ; Silence macOS 14 warning
Date: Fri, 29 Sep 2023 02:38:29 -0700

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

>> Without this code, are we enabling malicious processes to escape the
>> macOS sandbox, and gain the same privileges as the Emacs process?
>
> Well, not that drastically...  From the release notes of macOS 12 Appkit
> (we're now at 14).
>
> https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-12?changes=lat__5_3
>
> Restorable State
>
>     To enable secure coding for a restorable state, implement
>     applicationSupportsSecureRestorableState(_:). When opted in:
>
>         The system requires classes passed to restorationClass to
>         explicitly conform to NSWindowRestoration.
>
>         ...
>
> I understand that as meaning that this switches on additional checks in
> Appkit.  That should be okay for Emacs because it doesn't use this
> feature of Appkit, at least AFAIK.

Thanks.  IIUC, that seems to speak in favor of not making an emergency
release of Emacs 29.2 at this point.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 66245 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>,
 Eshel Yaron <me <at> eshelyaron.com>
Subject: Re: bug#66245: [PATCH] ; Silence macOS 14 warning
Date: Fri, 29 Sep 2023 12:11:50 +0200

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>>> Without this code, are we enabling malicious processes to escape the
>>> macOS sandbox, and gain the same privileges as the Emacs process?
>>
>> Well, not that drastically...  From the release notes of macOS 12 Appkit
>> (we're now at 14).
>>
>> https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-12?changes=lat__5_3
>>
>> Restorable State
>>
>>     To enable secure coding for a restorable state, implement
>>     applicationSupportsSecureRestorableState(_:). When opted in:
>>
>>         The system requires classes passed to restorationClass to
>>         explicitly conform to NSWindowRestoration.
>>
>>         ...
>>
>> I understand that as meaning that this switches on additional checks in
>> Appkit.  That should be okay for Emacs because it doesn't use this
>> feature of Appkit, at least AFAIK.
>
> Thanks.  IIUC, that seems to speak in favor of not making an emergency
> release of Emacs 29.2 at this point.

I agree.  The new method would just enable "secure coding" for
restorable state on macOS < 14 (it's the default in 14), but since we're
not using this stuff to begin with, it's kind of pointless.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eshel Yaron <me <at> eshelyaron.com>, 66245-done <at> debbugs.gnu.org
Subject: Re: bug#66245: [PATCH] ; Silence macOS 14 warning
Date: Fri, 29 Sep 2023 04:35:57 -0700

Version: 29.2

Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> Tags: patch
>
> Hi,
>
> After updating to macOS 14 (and rebuilding Emacs), I see the following
> warning whenever I start Emacs:
>
>     WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES.
>
> This patch does exactly what the warning suggests, and it silences the
> warning.

Thanks, this patch is now installed on emacs-29 ([1: a4185f87bd0]).

I'm also closing the bug, but this obviously doesn't preclude further
discussion.

[1: a4185f87bd0]: 2023-09-29 13:32:55 +0200
  ; Silence macOS 14 warning
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a4185f87bd0e5c129ce93a56b5a3330e2d6b1776

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 66245 <at> debbugs.gnu.org, me <at> eshelyaron.com
Subject: Re: bug#66245: [PATCH] ; Silence macOS 14 warning
Date: Fri, 29 Sep 2023 17:55:47 +0300

> Cc: 66245 <at> debbugs.gnu.org
> Date: Thu, 28 Sep 2023 22:47:34 +0100
> From: Alan Third <alan <at> idiocy.org>
> 
> Eli, Stefan, any thoughts? Does this look bad enough to force a new
> Emacs 29 release?

I don't understand this issue clearly enough to have an opinion, so I
trust you guys to decide whether this is important.

In any case, if we are worth our salt, Emacs 29.2 should be just a
month or two away, so I wouldn't make any emergency releases before
that, just for this issue.  After all, it isn't like Emacs doesn't
work, it just annoys you with a message at startup, right?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 66245 <at> debbugs.gnu.org, alan <at> idiocy.org, me <at> eshelyaron.com
Subject: Re: bug#66245: [PATCH] ; Silence macOS 14 warning
Date: Fri, 29 Sep 2023 18:10:56 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Fri, 29 Sep 2023 02:34:52 -0700
> Cc: Eshel Yaron <me <at> eshelyaron.com>, 66245 <at> debbugs.gnu.org, eliz <at> gnu.org
> 
> Eli, do you have any comments here?

I had hard time catching up on all the emails for the last 2 days, but
I finally posted a response a few minutes ago.

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

From: Alan Third <alan <at> idiocy.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 66245 <at> debbugs.gnu.org, Eshel Yaron <me <at> eshelyaron.com>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#66245: [PATCH] ; Silence macOS 14 warning
Date: Fri, 29 Sep 2023 16:36:22 +0100

On Fri, Sep 29, 2023 at 12:11:50PM +0200, Gerd Möllmann wrote:
> >> I understand that as meaning that this switches on additional checks in
> >> Appkit.  That should be okay for Emacs because it doesn't use this
> >> feature of Appkit, at least AFAIK.
> >
> > Thanks.  IIUC, that seems to speak in favor of not making an emergency
> > release of Emacs 29.2 at this point.
> 
> I agree.  The new method would just enable "secure coding" for
> restorable state on macOS < 14 (it's the default in 14), but since we're
> not using this stuff to begin with, it's kind of pointless.

Not quite true according to the long description linked elsewhere.
Saved state is turned on automatically and it seems there's no way to
opt out. As I understand it that means that even though we don't make
use of it the vulnerable code still executes.

I do agree though that it's probably not worth making an emergency
release.
-- 
Alan Third

Previous Next

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