all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Third <alan@idiocy.org>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: 66245@debbugs.gnu.org, Eshel Yaron <me@eshelyaron.com>
Subject: bug#66245: [PATCH] ; Silence macOS 14 warning
Date: Thu, 28 Sep 2023 23:37:41 +0100	[thread overview]
Message-ID: <ZRYANVUyFAfbmMym@idiocy.org> (raw)
In-Reply-To: <CADwFkmnuxV++36jWGURehKu7WvFPp42sT5fq3vSp8EErC7-E1g@mail.gmail.com>

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

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





  reply	other threads:[~2023-09-28 22:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-27 19:00 bug#66245: [PATCH] ; Silence macOS 14 warning Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-28 10:35 ` Alan Third
2023-09-28 13:46   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-28 21:47     ` Alan Third
2023-09-28 22:16       ` Stefan Kangas
2023-09-28 22:37         ` Alan Third [this message]
2023-09-29  1:38           ` Yuan Fu
2023-09-29  9:34           ` Stefan Kangas
2023-09-29 15:10             ` Eli Zaretskii
2023-09-29  9:21         ` Gerd Möllmann
2023-09-29  9:38           ` Stefan Kangas
2023-09-29 10:11             ` Gerd Möllmann
2023-09-29 15:36               ` Alan Third
2023-09-29 14:55       ` Eli Zaretskii
2023-09-29 11:35 ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZRYANVUyFAfbmMym@idiocy.org \
    --to=alan@idiocy.org \
    --cc=66245@debbugs.gnu.org \
    --cc=me@eshelyaron.com \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.