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 [email protected]
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
* Florian Weimer ([email protected]) 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
> 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
On Mon, Apr 22, 2002 at 12:18:19PM -0700, Chris Wright wrote:
> * Florian Weimer ([email protected]) 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)
* Alex Riesen ([email protected]) 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