[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#66245: [PATCH] ; Silence macOS 14 warning
From: |
Gerd Möllmann |
Subject: |
bug#66245: [PATCH] ; Silence macOS 14 warning |
Date: |
Fri, 29 Sep 2023 11:21:59 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Stefan Kangas <stefankangas@gmail.com> writes:
> Alan Third <alan@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.
- bug#66245: [PATCH] ; Silence macOS 14 warning, Eshel Yaron, 2023/09/27
- bug#66245: [PATCH] ; Silence macOS 14 warning, Alan Third, 2023/09/28
- bug#66245: [PATCH] ; Silence macOS 14 warning, Eshel Yaron, 2023/09/28
- bug#66245: [PATCH] ; Silence macOS 14 warning, Alan Third, 2023/09/28
- bug#66245: [PATCH] ; Silence macOS 14 warning, Stefan Kangas, 2023/09/28
- bug#66245: [PATCH] ; Silence macOS 14 warning, Alan Third, 2023/09/28
- bug#66245: [PATCH] ; Silence macOS 14 warning, Yuan Fu, 2023/09/28
- bug#66245: [PATCH] ; Silence macOS 14 warning, Stefan Kangas, 2023/09/29
- bug#66245: [PATCH] ; Silence macOS 14 warning, Eli Zaretskii, 2023/09/29
- bug#66245: [PATCH] ; Silence macOS 14 warning,
Gerd Möllmann <=
- bug#66245: [PATCH] ; Silence macOS 14 warning, Stefan Kangas, 2023/09/29
- bug#66245: [PATCH] ; Silence macOS 14 warning, Gerd Möllmann, 2023/09/29
- bug#66245: [PATCH] ; Silence macOS 14 warning, Alan Third, 2023/09/29
- bug#66245: [PATCH] ; Silence macOS 14 warning, Eli Zaretskii, 2023/09/29
bug#66245: [PATCH] ; Silence macOS 14 warning, Stefan Kangas, 2023/09/29