Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • evince evince
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 758
    • Issues 758
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 49
    • Merge requests 49
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOMEGNOME
  • evinceevince
  • Issues
  • #1058

Ghostscript security issues / consider PS input as hazardous

There've been a number of Ghostscript security issues lately. While some have been fixed, it's unlikely that ghostscript is to be considered safe now. See e.g. https://seclists.org/oss-sec/2016/q4/29 https://www.openwall.com/lists/oss-security/2018/08/21/2

The crucial underlying issue is that postscript is practically a programming language with all kinds of file and system operations. It has a weak sandbox via its "-DSAFER" flag, however it practically does not work.

Also in the discussion on oss-security Tavis Ormandy made it clear that it's unlikely that the core issue will be fixed, because upstream does not want to: https://www.openwall.com/lists/oss-security/2018/10/09/11

So the situation is that there is likely a never ending flow of security bypasses that trivially lead to code execution vulnerabilities.

evince uses ghostscript to parse ps files. Even more worrying: Evince by default installs a thumbnail parser that will use ghostscript to parse PS files.

I think evince needs to consider how to handle this. Given that there exists no safe ps parser alternative this is a difficult situation, but I believe at the very least:

  • The Thumbnail parser should not parse PS files
  • PS files should not be opened by default, but only after a clear warning is shown to the user that the PS parser cannot be considered safe for untrusted input.

I'd like to point out that PS files are not that relevant any more, I don't think anyone publishes original content via PS these days. So I believe not having first class PS support is an option, and maybe even deprecation.

The only alternative I see is either rewriting a safe PS parser from scratch or forking ghostscript and removing all file and system operations that can be dangerous. I don't think anyone is currently interested enough in this to make this happen.

Assignee
Assign to
Time tracking