Bug 707510

(In reply to Thomas Rinsma from comment #0)

> Hi, a few friends and I found several vulnerabilities in Ghostscript.
> Hopefully it’s alright to combine vulnerabilities like this in one report,
> if you’d rather have them separated let me know.

Not to worry for this report, but in future we'd really prefer one report per bug. It makes it much easier to divide up assignments between developers, makes sure we don't miss a part of the report, and generally makes the whole thing easier to manage.

A couple of points in passing (again for future reports); we need a command line to demonstrate the problem, you haven't supplied a command line for any of these. 

At least the first of the PostScript files, as supplied, can't reach the point of causing a problem because it opens a file on disk and writes to it, which immediately fails unless -dNOSAFER is set or read+write permission is granted for that specific file.

It would be better simply to provide the PDF file, rather than have a PostScript file write it, because file systems differ. Even with permissions granted to it, that PostScript file won't run on my system because it isn't able to open the directory (/tmp doesn't exist). I've had to modify the file to make it exhibit here.

Yes, I'm aware that means I'll have to modify the PostScript program to point to the PDF file, but I'd prefer to do that than have random PostScript programs writing to my file system, that's what SAFER is all about after all.

> Not to worry for this report, but in future we'd really prefer one report per bug.

Thanks, noted.

> we need a command line to demonstrate the problem, you haven't supplied a command line for any of these.

My apologies. My underlying assumption for all of these is a regular invocation of ghostscript (i.e. with -dSAFER) without any specific flags.


> Yes, I'm aware that means I'll have to modify the PostScript program to point
> to the PDF file, but I'd prefer to do that than have random PostScript
> programs writing to my file system, that's what SAFER is all about after all.

I may be misunderstanding, but I thought the "temp" directory (/tmp/ on Linux) is intentionally always R+W allowed with a wildcart. I did not need to modify the allowed paths list for these examples to work on my machine.

For at least the buffer overflows I suppose it would even be possible to do this without a wildcart allowed folder like /tmp/, but using %mem% and .PDFStream instead (but I did not test this).

> It would be better simply to provide the PDF file, rather than have a PostScript file write it,

The reason for doing it this way, is that the command line arguments do not need to be under attacker control, but only the contents of the input file.

(In reply to Thomas Rinsma from comment #3)

> > Yes, I'm aware that means I'll have to modify the PostScript program to point
> > to the PDF file, but I'd prefer to do that than have random PostScript
> > programs writing to my file system, that's what SAFER is all about after all.
> 
> I may be misunderstanding, but I thought the "temp" directory (/tmp/ on
> Linux) is intentionally always R+W allowed with a wildcart. I did not need
> to modify the allowed paths list for these examples to work on my machine.

I'm not on Linux.....

If that's the temp directory then yes it is permitted, but its not the temp directory on my OS (obviously, since it doesn't exist).

Note that your PoC would therefore only work on Linux. On Windows it throws an invalidfileaccess error.


> For at least the buffer overflows I suppose it would even be possible to do
> this without a wildcart allowed folder like /tmp/, but using %mem% and
> .PDFStream instead (but I did not test this).

You could use the ram file system %ramfs%. I believe that's always read/write (I ought to check that....)


> The reason for doing it this way, is that the command line arguments do not
> need to be under attacker control, but only the contents of the input file.

See above.

But fundamentally I just want a way I can reproduce the problem, and for me that's easiest by simply supplying the PDF file.

Created attachment 25256 [details]
PDF files

> I'm not on Linux.....

> Note that your PoC would therefore only work on Linux.
> On Windows it throws an invalidfileaccess error.

I understand! Just giving an example of my system, hence why I specified it as the general "temp" directory. From the code (gs_init.ps) it looks like this is the default/fallback if the system does not specify another directory:

```
/tempfilepaths
[
  (TMPDIR) getenv not
  {
    (TEMP) getenv not
    {
      (TMP) getenv not
      {
        (/temp) (/tmp)
      } if
    } if
  } if
] def
```

> But fundamentally I just want a way I can reproduce the problem,
> and for me that's easiest by simply supplying the PDF file.

Understood! If your system has an equivalent temp directory then it would be a matter of modifying the path accordingly. If it does not then the best approach would probably be to simulate one by adding a R+W path that you can write to, to the allowlist.

I don't think it's possible to PoC vulnerability (1) using just the command-line, as it requires a string with a null-byte in the middle.

For (2), I've attached the PDF by itself. You can trigger this one using `-dPDFDEBUG`.

For (3) I don't think it's possible using the command-line as it would become too long (at least on my system).

For (4) I've attached the PDF. You can run it with `-dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=out.pdf` and manually see the pointer in the output file.

As for (5), this one relies on being able to create at least the configuration file, so it would require an R+W-allowed directory similarly to (1).

(In reply to Thomas Rinsma from comment #6)

I don't really want this to spiral onwards, because (if nothing else) it sounds like I'm being unreasonably critical, and I really don't want to discourage anyone from reporting bugs.

But....

> I don't think it's possible to PoC vulnerability (1) using just the
> command-line, as it requires a string with a null-byte in the middle.

You can put arbitrary PostScript on the command line too, using -c and -f

 
> For (2), I've attached the PDF by itself. You can trigger this one using
> `-dPDFDEBUG`.
> 
> For (3) I don't think it's possible using the command-line as it would
> become too long (at least on my system).

Here you can use the @file syntax to have a file which contains a command line that would otherwise be too long for the shell.

 
> For (4) I've attached the PDF. You can run it with `-dBATCH -dNOPAUSE
> -sDEVICE=pdfwrite -sOutputFile=out.pdf` and manually see the pointer in the
> output file.
> 
> As for (5), this one relies on being able to create at least the
> configuration file, so it would require an R+W-allowed directory similarly
> to (1).

Again, I'm not totally worried by having to create files, though it would be useful to be warned that's the case; otherwise I just get an 'invalidfileaccess' error and have to go looking to see if that means the problem is already fixed or the PoC needs adjusting.

Simply saying that, where possible, it is easier for me at least if we can just have the file causing the problem and a command line, rather than a carefully crafted PostScript file to demonstrate that you don't need to control the command line, we're prepared to take that on trust.

> Simply saying that, where possible, it is easier for me at least if we can
> just have the file causing the problem and a command line, rather than a
> carefully crafted PostScript file to demonstrate that you don't need to
> control the command line, we're prepared to take that on trust.

In my mind the command line (i.e. lack of extra flags) is really part of the problem, as it shows the control an attacker has on a vanilla system with just control over the input file, that is the concept that these proofs-of-concept prove. The threat model is a headless (I suppose usually Linux-)system that uses Ghostscript for file conversion.

> Again, I'm not totally worried by having to create files,
> though it would be useful to be warned that's the case;

Apologies, I thought it would be clear from the descriptions and PoCs.

Created attachment 25271 [details]
In-memory / tempfile versions of PoCs 1-4

Latest attachment is a set of PoCs for vulnerabilities 1-4 that only use `%ram%` and `tempfile`. This should hopefully make them a bit more portable.

(In reply to Thomas Rinsma from comment #10)
> Latest attachment is a set of PoCs for vulnerabilities 1-4 that only use
> `%ram%` and `tempfile`. This should hopefully make them a bit more portable.

I really didn't mean for you to go to this effort with this report, my comments were intended only as guidance for future reports (and for others should they read this).

But the PDF for #4 was very welcome, saved me having to extract it.

So these commits:
917b3a71fb20748965254631199ad98210d6c2fb
77dc7f699beba606937b7ea23b50cf5974fa64b1
ff1013a0ab485b66783b70145e342a82c670906a

Should fix items 1, 2 and 4 respectively.

This additional commit:
d99396635f3d6ac6a1168e1af21a669e5c8f695f

should mean that builds using LIBIDN will work even when it throws a non-fatal error (I'm unable to test that).

Chris has commits in progress for items 3 and 5.

Great! For the `apply_sasl` fix: I am not 100% sure but isn't it still missing a memcpy from `Password` to `buffer`, after allocation of `buffer` and before stringprep?

(In reply to Thomas Rinsma from comment #13)
> Great! For the `apply_sasl` fix: I am not 100% sure but isn't it still
> missing a memcpy from `Password` to `buffer`, after allocation of `buffer`
> and before stringprep?

Might be, I'm not at all sure how that is supposed to work and as I said, I can't test it.

But if so presumably it fails and we will just use the supplied password.

Issue 3 is addressed in:
https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=7745dbe24514


Issue 5 addressed in:
https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=3d4cfdc1a44


I believe that covers all the issues in this report.


Thanks for reporting these, we do appreciate it!

(In reply to Chris Liddell (chrisl) from comment #15)

Thanks both for these quick fixes! Looking at the patches they indeed seem sufficient.

On the process side, what are the next steps? Do you have an existing process for requesting CVEs and contacting distro maintainers / users?

(In reply to Thomas Rinsma from comment #16)

> On the process side, what are the next steps? Do you have an existing
> process for requesting CVEs and contacting distro maintainers / users?

We generally only request CVEs ourselves if there's something dramatic needing fixing that we would plan on doing an out of band release for (partly to have a pointy stick to poke customers with, so they upgrade).

I wasn't planning on a patch release myself, don't know how Chris feels about it. The next scheduled release is in March anyway.

Given the proximity of the next release we'd probably prefer not to make a public disclosure just yet, as that would force us into making a patch release. We're probably looking at something like 6 weeks before the next release should be out.

And yeah, I know making commits to the Git repository is, in a sense, already public. That's a problem we haven't got a good answer for yet. We don't really want to try and maintain a private repository at the same time.


There are a number of package maintainers automagically CC'ed on security bug reports (you may be able to view the CC list, I'm not certain), so those maintainers are aware and can port/backport these commits as they feel appropriate.

And to echo Chris, thanks for making the report. However curmudgeonly I may sound, we really do appreciate these!

(In reply to Ken Sharp from comment #17)

> We generally only request CVEs ourselves if there's something dramatic
> needing fixing that we would plan on doing an out of band release for
> (partly to have a pointy stick to poke customers with, so they upgrade).

I understand the approach, but in my opinion this case warrants the patch release. I work at a small security lab and by chance we have two clients right now that are seriously affected by this (respectively using Imagemagick and Libreoffice for file conversion on web platforms). The file read/write would be a high severity issue for both. Based on this I expect there will be many others out there.

I would feel quite uncomfortable with this being out there for two months, especially with these public fixes.

> And to echo Chris, thanks for making the report. However curmudgeonly I may
> sound, we really do appreciate these!

Happy to help, and all good! I understand the importance of a reproducible report :)

Any updates on the decision regarding a patch release? If needed, we can help get the CVEs requested.

I would strongly advocate for publicly classifying these issues as security issues (with the associated severity) such that users are aware and can prioritize updating. Again, the overall impact is quite high as many document/image conversion platforms are likely vulnerable (think Google Docs, Slack, etc).

For your information, we have requested CVEs for these vulnerabilities.

CVEs have been assigned as follows (numbering from the initial report):

1 - CVE-2024-29509
2 - CVE-2024-29506
3 - CVE-2024-29507
4 - CVE-2024-29508
5 - CVE-2024-29511

Would you be able to indicate these somewhere or make this ticket public, such that people can cross-reference the issues with the fixes?