[Dshield] Sony, Rootkits and Digital Rights Management Gone Too Far

Tim Hollebeek tholleb at teknowledge.com
Tue Nov 1 18:29:20 GMT 2005


 
> But do we 
> have to change the premise of what a rootkit is, or at least 
> how we detect rootkits,  if legitimate applications want to 
> use capabilities of the system which are at this time only 
> used by rootkits and other malicious  code.  One example of 
> this is alternate data streams, for the most part we assume 
> they don't have a legitimate use for non-malicious 
> applications, but if a legitimate application chooses to use 
> alternate data streams do we immediately label them as malicious code?

It is always important to remember that with the term "malicious
code" we are refering to the intent of the writer of the code,
which is not strictly a property of the code itself.

By inspecting the code, we may discover certain properties of the
code that lead us to infer the intent of the writer, and label the
code "malicious code".  But it is important to realize there is
an inference process here, and the results will depend on the
definition of "malicious", which varies substantially depending
on context, and that due to the limited complexity of such algorithms,
the inferences will, from time to time, be wrong.  This problem is 
essentially unavoidable for a variety of reasons.  Essentially,
if you can draw a nice bright line between black and white, you
have an authorization/access control problem, not a malicious
code detection problem.

Use of alternative data streams is currently a good indicator of
malicious intent, but there are legitimate applications that use
them.  This is something designers of security systems have to
take into account.  But, it is also important that the designers
of legitimate programs take care to not require more privileges
than they need, or to engage in behavior that unnecessarily
blurs the line between legitimate and malicious behavior.

Tim Hollebeek




More information about the list mailing list