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>
> Cc: fuo <at> fuo.fi, 63063 <at> debbugs.gnu.org
> 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.
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.
This bug report was last modified 2 years and 56 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.