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

Previous Next

Full log

View this message in rfc822 format

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

Eli Zaretskii <eliz <at> gnu.org> writes:

> 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.

This is ``easy'': figure out where the stack is, replace the return
address in a certain frame with a pointer to some executable code in
your dump file.

> 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?

It's not there.

> 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.

But then you might as well overwrite Emacs with your malicious code,
since the pdumper file is installed with the same access control as the
Emacs executable.

If you or your site administrator wants to install a virus, you can go
ahead and just do that.  There's no need to involve Emacs or pdumper
files.

Previous Next

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