bug#63063: CVE-2021-36699 report

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: fuo@fuo.fi,  63063@debbugs.gnu.org
> Date: Tue, 25 Apr 2023 20:26:51 +0800
> 
> Eli Zaretskii <eliz@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.

How do you "easily" figure out the offset from some arbitrary data
address to the current stack pointer, and do that in advance,
i.e. before the target program even runs?

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

The pdumper file is data, not code.  It is loaded into the data
segment.  And executable code segments are usually write-protected.

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

I don't think this is relevant.  But based on what the code does, I
don't see why this should be considered a security issue.