Re: CVE-2021-36699 report

[Po Lu]

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.