Ghostscript Zero-Day Allows Full Server Compromises (therecord.media) 40
Proof-of-concept exploit code was published online over the weekend for an unpatched Ghostscript vulnerability that puts all servers that rely on the component at risk of attacks. From a report: Published by Vietnamese security researcher Nguyen The Duc, the proof-of-concept code is available on GitHub and was confirmed to work by several of today's leading security researchers. Released back in 1988, Ghostscript is a small library that allows applications to process PDF documents and PostScript-based files. While its primary use is for desktop software, Ghostscript is also used server-side, where it is typically included with image conversion and file upload processing toolkits, such as the popular ImageMagick. The proof-of-concept code released by Nguyen on Sunday exploits this latter scenario, allowing an attacker to upload a malformed SVG file that escapes the image processing pipeline and runs malicious code on the underlying operating system. While Nguyen released the public exploit for this bug, he is not the one who discovered the vulnerability.
turn it off on Debian / partial work around maybe (Score:3)
sudo chmod -x `which ghostscript` .so | sudo xargs chmod a-r /usr/lib/ghostscript/9.50/X11.so
dpkg --listfiles libgs9 | grep
chmod a-r
what more? (BTW do not trust code in random comments on Slashdot)
Re: turn it off on Debian / partial work around ma (Score:2)
grep \.so$
Re: (Score:2)
#!/bin/bash
sudo chmod a-x `which gs`
sudo chmod a-x `which ghostscript` # symlink - this should do nothing extra
echo by running this script from the internet without checking it I accept I am
echo the problem with humanity and promise all my money to alerunner
dpkg --listfiles libgs9 | grep '\.so' | sudo xargs chmod a-r
dpkg --listfiles ghostscript-x | grep '\.so' | sudo xargs chmod a-r
If you allow it to (Score:3)
Reading through the summary and TFA, the exploit will work if:
1. You allow someone to drop an arbitrary file (an SVG in this case) on the system
2. You allow them to cause that file to be processed by an application that runs Ghostscript
3. You allow the user that application would run under high enough privileges to affect your operating system.
I would not say this is a difficult or impossible situation to have, if you haven't been paying attention to the world. But, any idiot can run a server, as evidenced by how many of them do, so I guess it's dangerous.
Re:If you allow it to (Score:5, Interesting)
Reading through the summary and TFA, the exploit will work if:
1. You allow someone to drop an arbitrary file (an SVG in this case) on the system
2. You allow them to cause that file to be processed by an application that runs Ghostscript
3. You allow the user that application would run under high enough privileges to affect your operating system.
I would not say this is a difficult or impossible situation to have, if you haven't been paying attention to the world. But, any idiot can run a server, as evidenced by how many of them do, so I guess it's dangerous.
1) someone sends you a mail with a picture in it
2) you print the contents of that picture
3) we can hope.. but who knows; when did you last study the list of all applications which embed use of ghostscript?
Generally - lock down first; analyse next; open up when you actually know what the problem is.
Re: (Score:3)
Next questions what is print daemon running as? Does it apply 'filters' automatically if certain file types are spooled? Assuming its not root, does it start and suid process - do any of those things use ghostscript...
Things are better today but common Linux print stacks from not-all-that-long-ago, maybe a decade? Would likely be vulnerable.
Re:If you allow it to (Score:4, Informative)
3. You allow the user that application would run under high enough privileges to affect your operating system.
This is the key problem right here. Very little stuff needs to be installed as root (admin). Even less needs to be run as such on a properly designed OS. My web server runs as an untrusted user. As do any server side executables launched by incoming requests (I can even arrange to have these run as an even less trusted user).
any idiot can run a server
This is the root cause of the above key problem.
Re: (Score:3)
If they can compromise even an unprivileged user account, that gives a platform to find other bugs on your system, particularly privilege escalation bugs that could lead to a compromise of a superuser account.
Re: (Score:2)
This is a good security principle in general, but even more important in this specific case.
PostScript and PDF are code, Ghostscript is an interpreter, and anything that can understand PS and/or PDF is thereby capable of running untrusted code by its very nature. It has to in order to do its job.
Pretty sure this applies equally to PDF readers embedded in Web browsers unless they are careful to sandbox them, as well as those running under Windows, Mac, Android, etc.
Re: (Score:2)
My web server runs as an untrusted user.
Great. So they can spam, DDOS, and mine crypto on your server. But at least your operating system is safe.
Re: (Score:2)
Not so much. As soon as their server session is done, the storage allocated to running it is erased. And the copy of glibc in the chroot jail has a crippled socket implementation. So no talking to random systems.
Re: (Score:2)
Erm. You understand that "crippling glibc" wouldn't prevent access to its underlying kernel functionality, right?
Re: (Score:2)
Re: (Score:2)
likely to be doing so in chroot jails already
This. And with 'crippled' library copies to keep the interpreter from having full access to system functions.
Language (Score:2)
Postscript is a Turing-complete programming language. If you drop a Postscript program into Ghostscript, it will dutifully run it. So keep that in mind when you are setting permissions on what gets to run Ghostscript, and what you do with it's output.
Anything that produces PDFs (web apps) (Score:2)
The dangers around Postscript essentially apply to anything that produces PDF, where those PDFs include some information provided by the user, such as their name.
PDF files are produced by a Postscript interpreter, such as Ghostscript. It's called a Post"script interpreter" because it's a script interpreter.
> You allow the user that application would run under high enough privileges
And tomorrow you'll not be worried about another vulnerability because it's just a privilege escalation - they'd need to alre
Re: (Score:2)
The *vast* majority of PDF generation code uses nothing remotely resembling a PostScript interpreter. Generally speaking, Postscript interpreters are *slow* and ridiculously unnecessary to the task.
Re: (Score:1)
Re: (Score:2)
I'm curious what software packages you think people are using to create PDFs. I've seen ghostscript used for this purpose many times.
Re: (Score:2)
In my experience, most online commerce applications (for example) generate PDFs by generating HTML or XML and then running that through a layout engine designed to produce PDFs. Or occasionally, they use direct library calls to a PDF generation library, but that is difficult because you have to do the layout yourself, as you would if you generated your own Postscript and converted that.
Now of course a PDF generation library could use a Postscript interpreter for a final conversion step, but that is usually
Re: (Score:2)
Any libraries in particular, because the one I keep seeing is ghostscript.
Re: (Score:2)
iText is available under the AGPL or a commercial license. Prince is reportedly excellent, but expensive. PDFKit looks like it has potential, if you like Javascript. wkhtmltopdf (based on QtWebKit) was a little slow the last time I tried, but is self contained. Apache has one called PDFBox (Java based). Poppler is a GPL library (C++). Chrome/Chromium can now print to pdf in headless mode. There are quite a few others.
Re: (Score:2)
QTWebkit recently removed Postscript support. Of they are running a new version, it's not Postscript anymore. If it's a new version.
Poppler is a wrapper around Cairo, which supports Postscript.
I don't know about the others.
Be careful and validate your input well - you don't always know everything the libraries and command-line utilities can do.
Heck, even lowly printf() is Turing-complete, a fact I took advantage of multiple times in a recent CTF.
Re: (Score:2)
Poppler takes PDF as *input*. If you want to make GPL software that displays, prints, or analyzes PDFs it is worth considering. As far as Cairo goes, its inability to generate PDF output directly is not a point in its favor.
Generating PS and converting that to PDF is so 1994. PDF generation libraries do not work that way - the main reason is that PS doesn't support PDF special features, some of which are actually useful. Plus sub-par performance doing it that way of course.
Libraries like Cairo could use
Re: (Score:2)
A couple more:
(1) OpenPDF Java based library (LGPL). OpenPDF is a fork of iText, which went mostly proprietary.
(2) Flying Saucer XHTML to PDF renderer (Java library with command line option, LGPL). Uses one of several Java based libraries for the final (post layout) PDF conversion.
Re: (Score:2)
I would not say this is a difficult or impossible situation to have, if you haven't been paying attention to the world. But, any idiot can run a server, as evidenced by how many of them do, so I guess it's dangerous.
Indeed. Some forum software may do this though to convert and resize images in postings. SVG should probably not be supported there but it may be by accident or broken input validation.
PS vs PDF (Score:3, Informative)
This path of attack has been well known since the early 90s.
It's a "feature", not a "bug"
If you ever hear people complaining about PDF being "postscript made stupid", this is exactly what PDF was created for.
Despite the insulting nature, "stupid" isn't far off the mark.
Postscript is turning complete, it is a fully capable programming language.
That is such overkill for the purpose of rendering images that PDF was made as a subset of commands, only those needed for drawing.
It's understandable however that seemingly few remember this.
Even Adobe, the company formed by the creators of PDF, all but forgot its purpose and ended up adding in javascript on top!
Re: (Score:1)
I remember all the hype from the 90's about "smart documents", including MS-Office macros, which turned out to be security headaches. Much of IT is a Ponzi scheme: sell on hype, cash out for a big stack of Benjamins at peak hype, dumping the side-effects on the next generation, invest your wad in the Next Big Thing, rinse and repeat...
Yep, Ghost/Postscript(convert to PDF) is SCRIPT (Score:2)
The rule to remember here is that Postscript is indeed script.
Ghostscript, an open source implementation of Postscript, is a scripting engine.
If you converting something to PDF in your software, you are probably running it through a Postscript interpreter. Which means of there are any fields that come from the user, you are likely running scripts input by the user, if they choose to input a script in your "last name" field.
Re: (Score:2)
I'm not at home with Postscript, but what you describe sound pretty much similar to plain old SQL injection. Can you protect yourself in similar ways?
Re: (Score:2)
You go it. Pretty much all 'injection flaws' can be summarized as - The application interpolates user inputs into one or more commands processed by a downstream interpreter but fails to ensure the user input can not alter the syntactic structure of the resulting commands.
Re: (Score:2)
Kinda. For SQL injection protection, you really, really should be using prepared statements. Really. Validating or escaping input is good, but not good enough. Seriously. Gotta use prepared statements.
For Postscript, I don't know of anything similar to prepared statements. You can and should use the -dSAFER switch with Ghostscript. You end up having to rely on input validation to an uncomfortable degree, though (unless there is a strategy I'm not aware of). In a Unicode world, you can't blocklist "bad" ch
Re: (Score:2)
Fortunately, most PDF libraries do not generate Postscript as an intermediate step, but rather something that only has a superficial resemblance. PDF is a vector format, not a programming language, other than embedded Javascript.
I imagine there might be a more serious problem if someone could figure out how to inject *that*, but on the client side, not the server side, and only if the PDF viewer is sufficiently borked anyway.
Re: (Score:2)
I imagine they generate PDF directly, then when done compress it. Most PDF's are compressed; they don't have to be. You can have the raw PDF which is just plain ASCII if you want and as you say superficially looks like PostScript. It is however valid PDF you can feed it to any compliant PDF render and it will render just fine.
Is it just me... (Score:2)
Re:Is it just me... (Score:5, Interesting)
Ghostscript prior 9.50 unaffected (Score:4, Interesting)
The exploit targets ghostscript 9.50 and forward, which fixes a few CVE that impacted older versions, but bring this new vulnerability
How safe it is to run older ghostscript? It has unaddressed CVE, but is there 0day for those?
.
CUPS drivers (Score:2)
Some printers use this as part of the file conversion. Anyone know if this exploit covers this case?