Recently, there was
a
presentation at the annual meeting of
Chaos
Computer Club in Berlin.
As the presentation describes DTrace at some length,
several have asked the question: is DTrace a security risk? The answer
is an emphatic “no” — quite the contrary in fact — but it merits some
explanation.
DTrace can only be used by users on the system that have the appropriate
privileges (as discussed in the Security chapter of the
DTrace documentation).
By default, the only user with
sufficient privileges to use DTrace is root — the super-user.
The techniques described in the paper and in the presentation
are only for use on a system that one has already compromised.
Of course, once a system is compromised, all bets are off; a nefarious
user can:
-
Load their own daemons to act as
trojan
horses, potentially sniffing
passwords and compromising subsequent machines -
Examine /etc/shadow and crack it to obtain cleartext for
every password on the system -
Use the
pre-existing Solaris observability tools
(truss(1), gcore(1), mdb(1), etc.)
to observe and modify arbitrary processes - Crash and/or destroy the system beyond repair
- Load their own kernel modules to spoof arbitrary parts of the system
Yes, you can use DTrace on a compromised system to glean additional
information, but everything you
can do with DTrace was in principle possible before DTrace — DTrace
just happens to make it a little easier.
Indeed, the presentation
doesn’t even discuss the ways in which a nefarious user on a compromised
system can use DTrace — rather it describes how DTrace can be used to
understand the system well enough to design a nefarious
spoofing kernel module in the first place.
And revealingly, the presentation spends quite a bit of time
describing
how to design a nefarious kernel module such
that it evades instrumentation by DTrace.1 The fact
that time and effort were spend on DTrace evasion is telling:
as a tool designed to expose the inner workings of a production system,
DTrace is much more feared by
the Black Hats than it is useful to them;
far from being a security risk, DTrace is very much a security asset.
1 I hasten to add that the author’s techniques for evading
DTrace won’t actually work
completely. They will successfully evade one form of instrumentation, but
they leave the
nefarious module completely exposed to
several other forms of instrumentation and detection by DTrace. A
more devilish rootkit would completely replace DTrace with some sort of
Bizarro
DTrace that
knew how to completely deny the existence of its cohorts…