| Summary: | Stack-buffer-overwrite when parsing a malicious tiff file in XPS file | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Elias Myllymäki <elias.myllymaki04> |
| Component: | Security (public) | Assignee: | Chris Liddell (chrisl) <chris.liddell> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | carnil, dr, jsmeix, ken.sharp, marc.deslauriers, robin.watts, sam, till.kamppeter, zdohnal |
| Priority: | P2 | ||
| Version: | unspecified | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: | Stack buffer overflow XPS file. | ||
|
Description
Elias Myllymäki
2025-09-08 16:35:03 UTC
> Is this bug under bounty?
If you want to claim it as an RCE bounty then we'll need to see something which actually executes code on the host, using a reasonably normal build of Ghostscript.
I've pushed this commit 99727069197d548a8db69ba5d63f766bff40eaab to address this, so we can discuss what happens next at leisure. Hi! You need to define what a "normal" build is more specifically. If the binary has ASLR and/or stack canaries, then this bug by itself is not exploitable, since you would need to chain it with an information leak bug to get the base address and/or the stack canary. Executable stack (the absence of the NX bit) makes exploitation easier, but is not strictly necessary, but disabling ASLR and stack canaries are mandatory to exploit this bug as far as I can tell. In the meantime I will start developing an exploit for a build of gxps which has aslr disabled and no stack canaries but does not have executable stack. Of course this bug is still dangerous since this bug is still the "trigger" of an RCE exploit, but you lack the required information to exploit it in an ASLR environment or with stack canaries so you would have to chain it with other bugs. If an exploit needs to work with aslr and stack canaries, then this bug does not classify as RCE, so in this case feel free to classify this as a non-rce bug. Thanks in advance! (In reply to Elias Myllymäki from comment #3) > You need to define what a "normal" build is more specifically. I did say 'reasonably' normal, essentially not modifying the source code or build environment to disable protections, or including 3rd party libraries other than the versions we ship. > NX bit) makes exploitation easier, but is not strictly necessary, but > disabling ASLR and stack canaries are mandatory to exploit this bug as far > as I can tell. OK so you'd need to turn off protections which would (IMO) normally be present. At least these days, anyway, I am aware that wasn't always true. > In the meantime I will start developing an exploit for a > build of gxps which has aslr disabled and no stack canaries but does not > have executable stack. Please don't go to lots of effort. From what you say this wouldn't be classified by us as a remote code execution bug (I may be misunderstanding you, obviously I am not a security researcher) > If an exploit needs to work with aslr and stack canaries, then this bug does > not classify as RCE, so in this case feel free to classify this as a non-rce > bug. OK I can go ahead and add this to my list, and now that we've classified it, and finished the release, I can put that list forward for approval. I need to take this up with some people in the US, but you should expect to hear from me by private email in the near future; there are some steps we (the company, not me specifically) need to go through in order to pay bounties. Obviously we'll need banking details, we have money laundering hoops to jump through and I think that we need a declaration from non-US citizens in order to avoid the IRS taking a cut. I'm assuming you are not a US citizen.... Please do not post anything here, obviously, or direct to me, I'll make sure the accounts people contact you, and I'll alert you beforehand who to expect email from. Hi! Whoops, I meant that this vulnerability would not cause remote command execution in isolation. This vulnerability is usually considered a remote command execution one, but you would need to chain it with other info leak bugs in order for it to work. The best analogy I can come up with is that this bug is the round and the information leak bug(s) is the gun. The round isn't by itself deadly and can at most cause the program to just crash, but combined with the information leak bug(s) it becomes dangerous. Even though the round itself is not deadly, it doesn't erase the fact that without it the gun is useless and it is the most important part when trying to shoot. What I am trying to say is that the buffer overflow is the most important part of such an exploit chain and basically the linchpin of binary exploitation attacks. A stack buffer overflow is one of the most common ways an attacker can gain control of the instruction pointer register (RIP) which is the beating heart of binary exploitation. Practically all binary exploits first overwrite the stack or heap such that instead of returning back to the original caller, the program "returns" to an attacker controlled address. Now, the difficulty is in knowing which address to "return" to. This is the reason why such a bug is chained with an information leak bug in order to leak an address off of the heap or stack to figure out the "base address" of the module which then is used in a so called "ROP-chain" in order to piece small pieces of machine code called gadgets in a chain which ultimately call some function like "system" with "/bin/sh" as the argument to get a shell or execute arbitrary code. Of course one also needs to circumvent the stack canary protection with a similar information leak bug in order to write the correct canary byte such that the stack protector doesn't kill your exploit attempt but I digress. My main point is that this is the main bug needed for remote command execution, but you need extra information achieved via other bugs in order to exploit it. Without such a bug, command execution can not be achieved. So since this needs to be chained with other bugs to get remote command execution, I guess the final classification depends on if you consider each bug separately or together, since combined with other bugs you actually can achieve remote command execution. If separately, then this could lead to a situation where a group of bugs are all considered not remote command execution even though they would cause RCE in combination. So it depends on your definitions. Thanks in advance! Also, If I find such an infoleak and I am then able to exploit this vulnerability in combination with such a bug and actually cause RCE on a machine with ASLR, stack canaries and NX bit all enabled, then does this bounty apply retroactively? This complicates things since then you would have to consider such an infoleak as a "part" of this bug (maybe?) so I am not sure. (In reply to Elias Myllymäki from comment #6) > Also, If I find such an infoleak and I am then able to exploit this > vulnerability in combination with such a bug and actually cause RCE on a > machine with ASLR, stack canaries and NX bit all enabled, then does this > bounty apply retroactively? This complicates things since then you would > have to consider such an infoleak as a "part" of this bug (maybe?) so I am > not sure. All the remote code execution bugs reported to date have been 'stand-alone', none have required any other bug to be present in order to be demonstrated. Nor have they required us to build Ghostscript in particular ways. In general my feeling (and this is just me) is that a RCE bug needs to be stand-alone. But I'd take each case on its merits, I wouldn't want this to be taken as an absolute position. Which isn't to say that I don't think this is serious. While I haven't rated it as highly as the previous RCE bug reports, I have rated it more highly than your other reports, and well up the scale that we are able to afford. I've started the process of getting all the accumulated reports to date approved, but I'm not certain if our CEO is currently in Korea or the US, if Korea then this will take a little longer to filter through the email chain. I've asked one of my colleagues to request a CVE for this bug report. Unfortunately it is taking a long time for MITRE to assign us CVEs at the moment, we are still waiting for several others. |