Security issue in Sys::Hostname ? 
Author Message
 Security issue in Sys::Hostname ?

Hello

When looking for hostname, the Sys::Hostname module may end up in
invoking the hostname shell command.

The problem is that the hostname command is issued without the full
path and $ENV{PATH} is not checked or resetted:

For VMS:
      my($rslt) = `hostname`;
For Unix:
      $host = `(hostname) 2>/dev/null`; # bsdish
      $host = `uname -n 2>/dev/null`; ## sysVish

So, if Sys::Hostname is run as root and fails to find the info before
invoking `hostname`, a malicious user could gain root privilege by
modifying PATH to use its own version of hostname.

Is this a problem or did I miss something ?

Cheers

--



Tue, 08 Nov 2005 22:43:11 GMT  
 Security issue in Sys::Hostname ?

Quote:

> So, if Sys::Hostname is run as root and fails to find the info before
> invoking `hostname`, a malicious user could gain root privilege by
> modifying PATH to use its own version of hostname.

> Is this a problem or did I miss something ?

     Well, you "missed" one thing, although you did manage to write it,
just not read it...

    "if Sys::Hostname is run as root"..."a malicious user".

    So, this malicious user would *already* be running as root, but you
think that Sys::Hostname is a potential security issue?

--
      -*-    Just because I've written it here doesn't    -*-
      -*-    mean that you should, or I do, believe it.   -*-



Wed, 09 Nov 2005 05:39:08 GMT  
 Security issue in Sys::Hostname ?

Quote:

> > So, if Sys::Hostname is run as root and fails to find the info before
> > invoking `hostname`, a malicious user could gain root privilege by
> > modifying PATH to use its own version of hostname.

> > Is this a problem or did I miss something ?

>      Well, you "missed" one thing, although you did manage to write it,
> just not read it...

>     "if Sys::Hostname is run as root"..."a malicious user".

>     So, this malicious user would *already* be running as root, but you
> think that Sys::Hostname is a potential security issue?

Consider a program that uses Sys::Hostname that is installed setuid
root.  Any user can run this program, and the program runs with root
permissions.  This should be safe, as long as the program does what it
is supposed to do.  

But as Dominique has shown, because of the defect in Sys::Hostname,
the program can be made to do something unexpected: It can be forced
to run some *other* program, one written by the user, with root
permissions.



Thu, 10 Nov 2005 22:20:04 GMT  
 Security issue in Sys::Hostname ?

Quote:


> > > So, if Sys::Hostname is run as root and fails to find the info before
> > > invoking `hostname`, a malicious user could gain root privilege by
> > > modifying PATH to use its own version of hostname.

> > > Is this a problem or did I miss something ?

> >      Well, you "missed" one thing, although you did manage to write it,
> > just not read it...

> >     "if Sys::Hostname is run as root"..."a malicious user".

> >     So, this malicious user would *already* be running as root, but you
> > think that Sys::Hostname is a potential security issue?

> Consider a program that uses Sys::Hostname that is installed setuid
> root.  Any user can run this program, and the program runs with root
> permissions.  This should be safe, as long as the program does what it
> is supposed to do.  

> But as Dominique has shown, because of the defect in Sys::Hostname,
> the program can be made to do something unexpected: It can be forced
> to run some *other* program, one written by the user, with root
> permissions.

So should we add
        local $ENV{PATH} = "/bin:/usr/bin";
on top of Sys::Hostname::hostname?

Regards,
        Slaven

--

Tk-AppMaster: a perl/Tk module launcher designed for handhelds
        http://tk-appmaster.sf.net



Fri, 11 Nov 2005 04:12:21 GMT  
 Security issue in Sys::Hostname ?

Quote:

>> Consider a program that uses Sys::Hostname that is installed setuid
>> root.

> So should we add
>    local $ENV{PATH} = "/bin:/usr/bin";
> on top of Sys::Hostname::hostname?

No, you should stop writing setuid root applications which aren't taint
checked.

--
<quidity> Sometimes it's better not to pedant.



Fri, 11 Nov 2005 05:12:23 GMT  
 Security issue in Sys::Hostname ?

Quote:


>> > So, if Sys::Hostname is run as root and fails to find the info
>> > before invoking `hostname`, a malicious user could gain root
>> > privilege by modifying PATH to use its own version of hostname.

>> So, this malicious user would *already* be running as root, but you
>> think that Sys::Hostname is a potential security issue?

> Consider a program that uses Sys::Hostname that is installed setuid
> root.

The setuid will have forced taint mode, so it's still not a problem.

--
Steve



Fri, 11 Nov 2005 02:44:05 GMT  
 Security issue in Sys::Hostname ?

Quote:


>> > So, if Sys::Hostname is run as root and fails to find the info
>> > before invoking `hostname`, a malicious user could gain root
>> > privilege by modifying PATH to use its own version of hostname.

>> So, this malicious user would *already* be running as root, but you
>> think that Sys::Hostname is a potential security issue?

> Consider a program that uses Sys::Hostname that is installed setuid
> root.

The setuid will have forced taint mode, so it's still not a problem.

--
Steve



Fri, 11 Nov 2005 07:40:14 GMT  
 Security issue in Sys::Hostname ?
A program which runs suid root will have taint checking turned on (if
using suidperl) and this will complain about PATH being tainted.  So
it's more difficult to accidentally run a hostile host(1) command or
anything else.

--



Fri, 11 Nov 2005 05:38:48 GMT  
 Security issue in Sys::Hostname ?

Quote:




>>> > So, if Sys::Hostname is run as root and fails to find the info
>>> > before invoking `hostname`, a malicious user could gain root
>>> > privilege by modifying PATH to use its own version of hostname.

>>> So, this malicious user would *already* be running as root, but you
>>> think that Sys::Hostname is a potential security issue?

>> Consider a program that uses Sys::Hostname that is installed setuid
>> root.

> The setuid will have forced taint mode, so it's still not a problem.

Sorry, I indeed forget to write down a crucial part of the potential
problem.

So there's no security problem since a setuid script is run in taint
mode. So Sys::Hostname fallback methods will fail with "Insecure
$ENV{PATH}", which is better that leaving a security hole.

Thanks evebody for your responses.

--



Fri, 11 Nov 2005 17:44:04 GMT  
 Security issue in Sys::Hostname ?



:
: > So should we add
: >  local $ENV{PATH} = "/bin:/usr/bin";
: > on top of Sys::Hostname::hostname?
:
: No, you should stop writing setuid root applications which aren't taint
: checked.

You ought to perlbug a Perl program that can do this:

    Perl automatically enables a set of special security
    checks, called taint mode, when it detects its program
    running with differing real and effective user or group
    IDs.

Greg
--
My idea of a group decision is looking in a mirror.
    -- Warren Buffett



Sat, 12 Nov 2005 22:11:41 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. I'm stuck and need advise - cannot fix Record/Key Deleted

2. strange tp7 error on Pentium Computers

3. Help! DB not in edit/insert mode error, using TDBLookupComboBox

4. Using databases on a LAN

5. Why use Sys::Hostname instead of just $ENV{SERVER_NAME}

6. Sys::Hostname, Solaris, and perhaps tainting

7. compile warning with perl 5.003 module Sys::hostname

8. Sys::Hostname, taint and linux

9. Mysterious Sys::Hostname problem

10. Sys::Hostname module and -w

11. using Sys::Hostname in a CGI

12. Sys::Hostname exibits strange behavior under Solaris 2.5

 

 
Powered by phpBB® Forum Software