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.