| | <<<Back 1 day (to 2020/02/23) | Fwd 1 day (to 2020/02/25) >>> | 20200224 |
| petercher | kens: Re 702145, my recommendation had -dNOSAFER option, but the user omitted it. | 14:46.21 |
| kens | Hmm well I missed seeing it. Admittedly I was only scanniong it this morning | 14:46.46 |
| | Yes I see you had it in there | 14:47.19 |
| | Not the smartest of users I'm afraid | 14:47.27 |
| | I should probably add a commetn pointing out that using -dNOSAFER isn't a good idea | 14:48.06 |
| petercher | I think -dNOSAFWR is fine for this case. The PostScript program is safe, and PDF is not a programming language. | 14:52.29 |
| kens | But the Ghostscript PDF interpreter is currently a PostScript program | 14:52.57 |
| | If you can persuade that to execute random code in a PDF file, then potentially you could unleash remote code execution | 14:54.12 |
| | You can't easily do that with a PostScript Form XObject any more, but I wouldn't like to bet that you couldn't start executing a PostScript stream, or a PDF stream which actually contains PostScript. | 14:55.21 |
| petercher | Yex, Type 1 fonts can execute arbitrary PostScript. Perhaps gs needs a restricted execution operator for this case. | 15:01.36 |
| kens | I think there are more serious possibilities; I suspect I could create a stream in a PDF file which contained PostScript, and get the GS PDF interpreter to execute it. Obviously a 'normal' PDF interpreter would reject the contents as garbage. | 15:02.50 |
| | Which is why we chose to restrict the file operations | 15:03.16 |
| | <<<Back 1 day (to 2020/02/23) | Forward 1 day (to 2020/02/25)>>> | |
Log of #ghostscript at irc.freenode.net.