[gridengine users] Security hole in most versions of Grid Engine

Ron Chen ron_chen_123 at yahoo.com
Tue Apr 17 21:55:23 UTC 2012


Just IMO, IFS & PATH should be set by the script itself. But then it is just my opinion _only_.

And there is also LANG, and many other variables that can change the behaviour of the script somewhat.

 -Ron



________________________________
From: Reuti <reuti at staff.uni-marburg.de>
To: William Hay <w.hay at ucl.ac.uk> 
Cc: users at gridengine.org 
Sent: Tuesday, April 17, 2012 5:34 PM
Subject: Re: [gridengine users] Security hole in most versions of Grid Engine

Am 17.04.2012 um 22:57 schrieb William Hay:

> There is a security hole in most current versions of Grid Engine.  The
> problem occurs when using a dynamically linked program as
> rlogin_daemon, rsh_daemon or qlogin_daemon or when running a
> dynamically linked binary as prolog or epilog with elevated
> privileges.  This can be exploited by an ordinary user who submits a
> job using the -v option to set environment variables that control the
> dynamic linker  such as
> LD_LIBRARY_PATH or LD_PRELOAD on Linux.  This allows the user to run
> arbitrary  code with elevated privileges (ie root).

If you run a prolog/epilog script under root account there might be even more depending on $PATH or other used (uninitialized) environment variables which are used therein.

The best is to run them just as the ordinary user who runs the job anyway.

NB: Don't forget about start/stop_proc_args ;-)

-- Reuti


> If you use the builtin daemons and don't have prolog or epilog running
> with elevated privileges then you should be safe.
> 
> All the major forks (Son of Grid Engine,Open Grid Scheduler, Univa
> Grid Engine and Oracle Grid Engine)  and several linux distros have
> prepared patched versions which they should be releasing imminently.
> 
> If you can't upgrade immediately  then it should be possible to
> protect your system by using a statically linked binary to sanitize
> the environment.  On RedHat and compatible versions of Linux busybox
> is linked statically and provides an env command that can be used to
> remove dangerous variables.  On Debian and derivatives you need to
> ensure you have the busybox-static package installed rather than plain
> busybox.
> 
> You can then protect your code with something like the following:
> prolog                       root@/sbin/busybox env -u BASH_ENV -u
> LD_LIBRARY_PATH -u LD_PRELOAD -u PERL5OPT -u PERLLIB -u IFS
> /cm/shared/apps/sge/current/cm/prolog
> epilog                       root@/sbin/busybox env -u BASH_ENV -u
> LD_LIBRARY_PATH -u LD_PRELOAD -u PERL5OPT -u PERLLIB -u IFS
> /cm/shared/apps/sge/current/cm/epilog
> rlogin_daemon                /sbin/busybox env -u BASH_ENV -u
> LD_LIBRARY_PATH -u LD_PRELOAD -u PERL5OPT -u PERL5LIB -u PERLLIB -u
> IFS /cm/shared/apps/sge/assist/bin/qrlogind
> qlogin_daemon                /sbin/busybox env -u BASH_ENV -u
> LD_LIBRARY_PATH -u LD_PRELOAD -u PERL5OPT -u PERL5LIB -u PERLLIB -u
> IFS /cm/shared/apps/sge/assist/bin/qlogind
> rsh_daemon                   /sbin/busybox env -u BASH_ENV -u
> LD_LIBRARY_PATH -u LD_PRELOAD -u PERL5OPT -u PERL5LIB -u PERLLIB -u
> IFS /cm/shared/apps/sge/assist/bin/qrshd
> 
> The above examples also remove a few other variables that the
> interpreters we use for our scripts at UCL are sensitive to,
> 
> Dave Love(of SoGE) has created a small wrapper program that removes
> the various dynamic linker controlling variables with significantly
> less verbiage which he should be releasing shortly.
> 
> 
> 
> William
> _______________________________________________
> users mailing list
> users at gridengine.org
> https://gridengine.org/mailman/listinfo/users


_______________________________________________
users mailing list
users at gridengine.org
https://gridengine.org/mailman/listinfo/users




More information about the users mailing list