Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Ghostscript PDF interpreter

ghostscript.com

Post reply on HN
Print view View original

81–90 of 98 posts

Re: New Ghostscript PDF interpreter

#81

Post by ksidudwbw »

neilv wrote: post #34

Years back, I raised how evolved Ghostscript had been over a very long time, together with the huge complexity of the PDF specs, as a potential source of vulnerabilities. (But maybe wasn't as much on people's radars, with all lower-hanging fruit of other technology choices and practices going on, outside of PDF.) New code for a large spec is also interesting for potential vulns, but maybe easier to get confidence abo…

But why is the doc running as our user anyways? I didn't create the documebt so it doesn't make sense that it runs with the rights of my user. It can certainly ask for certain permissons.

Zero days will alwsys exist it seems, even Chrome has these, with hundreds of security researchers eyes on it

Re: New Ghostscript PDF interpreter

#82

Post by samus »

herodotus wrote: post #70
mkl wrote: post #50

> As time has gone on, and we have encountered more and more PDF files with ever more unexpected deviations from the specification Does anyone know of a collection of malformed PDF files? It would be useful for testing PDF processing programs.

One trick you can do is fuzz pdf your self by getting any PDF file and opening it using vi or vim. Then write over anything you see and save it. Crude but if all you need are some broken PDF files, that will do it.

Fuzzing sounds like a very good idea to employ right from the beginning when writing parsers for complicated file formats.

Re: New Ghostscript PDF interpreter

#83

Post by samus »

ptx wrote: post #52
daptaq wrote: post #47

Earlier quoted context omitted.

I'd say a language is bad at error handling if it doesn't let you check if a procedure failed or not. What C does it that it compiles even if you ignore this, which is a different issue. Java, Rust, etc. wouldn't compile if you totally ignored it, but you that doesn't mean you have to do proper error handling, beyond satisfying the compiler/type system.

Are there any languages that are bad at error handling then, according to that definition? That don't let you return values, set global flags, mutate arguments or in any other way communicate back from a procedure?

It mostly depends on API design I guess, but missing language features can certainly more complicated than necessary. I guess the GhostScript authors felt error handling in PostScript to be difficult since it is a concatenative programming language (related to functional programming languages) with a dynamic type system, even though it has error handling facilities.

Re: New Ghostscript PDF interpreter

#84

Post by pjmlp »

srvmshr wrote: post #76
vfclists wrote: post #18

Using C sounds like it will bring a whole new list of exploits with it. Not good!!

When people write code which doesn't have memory safety & lacks the compactness needed for a mature product, it is not C language's fault C is a well tested compact language - the fact that Linux kernel, BSD kernels, device drivers and a whole lot of games and physics engines are written for performant systems is a testament to it's reliability. Additionally, I think it's the sane move. A language which is hot cake t…

When Michael Abrash wrote his books, C compilers weren't known for the quality of their blazing machine code.

It also has a proven record that no matter what, exploits are bound to happen, making the whole industry turn into hardware memory tagging as the ultimate solution to fix C.

Re: New Ghostscript PDF interpreter

#85

Post by 3ace »

> Since there is no means to ‘verify’ that a PDF file conforms, creators fall back on using Adobe Acrobat, the de facto standard. If Acrobat will open the file then it must be OK! Sadly it turns out that Acrobat is really very tolerant of badly formed PDF files and will always attempt to open them.

I'm grinning widely when reading this.

Until last year I had an opportunity to help maintaining a pdf tools written using Golang. This case where a pdf doc that is not conforming with the standard could be opened in Acrobat but not on other pdf reader tools (including ghostscript) came a lot from our clients and I had to find a way to be able to read/extract the content with a minimum issue because of that.

Re: New Ghostscript PDF interpreter

#86

Post by srvmshr »

pjmlp wrote: post #84
srvmshr wrote: post #76

Earlier quoted context omitted.

When people write code which doesn't have memory safety & lacks the compactness needed for a mature product, it is not C language's fault C is a well tested compact language - the fact that Linux kernel, BSD kernels, device drivers and a whole lot of games and physics engines are written for performant systems is a testament to it's reliability. Additionally, I think it's the sane move. A language which is hot cake t…

When Michael Abrash wrote his books, C compilers weren't known for the quality of their blazing machine code. It also has a proven record that no matter what, exploits are bound to happen, making the whole industry turn into hardware memory tagging as the ultimate solution to fix C.

Memory exploits in Rust : Yes much less. That's where the world is (hopefully) headed to.

But then a lot of people would disagree on "Lets jump on the bandwagon ASAP". Even the transition to parts of Linux kernel components in Rust is slow and cautious. In that sense, C is still a wide choice. Plus there are a lot of people actively working on C. Rust is only but picking up. it's more likely people will write buggy code on a new language than something which has been around for a while.

Re: New Ghostscript PDF interpreter

#87

Post by pjmlp »

srvmshr wrote: post #86
pjmlp wrote: post #84

Earlier quoted context omitted.

When Michael Abrash wrote his books, C compilers weren't known for the quality of their blazing machine code. It also has a proven record that no matter what, exploits are bound to happen, making the whole industry turn into hardware memory tagging as the ultimate solution to fix C.

Memory exploits in Rust : Yes much less. That's where the world is (hopefully) headed to. But then a lot of people would disagree on "Lets jump on the bandwagon ASAP". Even the transition to parts of Linux kernel components in Rust is slow and cautious. In that sense, C is still a wide choice. Plus there are a lot of people actively working on C. Rust is only but picking up. it's more likely people will write buggy c…

No need to bring Rust into this talk, Modula-2 from 1978 would already sort out most of C's mistakes, or even JOVIAL from 1958.

C became a forced choice thanks to UNIX's free beer, and like JavaScript with the Web, it tainted us all.

Re: New Ghostscript PDF interpreter

#88

Post by rcarmo »

Funny thing: I remember hand coding Postscript patterns to play around on the first LaserWriter.

PDF became such a weird mess that I’m not surprised Postscript is now just a subset of it (to a degree), but writing an entirely new interpreter has had to be a hefty chunk of work..

Re: New Ghostscript PDF interpreter

#89

Post by cjbprime »

asdff wrote: post #43
neilv wrote: post #34

Years back, I raised how evolved Ghostscript had been over a very long time, together with the huge complexity of the PDF specs, as a potential source of vulnerabilities. (But maybe wasn't as much on people's radars, with all lower-hanging fruit of other technology choices and practices going on, outside of PDF.) New code for a large spec is also interesting for potential vulns, but maybe easier to get confidence abo…

Is there any work in this space on some oddball "contamination protocol" type of security? Like you would assume everything is contaminated and you do things that eliminate the potential for cross contamination entirely, like they do in lab settings with aseptic technique. In this case, it could mean printing out the contaminated pdf on a system you don't care about being contaminated, then scanning it with an airgap…

There are two relevant computer security ideas here -- "sandboxing" is used to place risky work (such as Chrome decoding some media) into an isolated process which lacks privileges to e.g. abuse access to files or networking, and "taint tracking" is used to reason about what attacker-supplied input can influence.

Re: New Ghostscript PDF interpreter

#90

Post by eesmith »

jcranmer wrote: post #49
vodou wrote: post #25

Earlier quoted context omitted.

C is not inherently unsafe. Sure, it hasn't "memory safety" as a feature. But there are loads of applications considered safe written in C. An experienced C programmer (with the help of tooling) can write safe C code. It is not impossible.

SQLite is the most stringently developed C code I'm aware of--the test suite maintains 100% branch coverage, routinely run through all of the sanitizers, and it is regularly fuzzed. It still accumulates CVEs: https://www.sqlite.org/cves.html .

As I recall, one of the advantages of C over Rust is that the SQLite authors have the tooling to do 100% branch coverage testing of the compiled binaries in C. They tried Rust, but Rust inserts code branches they are unable to test.

The tradeoff then is the small number of bug causing the denial of service bugs listed, vs. not having 100% branch coverage. And they chose the latter.

(The authors also believe Rust isn't portable enough, not handles out-of-memory errors well enough - https://www.sqlite.org/whyc.html#why_isn_t_sqlite_coded_in_a... .)

Post reply on HN