Created attachment 12981 [details] putdeviceparams.ps Tavis Ormandy reported another -dSAFER bypass: http://www.openwall.com/lists/oss-security/2016/09/30/8 commit 1fae53a708fca6c2ac0417bc23f5d095cc379250 Author: Chris Liddell <chris.liddell@artifex.com> Date: Thu Jul 30 17:27:23 2015 +0100 Bug 696101: fix uses of the sfopen API. The stream API in GS is defined as *always* opening files in binary mode, where applicable, so there is no need for the API clients to specify binary mode. This is previously been benign, and thus ignored, but reportedly ending up with a duplicate 'b' character in the mode causes a crash on Windows 10. No cluster differences. I'm attaching the reproducer from the oss-security posting. Before the commit, the file is only opened, with potential directory traversal, so this should be fixed as well, but the impact is greatly reduced.
'b' in the mode argument causes glibc's popen to fail, which is why this commit exposed the code execution bug on GNU/Linux. For other systems, there may be code execution even before this change.
I'm baffled about what you are reporting. What is the attack vector here - bearing in mind that the parameter being set is supposed to be an ICC profile file, and something that *isn't* a valid ICC profile will cause an error to occur.
The problem is that this entirely defeats -dSAFER, and permits arbitrary command execution in any application that uses -dSAFER to process untrusted documents (ImageMagick, cups, gimp, evince and dozens of other automated document processing systems). https://codesearch.debian.net/search?q=-dSAFER&perpkg=1 The attached reproducer works perfectly for me every time with gs -dSAFER in 9.18 and higher?
(In reply to Tavis Ormandy from comment #3) > The problem is that this entirely defeats -dSAFER, and permits arbitrary > command execution I don't see how that's the case. An ICC profile is just data, it is not "interpreted" in the way that Postscript is.
It's the pathname that's the problem, not the data. You can see in the example that %pipe% is used and that's interpreted as a special device (like %stdin%, %null%, etc). Can you repro the testcase? We're in agreement that -dSAFER should prevent an untrusted file from being able to run shell commands, right?
Yeh, I see what you're getting at, and yes, I agree it's a problem. This is going to take some thought as this is done at a rather lower level than SAFER is currently handled. This is beyond the scope of what SAFER was originally conceived to protect.
As Florian points out, it might also be necessary to have ICC profiles checked against PermitFileReading, because you can set an arbitrary directory like this: << (ICCProfilesDir) (whatever) >> .setuserparams Just thought I'd mention it while you're thinking about it :-)
Fixed in: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=71ac874