[SECURITY] FDs 0, 1, 2 for SUID/SGID programs

[SECURITY] FDs 0, 1, 2 for SUID/SGID programs

[Florian Weimer]

http://www.pine.nl/advisories/pine-cert-20020401.html probably affects
Linux, too (if a SUID/SGID program is invoked with FD 2 closed, error
messages might be written to a file opened by the program ).

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: [SECURITY] FDs 0, 1, 2 for SUID/SGID programs

[Chris Wright]

* Florian Weimer (Weimer@CERT.Uni-Stuttgart.DE) wrote:
> http://www.pine.nl/advisories/pine-cert-20020401.html probably affects
> Linux, too (if a SUID/SGID program is invoked with FD 2 closed, error
> messages might be written to a file opened by the program ).

AFAIK, the standards clearly specify behaviour wrt. open file descriptors
and clone-on-exec file descriptors across execve().  However, there
is nothing specified when it comes to closed file descpriptors across
execve(), notably FD's 0, 1 and 2 are certainly not required to be open
across an execve() of a SUID/SGID applictaion.  One could argue that
SUID/SGID apps that trust the file descriptors they inherit across exec()
are buggy.

Having said that, there are a number of implementations of this type
of protection for the linux kernel stemming from the Openwall project.
If you are interested, see:

	http://www.openwall.com	(CONFIG_SECURE_FD_0_1_2)
	http://lsm.immunix.org	(CONFIG_OWLSM_FD)
	http://grsecurity.net	(CONFIG_GRKERNSEC_FD)

cheers,
-chris

Re: [SECURITY] FDs 0, 1, 2 for SUID/SGID programs

[Alex Riesen]

On Mon, Apr 22, 2002 at 12:18:19PM -0700, Chris Wright wrote:
> * Florian Weimer (Weimer@CERT.Uni-Stuttgart.DE) wrote:
> > http://www.pine.nl/advisories/pine-cert-20020401.html probably affects
> > Linux, too (if a SUID/SGID program is invoked with FD 2 closed, error
> > messages might be written to a file opened by the program ).
> 
> AFAIK, the standards clearly specify behaviour wrt. open file descriptors
> and clone-on-exec file descriptors across execve().  However, there

that is close-on-exec. Different semantics.

       F_GETFD  Read  the  close-on-exec flag.  If the FD_CLOEXEC
                bit is 0, the file will remain open across  exec,
                otherwise it will be closed.


> is nothing specified when it comes to closed file descpriptors across
> execve(), notably FD's 0, 1 and 2 are certainly not required to be open
> across an execve() of a SUID/SGID applictaion.  One could argue that
> SUID/SGID apps that trust the file descriptors they inherit across exec()
> are buggy.
> 
> Having said that, there are a number of implementations of this type
> of protection for the linux kernel stemming from the Openwall project.
> If you are interested, see:
> 
> 	http://www.openwall.com	(CONFIG_SECURE_FD_0_1_2)
> 	http://lsm.immunix.org	(CONFIG_OWLSM_FD)
> 	http://grsecurity.net	(CONFIG_GRKERNSEC_FD)

Re: [SECURITY] FDs 0, 1, 2 for SUID/SGID programs

[Chris Wright]

* Alex Riesen (Alexander.Riesen@synopsys.com) wrote:
> On Mon, Apr 22, 2002 at 12:18:19PM -0700, Chris Wright wrote:
> > and clone-on-exec file descriptors across execve().  However, there
> 
> that is close-on-exec. Different semantics.

yes, typo. thanks.
-chris

Re: [SECURITY] FDs 0, 1, 2 for SUID/SGID programs

[Alan Cox]

> http://www.pine.nl/advisories/pine-cert-20020401.html probably affects
> Linux, too (if a SUID/SGID program is invoked with FD 2 closed, error
> messages might be written to a file opened by the program ).

Unix requires this behaviour. Its an old and common bug to get it
wrong. glibc intentionally provides some cover