#3910: +RTS options introduce a security problem for, e.g., setuid binaries
------------------------------------------+---------------------------------
  Reporter:  andersk                      |          Owner:  simonmar        
      Type:  bug                          |         Status:  closed          
  Priority:  normal                       |      Milestone:  7.0.2           
 Component:  Runtime System               |        Version:  7.1             
Resolution:  fixed                        |       Keywords:                  
  Testcase:                               |      Blockedby:                  
Difficulty:                               |             Os:  Unknown/Multiple
  Blocking:                               |   Architecture:  Unknown/Multiple
   Failure:  Incorrect result at runtime  |  
------------------------------------------+---------------------------------

Comment(by duncan):

 I also find it annoying, and other users of parallel haskell find it
 annoying too. Attached is a patch to relax the situation somewhat.

 {{{
 Author: Duncan Coutts <[email protected]>
 Date:   Thu Oct 27 13:26:15 2011 +0100

 Ticket #3910 originally pointed out that the RTS options are a potential
 security problem. For example the -t -s or -S flags can be used to
 overwrite files. This would be bad in the context of CGI scripts or
 setuid binaries. So we introduced a system where +RTS processing is more
 or less disabled unless you pass the -rtsopts flag at link time.

 This scheme is safe enough but it also really annoies users. They have
 to use -rtsopts in many circumstances: with -threaded to use -N, with
 -eventlog to use -l, with -prof to use any of the profiling flags. Many
 users just set -rtsopts globally or in project .cabal files. Apart from
 annoying users it reduces security because it means that deployed
 binaries will have all RTS options enabled rather than just profiling
 ones.

 This patch relaxes the set of RTS options that are available in the
 default -rtsopts=some case. For "deployment" ways like vanilla and
 -threaded we remain quite conservative. Only --info -? --help are
 allowed for vanilla. For -threaded, -N and -N<x> are allowed with a
 check that x <= num cpus.

 For "developer" ways like -debug, -eventlog, -prof, we allow all the
 options that are special to that way. Some of these allow writing files,
 but the file written is not directly under the control of the attacker.
 For the setuid case (where the attacker would have control over binary
 name, current dir, local symlinks etc) we check if the process is
 running setuid/setgid and refuse all RTS option processing. Users would
 need to use -rtsopts=all in this case.

 We are making the assumption that developers will not deploy binaries
 built in the -debug, -eventlog, -prof ways. And even if they do, the
 damage should be limited to DOS, information disclosure and writing
 files like <progname>.eventlog, not arbitrary files.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3910#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to