Is CVE-2024-30203 bogus?

Is CVE-2024-30203 bogus?

[Sean Whitton]

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

Hello Ihor,

The description for CVE-2024-30203 is

    In Emacs before 29.3, Gnus treats inline MIME contents as trusted.

and for CVE-2024-30204 is

    In Emacs before 29.3, LaTeX preview is enabled by default for e-mail
    attachments.

but I think these commits

* ccc188fcf98..: Ihor Radchenko 2024-02-20 * lisp/files.el
  (untrusted-content): New variable.
* 937b9042ad7..: Ihor Radchenko 2024-02-20 * lisp/gnus/mm-view.el
  (mm-display-inline-fontify): Mark contents untrusted.
* 6f9ea396f49..: Ihor Radchenko 2024-02-20 org-latex-preview: Add
  protection when `untrusted-content' is non-nil

fix only a single problem, right?  But we have two CVEs.

It seems to me that either

- CVE-2024-30203 is just bogus, based on a misunderstanding by the CVEs
  assigner of exactly what the vulnerabilities were

- CVE-2024-30203 is legitimate, and we have only fixed one possible way
  in which Gnus treats inline MIME content as trusted.

I think it's the first one -- can you confirm?

Thanks.

-- 
Sean Whitton

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

Re: Is CVE-2024-30203 bogus?

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: emacs@packages.debian.org, emacs-devel@gnu.org,
>  oss-security@lists.openwall.com
> Date: Mon, 08 Apr 2024 15:05:21 +0800
> 
> 
> The description for CVE-2024-30203 is
> 
>     In Emacs before 29.3, Gnus treats inline MIME contents as trusted.
> 
> and for CVE-2024-30204 is
> 
>     In Emacs before 29.3, LaTeX preview is enabled by default for e-mail
>     attachments.
> 
> but I think these commits
> 
> * ccc188fcf98..: Ihor Radchenko 2024-02-20 * lisp/files.el
>   (untrusted-content): New variable.
> * 937b9042ad7..: Ihor Radchenko 2024-02-20 * lisp/gnus/mm-view.el
>   (mm-display-inline-fontify): Mark contents untrusted.
> * 6f9ea396f49..: Ihor Radchenko 2024-02-20 org-latex-preview: Add
>   protection when `untrusted-content' is non-nil
> 
> fix only a single problem, right?  But we have two CVEs.
> 
> It seems to me that either
> 
> - CVE-2024-30203 is just bogus, based on a misunderstanding by the CVEs
>   assigner of exactly what the vulnerabilities were
> 
> - CVE-2024-30203 is legitimate, and we have only fixed one possible way
>   in which Gnus treats inline MIME content as trusted.
> 
> I think it's the first one -- can you confirm?

I'm not Ihor, but I cannot agree with you.  Those changes fixed two
problems, not one: both the fact that by default MIME attachments are
treated in a way that can execute arbitrary code, and the fact that
maliciously-constructed LaTeX attachment could exhaust all free space
on your disk.

Re: Is CVE-2024-30203 bogus?

[Max Nikulin]

On 08/04/2024 18:38, Eli Zaretskii wrote:
>> From: Sean Whitton Date: Mon, 08 Apr 2024 15:05:21 +0800
>>
>> - CVE-2024-30203 is just bogus, based on a misunderstanding by the CVEs
>>    assigner of exactly what the vulnerabilities were
>>
>> - CVE-2024-30203 is legitimate, and we have only fixed one possible way
>>    in which Gnus treats inline MIME content as trusted.
>>
>> I think it's the first one -- can you confirm?
> 
> I'm not Ihor, but I cannot agree with you.  Those changes fixed two
> problems, not one: both the fact that by default MIME attachments are
> treated in a way that can execute arbitrary code, and the fact that
> maliciously-constructed LaTeX attachment could exhaust all free space
> on your disk.

Arbitrary code execution bug is neither CVE-2024-30203 nor 
CVE-2024-30204, it is

CVE-2024-30202 "In Emacs before 29.3, arbitrary Lisp code is evaluated 
as part of turning on Org mode. This affects Org Mode before 9.6.23."

and it is fixed by

- 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-29&id=befa9fcaae29a6c9a283ba371c3c5234c7f644eb
- 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=003ddacf1c8d869b1858181c29ea21b731a8d8d9
2024-02-20 12:19:46 +0300 Ihor Radchenko: org-macro--set-templates: 
Prevent code evaluation

This commit fully covers both scenarios:
- inline preview for attachments in Gnus,
- a text file (not necessary having .org suffix) opened in Emacs directly.

I hope, rare users have Org mode or TeX engine configuration allowing 
execution of arbitrary shell commands during generation of LaTeX preview.

The commits mentioned by Sean suppress a kind of DoS (attempt to exhaust 
disk space or inodes allocated for /tmp) through LaTeX preview for email 
attachments. (There is no reasonable way to address the case when a 
malicious file is opened in Emacs.)

Re: Is CVE-2024-30203 bogus?

[Ihor Radchenko]

Sean Whitton <spwhitton@spwhitton.name> writes:

> The description for CVE-2024-30203 is
>
>     In Emacs before 29.3, Gnus treats inline MIME contents as trusted.

Before Emacs 29.3, there was no concept of trusted or untrusted content
in Emacs. We introduced it specifically to control whether we allow
running LaTeX on the contents of a given buffer. (And even in Emacs
29.3, the concept of untrusted contents is not yet official) So, at least
the title is misleading.

> and for CVE-2024-30204 is
>
>     In Emacs before 29.3, LaTeX preview is enabled by default for e-mail
>     attachments.

This is closer to what was happening.
Note that LaTeX preview itself was not a problem. The problem was that we
executed actual latex program without user query with input taken from
buffer text to generate the previews (using the default settings). LaTeX
input can be specifically constructed to cause DOS when using LaTeX
compiler, which is especially dangerous when the input is coming from
emails.

Also, only GNUS and MUA clients re-using gnus libs (at least, notmuch
and mu4e) were affected. Not rmail, AFAIK.

> ...
> I think it's the first one -- can you confirm?

I hope that the above clarified things.

-- 
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: Is CVE-2024-30203 bogus? (Emacs)

[Sean Whitton]

Hello,

On Mon 08 Apr 2024 at 06:44pm GMT, Ihor Radchenko wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> The description for CVE-2024-30203 is
>>
>>     In Emacs before 29.3, Gnus treats inline MIME contents as trusted.
>
> Before Emacs 29.3, there was no concept of trusted or untrusted content
> in Emacs. We introduced it specifically to control whether we allow
> running LaTeX on the contents of a given buffer. (And even in Emacs
> 29.3, the concept of untrusted contents is not yet official) So, at least
> the title is misleading.

Right, it's a purely preliminary change, not fixing any holes in itself.

>> and for CVE-2024-30204 is
>>
>>     In Emacs before 29.3, LaTeX preview is enabled by default for e-mail
>>     attachments.
>
> This is closer to what was happening.
> Note that LaTeX preview itself was not a problem. The problem was that we
> executed actual latex program without user query with input taken from
> buffer text to generate the previews (using the default settings). LaTeX
> input can be specifically constructed to cause DOS when using LaTeX
> compiler, which is especially dangerous when the input is coming from
> emails.
>
> Also, only GNUS and MUA clients re-using gnus libs (at least, notmuch
> and mu4e) were affected. Not rmail, AFAIK.
>
>> ...
>> I think it's the first one -- can you confirm?
>
> I hope that the above clarified things.

Hmm, thank you, but let me ask a follow-up question: do you agree with
me that there is only one security flaw covered by these two CVEs, and
CVE-2024-30203 is the superfluous one?

-- 
Sean Whitton

Re: Is CVE-2024-30203 bogus? (Emacs)

[Ihor Radchenko]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hmm, thank you, but let me ask a follow-up question: do you agree with
> me that there is only one security flaw covered by these two CVEs, and
> CVE-2024-30203 is the superfluous one?

Yes, CVE-2024-30203 title is superfluous.
And CVE-2024-30204 title is not accurate - it only applies to
certain attachments with specific (text/x-org) mime type.

-- 
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: Re: Is CVE-2024-30203 bogus? (Emacs)

[Salvatore Bonaccorso]

Hi,

On Wed, Apr 10, 2024 at 12:04:06PM +0000, Ihor Radchenko wrote:
> Sean Whitton <spwhitton-PEZ64Ft4C9UnzZ6mRAm98g@public.gmane.org> writes:
> 
> > Hmm, thank you, but let me ask a follow-up question: do you agree with
> > me that there is only one security flaw covered by these two CVEs, and
> > CVE-2024-30203 is the superfluous one?
> 
> Yes, CVE-2024-30203 title is superfluous.
> And CVE-2024-30204 title is not accurate - it only applies to
> certain attachments with specific (text/x-org) mime type.

Note that the CVE assignment (by MITRE as assigning CNA) for
CVE-2024-30203 is explicitly as follows:

> In Emacs before 29.3, Gnus treats inline MIME contents as trusted.

associated with:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-29&id=937b9042ad7426acdcca33e3d931d8f495bdd804

If you think the CVE assignment is not valid, then you might ask for a
REJECT on https://cveform.mitre.org/ .

Regards,
Salvatore

Re: Is CVE-2024-30203 bogus? (Emacs)

[Max Nikulin]

On 10/04/2024 21:17, Salvatore Bonaccorso wrote:
> On Wed, Apr 10, 2024 at 12:04:06PM +0000, Ihor Radchenko wrote:
>>
>> Yes, CVE-2024-30203 title is superfluous.
>> And CVE-2024-30204 title is not accurate - it only applies to
>> certain attachments with specific (text/x-org) mime type.
[...]
> If you think the CVE assignment is not valid, then you might ask for a
> REJECT on https://cveform.mitre.org/ .

Do 2 CVE numbers make sense to track fixes in Emacs and Org mode? 
Various versions of Org mode may be loaded to different versions of 
Emacs and both parties must have fixes to avoid the issue.

Re: Is CVE-2024-30203 bogus? (Emacs)

[Sean Whitton]

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

Hello,

On Wed 10 Apr 2024 at 10:07pm +07, Max Nikulin wrote:

> On 10/04/2024 21:17, Salvatore Bonaccorso wrote:
>> On Wed, Apr 10, 2024 at 12:04:06PM +0000, Ihor Radchenko wrote:
>>>
>>> Yes, CVE-2024-30203 title is superfluous.
>>> And CVE-2024-30204 title is not accurate - it only applies to
>>> certain attachments with specific (text/x-org) mime type.
> [...]
>> If you think the CVE assignment is not valid, then you might ask for a
>> REJECT on https://cveform.mitre.org/ .
>
> Do 2 CVE numbers make sense to track fixes in Emacs and Org mode? Various
> versions of Org mode may be loaded to different versions of Emacs and both
> parties must have fixes to avoid the issue.

My understanding is that one CVE for the same vulnerability in multiple
code bases is normal.

-- 
Sean Whitton

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

Re: [oss-security] Re: Is CVE-2024-30203 bogus? (Emacs)

[Sean Whitton]

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

Hello,

On Wed 10 Apr 2024 at 04:17pm +02, Salvatore Bonaccorso wrote:

> Note that the CVE assignment (by MITRE as assigning CNA) for
> CVE-2024-30203 is explicitly as follows:
>
>> In Emacs before 29.3, Gnus treats inline MIME contents as trusted.
>
> associated with:
>
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-29&id=937b9042ad7426acdcca33e3d931d8f495bdd804

This commit doesn't fix anything at all, just fyi.

> If you think the CVE assignment is not valid, then you might ask for a
> REJECT on https://cveform.mitre.org/ .

Okay, I'll do that, thanks.

-- 
Sean Whitton

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

Re: Is CVE-2024-30203 bogus? (Emacs)

[Max Nikulin]

On 11/04/2024 16:13, Sean Whitton wrote:
> On Wed 10 Apr 2024 at 04:17pm +02, Salvatore Bonaccorso wrote:
> 
>> Note that the CVE assignment (by MITRE as assigning CNA) for
>> CVE-2024-30203 is explicitly as follows:
>>
>>> In Emacs before 29.3, Gnus treats inline MIME contents as trusted.
>>
>> https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-29&id=937b9042ad7426acdcca33e3d931d8f495bdd804
> 
> This commit doesn't fix anything at all, just fyi.

This Emacs commit

     2024-02-20 12:44:30 +0300 Ihor Radchenko:
     * lisp/gnus/mm-view.el (mm-display-inline-fontify): Mark contents 
untrusted.)

is not enough to fix the issue. More changes are required to make the
fix effective, namely

ccc188fcf98 2024-02-20 12:43:51 +0300 Ihor Radchenko: * lisp/files.el 
(untrusted-content): New variable.
6f9ea396f49 2024-02-20 12:47:24 +0300 Ihor Radchenko: org-latex-preview: 
Add protection when `untrusted-content' is non-nil


When external Org mode is loaded, that version should contain

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=03635a335
2024-02-20 12:47:24 +0300 Ihor Radchenko: org-latex-preview: Add 
protection when `untrusted-content' is non-nil

besides Emacs commits ccc188fcf98 and 937b9042ad7

Emacs commit 6f9ea396f49 (fix of built-in Org mode) is currently
associated with CVE-2024-30203, however Org mode commit 03635a335
is not.