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

Previous Next

Full log

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.

Previous Next

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