Possible security bug

RT Developers
1

Hi,

While looking at the rt2 source, I noticed that in tools/initdb the
sub:

sub prompt_for_dba_password {
    print "Enter the $DB_TYPE password for $DB_DBA: ";

    system "stty -echo";
    $DB_DBA_PASSWORD = scalar(<STDIN>); #keep off commandline
    system "stty echo";
    chomp $DB_DBA_PASSWORD;

}

calls ‘stty’ via system() without specifying a path, or making any
checks of %ENV whatsoever.

This is not good. Despite the fact that the person who is installing
rt2 probably has root privileges, they may not, and may be invoking
’initdb’ via something like ‘sudo’, in which case it’s trivial for
them to then get root access by placing something called ‘stty’ in
the search path that shows up before the really stty.

I recommend setting an explicit path for ‘stty’ at the very least, at
best de-taint only required %ENV variables and unset %ENV.

Seeya,
Paul

		  God Bless America!

 If you're not having fun, you're not doing it right!

...we don't need to be perfect to be the best around,
	and we never stop trying to be better. 
	       Tom Clancy, The Bear and The Dragon
2

[snip]
Despite the fact that the person who is installing rt2 probably has
root privileges, they may not, and may be invoking ‘initdb’ via
something like ‘sudo’, in which case it’s trivial for them to then get
root access by placing something called ‘stty’ in the search path that
shows up before the really stty.

I’m not sure this is a real security problem. According to the sudo
manpage, the current directory “.” is checked last to prevent command
spoofing.

The problem with setting an explicit path is that stty may not always be
in the same place from one flavor of *nix to another. Setting a path
comprised of “well known” directories should work for most distros.

Additionaly, if someone is using sudo, they are likely to be a trusted
user or administrator of the box.

Dave Hull
Senior Information Technology Analyst
The University of Kansas
voice: (785) 864-0403 || (785) 864-5621
fax: (785) 864-0485
http://insipid.cc.ukans.edu/dphull

3

In a message dated: Thu, 17 Jan 2002 15:09:15 CST
dphull@ku.edu said:

I’m not sure this is a real security problem. According to the sudo
manpage, the current directory “.” is checked last to prevent command
spoofing.

The problem with setting an explicit path is that stty may not always be
in the same place from one flavor of *nix to another. Setting a path
comprised of “well known” directories should work for most distros.

That’s the problem autoconf/automake solve. However, if you can
figure out how to get this to work easily with perl packages, please
let me know :slight_smile:

Additionaly, if someone is using sudo, they are likely to be a trusted
user or administrator of the box.

Well, yes, or they may have just succeeded in getting access to an
account that is trusted enough to use sudo.

Granted, it’s stretching pretty thin, but it’s still possible that
initdb could be used to grab total root access at some point because
this problem.

I’m just the messenger here :slight_smile:

I felt it my duty to point this out to the developers, that’s the best I can do.
I understand the difficulties involved in accounting for every possible loop
hole. Security is inversely propotional to productivity, after all.

Thanks for the quick response!

Seeya,
Paul

		  God Bless America!

 If you're not having fun, you're not doing it right!

...we don't need to be perfect to be the best around,
	and we never stop trying to be better. 
	       Tom Clancy, The Bear and The Dragon
4

[snip]
Despite the fact that the person who is installing rt2 probably has
root privileges, they may not, and may be invoking ‘initdb’ via
something like ‘sudo’, in which case it’s trivial for them to then get
root access by placing something called ‘stty’ in the search path that
shows up before the really stty.

I’m not sure this is a real security problem. According to the sudo
manpage, the current directory “.” is checked last to prevent command
spoofing.

I believe this comes under ‘check the Makefile and everything it possible
invokes before trying it with root privs’. Standard paranoia.

On the search path, most implementations of sudo and its ilk force $PATH
to be a known set of values, not including ‘.’. If an attacker has put
stty in one of the known $PATH, then all hope is already lost (ie, they
either have root, or theres some really sloppy admin going on).

Bruce.

5

The real “right” answer is to start doing all of this in pure perl :wink: (where
“this” is the entire build and install process). (This would get us a
bunch more install/update flexibility and make packaging not be such a
heinous pain in the ass…

If someone wants to step up with a magic autoconf/automake setup
before I get to that, I’d certainly have a look.

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

6

The real “right” answer is to start doing all of this in pure perl :wink: (where
“this” is the entire build and install process). (This would get us a
bunch more install/update flexibility and make packaging not be such a
heinous pain in the ass…

make supplies you with a proven-to-work target and action parser, that
works on pretty much every platform conceived, and some that should never
have been. Please don’t re-implement it. :wink:

Bruce.

7

Not reimplementing make, (though that’s actually been done for perl6.)
Reimplementing the install process. calling a half-dozen perl scripts, when
they should just be reading from a centralized file, such as config.pm just
sucks.

There will still be a makefile that calls targets, but a lot of the logic
that’s currently being done with hacky makefile targets will be moved into
a single place, so we no longer have to deal with things like
passing passwords as arguments…On Sun, Jan 20, 2002 at 05:32:23PM +0100, Bruce Campbell wrote:

On Sat, 19 Jan 2002, Jesse Vincent wrote:

The real “right” answer is to start doing all of this in pure perl :wink: (where
“this” is the entire build and install process). (This would get us a
bunch more install/update flexibility and make packaging not be such a
heinous pain in the ass…

make supplies you with a proven-to-work target and action parser, that
works on pretty much every platform conceived, and some that should never
have been. Please don’t re-implement it. :wink:

–==–
Bruce.

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.