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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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