
#15567: security of package environment files -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by joeyhess: Old description:
ghc will read package environment files owned by other users than the current user, in directories below the current directory. So using ghc in shared directories like /tmp is now a security concern.
{{{ joey@darkstar:/tmp/test/sub>ls -l ../../.ghc.environment.x86_64-linux-8.2.2 -rw-r--r-- 1 mail mail 9 Aug 25 15:03 ../../.ghc.environment.x86_64-linux-8.2.2 joey@darkstar:/tmp/test/sub>cat ../.ghc.environment.x86_64-linux-8.2.2 outdated joey@darkstar:/tmp/test/sub>ghc --make foo <command line>: cannot satisfy -package-id outdated (use -v for more information) }}}
I suppose this could at least be used to trick ghc into building against an older version of some package that was updated with a security fix. It might be possible to exploit in other ways, perhaps by pointing to a backdoored build of a package?
New description: ghc will read package environment files owned by other users than the current user, in directories below the current directory. So using ghc in shared directories like /tmp is now a security concern. {{{ joey@darkstar:/tmp/test/sub>ls -l ../../.ghc.environment.x86_64-linux-8.2.2 -rw-r--r-- 1 mail mail 9 Aug 25 15:03 ../../.ghc.environment.x86_64-linux-8.2.2 joey@darkstar:/tmp/test/sub>cat ../../.ghc.environment.x86_64-linux-8.2.2 outdated joey@darkstar:/tmp/test/sub>ghc --make foo <command line>: cannot satisfy -package-id outdated (use -v for more information) }}} I suppose this could at least be used to trick ghc into building against an older version of some package that was updated with a security fix. It might be possible to exploit in other ways, perhaps by pointing to a backdoored build of a package? -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15567#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler