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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 14:51:04 +0300

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

Previous Next

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