Re: CVE-2021-36699 report

Re: CVE-2021-36699 report

[fuomag9]

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

Hi,

This email was forwarded to you as suggested by simon@josefsson.org <mailto:simon@josefsson.org> as I was forwarded to this person when contacting security@gnu.org



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).
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
Here's the program execution via GDB
Starting program: /home/fuomag9/emacs-std/src/emacs --dump-file
exploit_p1/3_1.dat
ERROR: Could not find ELF base!
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x000055555567d66e in dump_make_lv_from_reloc (reloc=...,
dump_base=140737341673472) at pdumper.c:5239
5239 && reloc.type < RELOC_DUMP_TO_EMACS_LV)
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
────────────────────────────────────────────────────────────────────────────[
REGISTERS ]─────────────────────────────────────────────────────────────────────────────
RAX 0x24
RBX 0x555555b19ed8 (globals+2008) ◂— 0x0
RCX 0x9
RDX 0x7ffff7bcafe0 (deflateParams+320) ◂— mov dword ptr [rdi + rdx*2], eax
RDI 0x8000089de224
RSI 0x7ffff741d000 ◂— 'DUMPEDGNUEMACS'
R8 0x555555b6c8b0 ◂— 0x0
R9 0x555555b6c8b0 ◂— 0x0
R10 0x12
R11 0x7ffff7b2ac00 (main_arena+96) —▸ 0x555555b6c970 ◂— 0x0
R12 0x7ffff7bcafe4 (deflateParams+324) ◂— mov edx, eax
R13 0x7ffff741d000 ◂— 'DUMPEDGNUEMACS'
R14 0x7ffff7d49e78 ◂— add byte ptr [rax], al
R15 0x7ffff751d000 ◂— 0x0
RBP 0x555555b1c2e0 (lispsym) ◂— 0x0
RSP 0x7fffffffdf30 —▸ 0x7fffffffe0c0 ◂— 0x3
RIP 0x55555567d66e (dump_do_all_dump_reloc_for_phase+78) ◂— mov rdx,
qword ptr [rdi]
──────────────────────────────────────────────────────────────────────────────[
DISASM ]──────────────────────────────────────────────────────────────────────────────
► 0x55555567d66e mov rdx, qword ptr [rdi] <0x7ffff7bcafe0>
0x55555567d671 and eax, 0x1f
0x55555567d674 cmp al, 7
0x55555567d676 ja dump_do_all_dump_reloc_for_phase+224
<dump_do_all_dump_reloc_for_phase+224>
↓
0x55555567d700 sub ecx, 0xd
0x55555567d703 lea rax, [rdx + rbx]
0x55555567d707 jmp dump_do_all_dump_reloc_for_phase+100
<dump_do_all_dump_reloc_for_phase+100>
↓
0x55555567d684 mov rdx, rax
0x55555567d687 mov esi, ecx
0x55555567d689 sub rdx, rbp
0x55555567d68c add rax, rsi
──────────────────────────────────────────────────────────────────────────[
SOURCE (CODE) ]───────────────────────────────────────────────────────────────────────────
In file: /home/fuomag9/emacs-std/src/pdumper.c
5234 const struct dump_reloc reloc)
5235 {
5236 const dump_off reloc_offset = dump_reloc_get_offset (reloc);
5237 uintptr_t value = dump_read_word_from_dump (dump_base, reloc_offset);
5238 enum Lisp_Type lisp_type;
► 5239
5240 if (RELOC_DUMP_TO_DUMP_LV <= reloc.type
5241 && reloc.type < RELOC_DUMP_TO_EMACS_LV)
5242 {
5243 lisp_type = reloc.type - RELOC_DUMP_TO_DUMP_LV;
5244 value += dump_base;
──────────────────────────────────────────────────────────────────────────────[
STACK ]───────────────────────────────────────────────────────────────────────────────
00:0000│ rsp 0x7fffffffdf30 —▸ 0x7fffffffe0c0 ◂— 0x3
01:0008│ 0x7fffffffdf38 ◂— 0x3
02:0010│ 0x7fffffffdf40 —▸ 0x7fffffffdfc0 ◂— 'DUMPEDGNUEMACS'
03:0018│ 0x7fffffffdf48 —▸ 0x7fffffffe168 ◂— 0x3f /* '?' */
04:0020│ 0x7fffffffdf50 ◂— 0x0
05:0028│ 0x7fffffffdf58 —▸ 0x555555683e63 (pdumper_load+1523) ◂— mov
eax, dword ptr [rsp + 0xb4]
06:0030│ 0x7fffffffdf60 ◂— 0x60e99c8c
07:0038│ 0x7fffffffdf68 ◂— 0x60e9d68
────────────────────────────────────────────────────────────────────────────[
BACKTRACE ]─────────────────────────────────────────────────────────────────────────────
► f 0 0x55555567d66e dump_do_all_dump_reloc_for_phase+78
f 1 0x55555567d66e dump_do_all_dump_reloc_for_phase+78
f 2 0x55555567d66e dump_do_all_dump_reloc_for_phase+78
f 3 0x555555683e63 pdumper_load+1523
f 4 0x555555587c10 main+2880
f 5 0x555555587c10 main+2880
f 6 0x7ffff7972565 __libc_start_main+213

Below is the execution with the ASAN address sanitizer showing the
global buffer overflow:

==25852==ERROR: AddressSanitizer: global-buffer-overflow on address
0x56099125b830 at pc 0x7fc6db6862d3 bp 0x7ffe24fa83a0 sp
0x7ffe24fa7b48
WRITE of size 226929408 at 0x56099125b830 thread T0
#0 0x7fc6db6862d2 in __interceptor_memcpy
../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
#1 0x560990ba5258 in dump_do_emacs_relocation
(/home/fuomag9/emacs-asan/src/emacs+0x457258)
#2 0x560990ba5aa1 in dump_do_all_emacs_relocations
(/home/fuomag9/emacs-asan/src/emacs+0x457aa1)
#3 0x560990ba67ea in pdumper_load (/home/fuomag9/emacs-asan/src/emacs+0x4587ea)
#4 0x560990a5986a in load_pdump (/home/fuomag9/emacs-asan/src/emacs+0x30b86a)
#5 0x560990a5b167 in main (/home/fuomag9/emacs-asan/src/emacs+0x30d167)
#6 0x7fc6db006564 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x28564)
#7 0x56099082f00d in _start (/home/fuomag9/emacs-asan/src/emacs+0xe100d)
0x56099125b830 is located 0 bytes to the right of global variable
'globals' defined in 'alloc.c:283:22' (0x56099125aa80) of size 3504
0x56099125b830 is located 48 bytes to the left of global variable
'consing_until_gc' defined in 'alloc.c:287:11' (0x56099125b860) of
size 8
SUMMARY: AddressSanitizer: global-buffer-overflow
../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
in __interceptor_memcpy
Shadow bytes around the buggy address:
0x0ac1b22436b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ac1b22436c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ac1b22436d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ac1b22436e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ac1b22436f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ac1b2243700: 00 00 00 00 00 00[f9]f9 f9 f9 f9 f9 00 f9 f9 f9
0x0ac1b2243710: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9
0x0ac1b2243720: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
0x0ac1b2243730: 00 00 00 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 f9
0x0ac1b2243740: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
0x0ac1b2243750: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
I look forward your promptly response.
Best regards,
fuomag9



[-- Attachment #2.1: Type: text/html, Size: 29241 bytes --]

[-- Attachment #2.2: PAYLOAD --]
[-- Type: application/octet-stream, Size: 1048576 bytes --]

[-- Attachment #2.3: Type: text/html, Size: 212 bytes --]

bug#63063: CVE-2021-36699 report

[Eli Zaretskii]

> From: fuomag9 <fuo@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.

bug#63063: CVE-2021-36699 report

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@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.

bug#63063: CVE-2021-36699 report

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: fuomag9 <fuo@fuo.fi>,  63063@debbugs.gnu.org
> Date: Tue, 25 Apr 2023 15:24:31 +0800
> 
> Eli Zaretskii <eliz@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?

bug#63063: CVE-2021-36699 report

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: fuomag9 <fuo@fuo.fi>,  63063@debbugs.gnu.org
>> Date: Tue, 25 Apr 2023 15:24:31 +0800
>> 
>> Eli Zaretskii <eliz@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.

bug#63063: CVE-2021-36699 report

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: fuo@fuo.fi,  63063@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.

bug#63063: CVE-2021-36699 report

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@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.

bug#63063: CVE-2021-36699 report

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: fuo@fuo.fi,  63063@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.

bug#63063: CVE-2021-36699 report

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@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.

bug#63063: CVE-2021-36699 report

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: fuo@fuo.fi,  63063@debbugs.gnu.org
> Date: Tue, 25 Apr 2023 20:26:51 +0800
> 
> Eli Zaretskii <eliz@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.

bug#63063: CVE-2021-36699 report

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@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.

bug#63063: CVE-2021-36699 report

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: fuo@fuo.fi,  63063@debbugs.gnu.org
> Date: Tue, 25 Apr 2023 20:59:16 +0800
> 
> Eli Zaretskii <eliz@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.

bug#63063: CVE-2021-36699 report

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@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.

bug#63063: CVE-2021-36699 report

[lux]

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@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.

bug#63063: CVE-2021-36699 report

[Eli Zaretskii]

> From: lux <lx@shellcodes.org>
> Cc: 63063@debbugs.gnu.org, fuo@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.

bug#63063: CVE-2021-36699 report

[Robert Pluim]

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

    >> From: lux <lx@shellcodes.org>
    >> Cc: 63063@debbugs.gnu.org, fuo@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
-- 

bug#63063: CVE-2021-36699 report

[lux]

On Tue, 2023-04-25 at 18:17 +0200, Robert Pluim wrote:
> > > > > > On Tue, 25 Apr 2023 19:01:47 +0300, Eli Zaretskii
> > > > > > <eliz@gnu.org> said:
> 
>     >> From: lux <lx@shellcodes.org>
>     >> Cc: 63063@debbugs.gnu.org, fuo@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.

bug#63063: CVE-2021-36699 report

[Richard Stallman]

[[[ 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)

bug#63063: CVE-2021-36699 report

[fuomag9 via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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@gnu.org> wrote:
> 
>> From: fuomag9 <fuo@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.


[-- Attachment #2: Type: text/html, Size: 2102 bytes --]

bug#63063: CVE-2021-36699 report

[Eli Zaretskii]

> From: Nicolas Martyanoff <nicolas@n16f.net>
> Cc: fuomag9 <fuo@fuo.fi>,  emacs-devel@gnu.org
> Date: Tue, 25 Apr 2023 09:13:34 +0200
> 
> Po Lu <luangruo@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.

bug#63063: CVE-2021-36699 report

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: fuomag9 <fuo@fuo.fi>,  emacs-devel@gnu.org
> Date: Tue, 25 Apr 2023 15:21:27 +0800
> 
> Nicolas Martyanoff <nicolas@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!!

bug#63063: CVE-2021-36699 report

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Tue, 25 Apr 2023 14:40:20 +0700
> Cc: emacs-devel@gnu.org
> 
> On Tue, 25 Apr 2023 at 12:33, fuomag9 <fuo@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.