* Re: CVE-2021-36699 report [not found] ` <bcb96279c47143f403f588dc3f020725029137bd.camel@josefsson.org> @ 2023-04-24 21:27 ` fuomag9 2023-04-25 5:51 ` Po Lu ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: fuomag9 @ 2023-04-24 21:27 UTC (permalink / raw) To: bug-gnu-emacs, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CVE-2021-36699 report 2023-04-24 21:27 ` CVE-2021-36699 report fuomag9 @ 2023-04-25 5:51 ` Po Lu 2023-04-25 7:13 ` Nicolas Martyanoff 2023-04-25 6:37 ` tomas 2023-04-25 7:40 ` Yuri Khan 2 siblings, 1 reply; 7+ messages in thread From: Po Lu @ 2023-04-25 5:51 UTC (permalink / raw) To: fuomag9; +Cc: emacs-devel Please never CC the bug tracker and emacs-devel at the same time! fuomag9 <fuo@fuo.fi> writes: > Hi, > > This email was forwarded to you as suggested by 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! 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. 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. Thanks. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CVE-2021-36699 report 2023-04-25 5:51 ` Po Lu @ 2023-04-25 7:13 ` Nicolas Martyanoff 2023-04-25 7:21 ` Po Lu 0 siblings, 1 reply; 7+ messages in thread From: Nicolas Martyanoff @ 2023-04-25 7:13 UTC (permalink / raw) To: Po Lu; +Cc: fuomag9, emacs-devel 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. -- Nicolas Martyanoff https://n16f.net nicolas@n16f.net ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CVE-2021-36699 report 2023-04-25 7:13 ` Nicolas Martyanoff @ 2023-04-25 7:21 ` Po Lu 0 siblings, 0 replies; 7+ messages in thread From: Po Lu @ 2023-04-25 7:21 UTC (permalink / raw) To: Nicolas Martyanoff; +Cc: fuomag9, emacs-devel 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CVE-2021-36699 report 2023-04-24 21:27 ` CVE-2021-36699 report fuomag9 2023-04-25 5:51 ` Po Lu @ 2023-04-25 6:37 ` tomas 2023-04-25 7:11 ` Eli Zaretskii 2023-04-25 7:40 ` Yuri Khan 2 siblings, 1 reply; 7+ messages in thread From: tomas @ 2023-04-25 6:37 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1158 bytes --] On Mon, Apr 24, 2023 at 09:27:34PM +0000, fuomag9 wrote: > 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). [...] Hm. The way I see this: the dump file is part of the Emacs program. Creating a vulnerability by replacing part of a program (e.g. a shared library) seems to be possible everywhere, no? Cheers -- t [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CVE-2021-36699 report 2023-04-25 6:37 ` tomas @ 2023-04-25 7:11 ` Eli Zaretskii 0 siblings, 0 replies; 7+ messages in thread From: Eli Zaretskii @ 2023-04-25 7:11 UTC (permalink / raw) To: tomas; +Cc: emacs-devel > Date: Tue, 25 Apr 2023 08:37:32 +0200 > From: <tomas@tuxteam.de> > > Hm. The way I see this: the dump file is part of the > Emacs program. Creating a vulnerability by replacing > part of a program (e.g. a shared library) seems to be > possible everywhere, no? Please, everybody, don't respond to this on emacs-devel, only on the bug list. Thanks. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CVE-2021-36699 report 2023-04-24 21:27 ` CVE-2021-36699 report fuomag9 2023-04-25 5:51 ` Po Lu 2023-04-25 6:37 ` tomas @ 2023-04-25 7:40 ` Yuri Khan 2 siblings, 0 replies; 7+ messages in thread From: Yuri Khan @ 2023-04-25 7:40 UTC (permalink / raw) To: fuomag9; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-04-25 7:40 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <40-63e3c600-3-2d802d00@111202636> [not found] ` <01070187b503303f-1657dcaa-4f53-47da-9679-2f68a682d447-000000@eu-central-1.amazonses.com> [not found] ` <bcb96279c47143f403f588dc3f020725029137bd.camel@josefsson.org> 2023-04-24 21:27 ` CVE-2021-36699 report fuomag9 2023-04-25 5:51 ` Po Lu 2023-04-25 7:13 ` Nicolas Martyanoff 2023-04-25 7:21 ` Po Lu 2023-04-25 6:37 ` tomas 2023-04-25 7:11 ` Eli Zaretskii 2023-04-25 7:40 ` Yuri Khan
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).