GNU bug report logs - #63063
CVE-2021-36699 report

Previous Next

To reply to this bug, email your comments to 63063 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: fuomag9 <fuo <at> fuo.fi>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 10:14:05 +0300

> From: fuomag9 <fuo <at> fuo.fi>
> Date: Mon, 24 Apr 2023 21:27:34 +0000
> 
> I’m a security researcher and I’ve searched for a way to contact the emacs security team but I’ve not found any information online, so I’m reporting this issue here.
> I’ve discovered a buffer overflow in GNU Emacs 28.0.50 (at the time of writing the exploit still works on GNU Emacs 28.2)
> The issue is inside the --dump-file functionality of emacs, in particular dump_make_lv_from_reloc at pdumper.c:5239
> Attached to this email there's is payload used to make the vulnerability work (if emacs complains about a signature error you need to replace the hex bytes inside the payload with the expected one, since every emacs binary will expect a different signature).
> This issue has been assigned CVE-2021-36699 and thus I’m notifying you of this. (I do not think the emacs team is aware of this security issue)
> The POC is simple:
> Launch emacs --dump-file exploit, where exploit is a custom crafted emacs dump file

Please tell more about the buffer overflow: where does it happen in
the Emacs sources, which buffer overflows, and why.  I cannot find
these details in your report.

Also, the CVE ID seems to be incorrect: if I look it up, I get some
SQL related issue, not an Emacs issue.

Message #8 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63063 <at> debbugs.gnu.org, fuomag9 <fuo <at> fuo.fi>
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 15:24:31 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> Please tell more about the buffer overflow: where does it happen in
> the Emacs sources, which buffer overflows, and why.  I cannot find
> these details in your report.

It happens because the dump file is deliberately edited to be invalid.
It is not a dump file that Emacs will generate under any circumstance,
and as such it's not a bug; by the same means, a pointer to an invalid
Lisp object could be created, causing a similar crash.  Emacs is not
expected to operate from a corrupt dump file any more than it is
expected to operate from a corrupt executable.

Message #11 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Martyanoff <nicolas <at> n16f.net>
Cc: luangruo <at> yahoo.com, 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 10:53:09 +0300

> From: Nicolas Martyanoff <nicolas <at> n16f.net>
> Cc: fuomag9 <fuo <at> fuo.fi>,  emacs-devel <at> gnu.org
> Date: Tue, 25 Apr 2023 09:13:34 +0200
> 
> Po Lu <luangruo <at> yahoo.com> writes:
> 
> > If you create a malformed dump file, of course Emacs cannot possibly
> > work.  Here, the buffer overflow is not even a bug: signature checks are
> > already there to prevent a dump file created for a different copy of
> > Emacs from being loaded by mistake.  If you deliberately create a
> > malformed dump file, Emacs does not guarantee correct operation.
> Is there a reason why Emacs does not validate dump files while reading
> them as any other program with any other data format? Nothing good ever
> comes from buffer overflows.
> 
> > We are trying to put together two releases of a very large piece of
> > software at the same time, and really should not be wasting our time on
> > these CVE reports.  It would save us a great deal of trouble if whoever
> > runs the CVE registry stopped tracking security ``issues'' with Emacs.
> I'm aware that most people simply do not care about security, and it is
> your right to do the same. However I sincerely hope it is not the view
> of the GNU Emacs project in general.

Please do NOT respond on emacs-devel, only to the bug tracker.

I've redirected the response.

Message #14 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi, nicolas <at> n16f.net
Subject: Re: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 10:53:54 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: fuomag9 <fuo <at> fuo.fi>,  emacs-devel <at> gnu.org
> Date: Tue, 25 Apr 2023 15:21:27 +0800
> 
> Nicolas Martyanoff <nicolas <at> n16f.net> writes:
> 
> > Is there a reason why Emacs does not validate dump files while reading
> > them as any other program with any other data format? Nothing good ever
> > comes from buffer overflows.
> 
> Is there any reason Unix does not verify that machine code is free of
> bugs before loading an a.out into memory?

Please keep this discussion on the bug tracker, not on emacs-devel.

PLEASE!!

Message #17 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 10:55:36 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: fuomag9 <fuo <at> fuo.fi>,  63063 <at> debbugs.gnu.org
> Date: Tue, 25 Apr 2023 15:24:31 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Please tell more about the buffer overflow: where does it happen in
> > the Emacs sources, which buffer overflows, and why.  I cannot find
> > these details in your report.
> 
> It happens because the dump file is deliberately edited to be invalid.

I didn't ask about the root cause, I asked about the details of the
problem: where it happens in our sources, and what exactly happens.

> It is not a dump file that Emacs will generate under any circumstance,
> and as such it's not a bug; by the same means, a pointer to an invalid
> Lisp object could be created, causing a similar crash.  Emacs is not
> expected to operate from a corrupt dump file any more than it is
> expected to operate from a corrupt executable.

Noted.  But please let me make up my own mind about this issue, once I
understand the details.  OK?

Message #20 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuri Khan <yuri.v.khan <at> gmail.com>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 10:57:07 +0300

> From: Yuri Khan <yuri.v.khan <at> gmail.com>
> Date: Tue, 25 Apr 2023 14:40:20 +0700
> Cc: emacs-devel <at> gnu.org
> 
> On Tue, 25 Apr 2023 at 12:33, fuomag9 <fuo <at> fuo.fi> wrote:
> 
> > Hi,
> > I’m a security researcher and I’ve searched for a way to contact the emacs security team but I’ve not found any information online, so I’m reporting this issue here.
> > I’ve discovered a buffer overflow in GNU Emacs 28.0.50 (at the time of writing the exploit still works on GNU Emacs 28.2)
> > The issue is inside the --dump-file functionality of emacs, in particular dump_make_lv_from_reloc at pdumper.c:5239
> > Attached to this email there's is payload used to make the vulnerability work (if emacs complains about a signature error you need to replace the hex bytes inside the payload with the expected one, since every emacs binary will expect a different signature).
> 
> A security report needs to identify a few key pieces of information:
> 
> * Who is the attacker?
> * Who is the victim?
> * What is the attack vector?
> * What does the attacker gain from the attack, that they would not be
> able to do without it?
> 
> If you start thinking about the described case, you will come to a
> conclusion that (1) you are able to attack yourself, or (2) if you can
> persuade another person to run Emacs with a dump file you provided,
> you are able to inflict denial of service for that specific run; or,
> if you provide a differently specially constructed dump file,
> arbitrary code execution as that user.
> 
> However, you could achieve the same by just convincing the victim to
> run an executable file you provide.
> 
> As Raymond Chen <https://devblogs.microsoft.com/oldnewthing/> likes to
> say, this so-called vulnerability involves being on the other side of
> the airtight hatchway.

PLEASE do NOT respond to this on emacs-devel, only to the bug tracker.

Message #23 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 16:38:19 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Po Lu <luangruo <at> yahoo.com>
>> Cc: fuomag9 <fuo <at> fuo.fi>,  63063 <at> debbugs.gnu.org
>> Date: Tue, 25 Apr 2023 15:24:31 +0800
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Please tell more about the buffer overflow: where does it happen in
>> > the Emacs sources, which buffer overflows, and why.  I cannot find
>> > these details in your report.
>> 
>> It happens because the dump file is deliberately edited to be invalid.
>
> I didn't ask about the root cause, I asked about the details of the
> problem: where it happens in our sources, and what exactly happens.

The protection fault is in `dump_do_emacs_relocation'.  When the dump
file contains a relocation with an offset outside the heap:

	lv = make_lisp_ptr (obj_ptr, reloc.length);
	memcpy (emacs_ptr_at (reloc.emacs_offset), &lv, sizeof (lv));

will end up copying outside the heap.

Message #26 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 12:09:19 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: fuo <at> fuo.fi,  63063 <at> debbugs.gnu.org
> Date: Tue, 25 Apr 2023 16:38:19 +0800
> 
> The protection fault is in `dump_do_emacs_relocation'.  When the dump
> file contains a relocation with an offset outside the heap:
> 
> 	lv = make_lisp_ptr (obj_ptr, reloc.length);
> 	memcpy (emacs_ptr_at (reloc.emacs_offset), &lv, sizeof (lv));
> 
> will end up copying outside the heap.

Thanks, but that seems to be unrelated to the code to which the OP
pointed.  Are you sure it's the same problem?

Also, writing outside of the process's address space will indeed cause
protection fault and SIGSEGV, not a buffer-overflow type of problem
that can be exploited for executing some arbitrary code.  So I'm not
sure I see why is this a security issue?

emacs_ptr_at has this comment:

  /* TODO: assert somehow that the result is actually in the Emacs
     image.  */

Can we assure that in some reasonable way?  We have valid_pointer_p,
but that's too expensive, I think.

Message #29 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 18:55:40 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks, but that seems to be unrelated to the code to which the OP
> pointed.  Are you sure it's the same problem?

Yes: the debugger output isn't very clear because
`dump_make_lv_from_reloc' has been inlined.  Look at the program counter
in the ASAN report.

> Also, writing outside of the process's address space will indeed cause
> protection fault and SIGSEGV, not a buffer-overflow type of problem
> that can be exploited for executing some arbitrary code.  So I'm not
> sure I see why is this a security issue?

The invalid relocation could also point to an address that Emacs has
mapped, but outside any object, in which case AddressSanitizer will
report a buffer overflow.

In either case, this is not a security vulnerability: if you can make
the user load malformed dump files, you can make him load nefarious
executables as well.  It doesn't even qualify as a bug, since malformed
dump files can cause Emacs to crash in a myriad of other ways.

> emacs_ptr_at has this comment:
>
>   /* TODO: assert somehow that the result is actually in the Emacs
>      image.  */
>
> Can we assure that in some reasonable way?  We have valid_pointer_p,
> but that's too expensive, I think.

It's quite expensive.  Any such check should only be turned on
--with-checking.

Message #32 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 14:51:04 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: fuo <at> fuo.fi,  63063 <at> debbugs.gnu.org
> Date: Tue, 25 Apr 2023 18:55:40 +0800
> 
> > Also, writing outside of the process's address space will indeed cause
> > protection fault and SIGSEGV, not a buffer-overflow type of problem
> > that can be exploited for executing some arbitrary code.  So I'm not
> > sure I see why is this a security issue?
> 
> The invalid relocation could also point to an address that Emacs has
> mapped, but outside any object, in which case AddressSanitizer will
> report a buffer overflow.

That is still insufficient for tricking the program into executing
arbitrary code, AFAIU.  For that, you need to point it to an address
that is both writable and executable, arrange for that address to hold
the malicious code to be executed, and then arrange for the PC to jump
to that address.  By contrast, the only thing this code does is write
some stuff into some address, which may or may not be writable.
Where's the rest of this scenario, as part of just reading the dumper
file, whether nefarious or not?

> In either case, this is not a security vulnerability: if you can make
> the user load malformed dump files, you can make him load nefarious
> executables as well.

That's not necessarily true.  The malformed pdumper file could be
placed where Emacs usually finds it.  IOW, the perpetrator could
overwrite the pdumper file that EMacs loads when it starts.

Message #35 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 20:26:51 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> That is still insufficient for tricking the program into executing
> arbitrary code, AFAIU.  For that, you need to point it to an address
> that is both writable and executable, arrange for that address to hold
> the malicious code to be executed, and then arrange for the PC to jump
> to that address.

This is ``easy'': figure out where the stack is, replace the return
address in a certain frame with a pointer to some executable code in
your dump file.

> By contrast, the only thing this code does is write some stuff into
> some address, which may or may not be writable.  Where's the rest of
> this scenario, as part of just reading the dumper file, whether
> nefarious or not?

It's not there.

> That's not necessarily true.  The malformed pdumper file could be
> placed where Emacs usually finds it.  IOW, the perpetrator could
> overwrite the pdumper file that EMacs loads when it starts.

But then you might as well overwrite Emacs with your malicious code,
since the pdumper file is installed with the same access control as the
Emacs executable.

If you or your site administrator wants to install a virus, you can go
ahead and just do that.  There's no need to involve Emacs or pdumper
files.

Message #38 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 15:47:29 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: fuo <at> fuo.fi,  63063 <at> debbugs.gnu.org
> Date: Tue, 25 Apr 2023 20:26:51 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > That is still insufficient for tricking the program into executing
> > arbitrary code, AFAIU.  For that, you need to point it to an address
> > that is both writable and executable, arrange for that address to hold
> > the malicious code to be executed, and then arrange for the PC to jump
> > to that address.
> 
> This is ``easy'': figure out where the stack is, replace the return
> address in a certain frame with a pointer to some executable code in
> your dump file.

How do you "easily" figure out the offset from some arbitrary data
address to the current stack pointer, and do that in advance,
i.e. before the target program even runs?

> > That's not necessarily true.  The malformed pdumper file could be
> > placed where Emacs usually finds it.  IOW, the perpetrator could
> > overwrite the pdumper file that EMacs loads when it starts.
> 
> But then you might as well overwrite Emacs with your malicious code,
> since the pdumper file is installed with the same access control as the
> Emacs executable.

The pdumper file is data, not code.  It is loaded into the data
segment.  And executable code segments are usually write-protected.

> If you or your site administrator wants to install a virus, you can go
> ahead and just do that.  There's no need to involve Emacs or pdumper
> files.

I don't think this is relevant.  But based on what the code does, I
don't see why this should be considered a security issue.

Message #41 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 20:59:16 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> How do you "easily" figure out the offset from some arbitrary data
> address to the current stack pointer, and do that in advance,
> i.e. before the target program even runs?

The reason I put ``easy'' in quotes was because it's ``easy'' in the
eyes of the people running the CVE registry.  To them, any kind of bug
(or perhaps even intended crash) is a security problem.

> The pdumper file is data, not code.  It is loaded into the data
> segment.  And executable code segments are usually write-protected.

Only some kinds of CPU make the distinction between executable and
readable pages.

> I don't think this is relevant.  But based on what the code does, I
> don't see why this should be considered a security issue.

It's not, indeed.

The glaringly obvious reason being that only the site administrator, or
the user himself, can replace the dump file with something else.

Message #44 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 16:06:41 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: fuo <at> fuo.fi,  63063 <at> debbugs.gnu.org
> Date: Tue, 25 Apr 2023 20:59:16 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > The pdumper file is data, not code.  It is loaded into the data
> > segment.  And executable code segments are usually write-protected.
> 
> Only some kinds of CPU make the distinction between executable and
> readable pages.

I think this depends on the OS, not only the CPU?

> > I don't think this is relevant.  But based on what the code does, I
> > don't see why this should be considered a security issue.
> 
> It's not, indeed.
> 
> The glaringly obvious reason being that only the site administrator, or
> the user himself, can replace the dump file with something else.

I'm not sure I agree (there's the symlink attack, for example), but I
don't think it changes the nature of the issue.

Message #47 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 21:18:20 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> I think this depends on the OS, not only the CPU?

That too.

>> > I don't think this is relevant.  But based on what the code does, I
>> > don't see why this should be considered a security issue.
>> 
>> It's not, indeed.
>> 
>> The glaringly obvious reason being that only the site administrator, or
>> the user himself, can replace the dump file with something else.
>
> I'm not sure I agree (there's the symlink attack, for example), but I
> don't think it changes the nature of the issue.

How would such a ``symlink attack'' work?
And in any case:

  1. How will such a malicious .pdmp file be installed on the user's
     system?
  2. How will such a malicious .pdmp file end up loaded by the user's
     Emacs?
  3. What privileges will the user's Emacs have, that whoever installed
     the malicious .pdmp file did not?

The answers to questions 1 and 2 can only be ``by user action'', or ``by
administrative action''.  The answer to question 3 naturally follows.

Message #50 received at submit <at> debbugs.gnu.org (full text, mbox):

From: fuomag9 <fuo <at> fuo.fi>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 08:45:06 +0000

[Message part 1 (text/plain, inline)]

Hi, the CVE is currently unpublished. So when visiting this URL you’ll see that it’s reserved https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2021-36699


> On 25 Apr 2023, at 09:14, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: fuomag9 <fuo <at> fuo.fi>
>> Date: Mon, 24 Apr 2023 21:27:34 +0000
>> 
>> I’m a security researcher and I’ve searched for a way to contact the emacs security team but I’ve not found any information online, so I’m reporting this issue here.
>> I’ve discovered a buffer overflow in GNU Emacs 28.0.50 (at the time of writing the exploit still works on GNU Emacs 28.2)
>> The issue is inside the --dump-file functionality of emacs, in particular dump_make_lv_from_reloc at pdumper.c:5239
>> Attached to this email there's is payload used to make the vulnerability work (if emacs complains about a signature error you need to replace the hex bytes inside the payload with the expected one, since every emacs binary will expect a different signature).
>> This issue has been assigned CVE-2021-36699 and thus I’m notifying you of this. (I do not think the emacs team is aware of this security issue)
>> The POC is simple:
>> Launch emacs --dump-file exploit, where exploit is a custom crafted emacs dump file
> 
> Please tell more about the buffer overflow: where does it happen in
> the Emacs sources, which buffer overflows, and why.  I cannot find
> these details in your report.
> 
> Also, the CVE ID seems to be incorrect: if I look it up, I get some
> SQL related issue, not an Emacs issue.

[Message part 2 (text/html, inline)]

Message #53 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: lux <lx <at> shellcodes.org>
To: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 23:54:33 +0800

On Tue, 2023-04-25 at 21:18 +0800, Po Lu via Bug reports for GNU Emacs,
the Swiss army knife of text editors wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I think this depends on the OS, not only the CPU?
> 
> That too.
> 
> > > > I don't think this is relevant.  But based on what the code
> > > > does, I
> > > > don't see why this should be considered a security issue.
> > > 
> > > It's not, indeed.
> > > 
> > > The glaringly obvious reason being that only the site
> > > administrator, or
> > > the user himself, can replace the dump file with something else.
> > 
> > I'm not sure I agree (there's the symlink attack, for example), but
> > I
> > don't think it changes the nature of the issue.
> 
> How would such a ``symlink attack'' work?
> And in any case:
> 
>   1. How will such a malicious .pdmp file be installed on the user's
>      system?
>   2. How will such a malicious .pdmp file end up loaded by the user's
>      Emacs?
>   3. What privileges will the user's Emacs have, that whoever
> installed
>      the malicious .pdmp file did not?
> 
> The answers to questions 1 and 2 can only be ``by user action'', or
> ``by
> administrative action''.  The answer to question 3 naturally follows.
> 
> 
> 
How the vulnerability is exploited depends on the scenario and what
color hat is attacker (black hat, white hat).

Attackers do not use conventional thinking to exploit vulnerabilities,
and turn many local vulnerabilities, from 'impossible' to 'possible'.

For reference, take a look at some APT (Advanced Persistent Threat)
reports,
https://github.com/CyberMonitor/APT_CyberCriminal_Campagin_Collections

I think if the reported CVEs are real and valid, they should be taken
seriously.

Message #56 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: lux <lx <at> shellcodes.org>
Cc: luangruo <at> yahoo.com, 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 19:01:47 +0300

> From: lux <lx <at> shellcodes.org>
> Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
> Date: Tue, 25 Apr 2023 23:54:33 +0800
> 
> I think if the reported CVEs are real and valid, they should be taken
> seriously.

I agree, but in this case all I see is a convoluted way of having
Emacs crash.  That's not a security problem in my book.

Message #59 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, lux <lx <at> shellcodes.org>, fuo <at> fuo.fi,
 63063 <at> debbugs.gnu.org
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 18:17:24 +0200

>>>>> On Tue, 25 Apr 2023 19:01:47 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: lux <lx <at> shellcodes.org>
    >> Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
    >> Date: Tue, 25 Apr 2023 23:54:33 +0800
    >> 
    >> I think if the reported CVEs are real and valid, they should be taken
    >> seriously.

    Eli> I agree, but in this case all I see is a convoluted way of having
    Eli> Emacs crash.  That's not a security problem in my book.

"Itʼs a denial of service attack. You MUST fix it. Whereʼs my fee?"

(sorry, I too deal with this kind of stuff far too often).

Robert
-- 

Message #62 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: lux <lx <at> shellcodes.org>
To: Robert Pluim <rpluim <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Wed, 26 Apr 2023 00:37:33 +0800

On Tue, 2023-04-25 at 18:17 +0200, Robert Pluim wrote:
> > > > > > On Tue, 25 Apr 2023 19:01:47 +0300, Eli Zaretskii
> > > > > > <eliz <at> gnu.org> said:
> 
>     >> From: lux <lx <at> shellcodes.org>
>     >> Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
>     >> Date: Tue, 25 Apr 2023 23:54:33 +0800
>     >> 
>     >> I think if the reported CVEs are real and valid, they should
> be taken
>     >> seriously.
> 
>     Eli> I agree, but in this case all I see is a convoluted way of
> having
>     Eli> Emacs crash.  That's not a security problem in my book.
> 
> "Itʼs a denial of service attack. You MUST fix it. Whereʼs my fee?"
> 
> (sorry, I too deal with this kind of stuff far too often).
> 
> Robert

I have to face this problem every day.

Yes, I'm faced with many meaningless CVE numbers every day.

So I hope the submitter will give the details and the developer will
decide to ignore, fix urgently, or postpone the fix depending on the
level of harm.

Message #65 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 21:28:51 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > In either case, this is not a security vulnerability: if you can make
  > > the user load malformed dump files, you can make him load nefarious
  > > executables as well.

  > That's not necessarily true.  The malformed pdumper file could be
  > placed where Emacs usually finds it.  IOW, the perpetrator could
  > overwrite the pdumper file that EMacs loads when it starts.

If the pdumper file is writable by you, you could mess it up in all
sorts of ways.  You wouldn't need this feature -- you could do it with
truncate, or cat.  So I think it is incorrect to describe this feature
as being a security problem.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Previous Next

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