Are there valid technical reasons for using RootKits?

[Escalader]

What I would like to understand is there ever a valid technical reason for using RootKits, hooks, and / or hidden processes?

I submitted a report from RKU to their forum and was told that all was well since the RKs and hooks were ALL related to my security software.

Please lets not start again on RKU, I'm not complaining about their findings!

Thing that puzzles me is one package I use BitDefender, uses them and others did not. Why is this? Do vendors try to protect their property with RK's?

I must be a worrier at heart but does anybody have an explanation to these questions?
__________________

[lucas1985]

Security software needs access to kernel to protect the system.

[Escalader]

-{ Quote: "Security software needs access to kernel to protect the system." }-

Thanks lucas.

Thing is some of my security software seemed NOT to get reported in the RKU reports. Have you actually done yours to see if they all do it? I'm going to redo mine and look again.

This is not a challenge question just a work in progress I'm just trying to figure this out.

[ThunderZ]

Have played with several RK detectors. The results varied dramatically. Where several showed none, one showed many. All were related to my security apps. in general with ZA Pro being the leader of the pack by far. Do not know if the ones that showed none was by design or just missed them. Or if the one that showed many were in affect showing FPs or just showing everything so the User could decide. Sorry, do not remember which one showed and which ones did not.

[Ice_Czar]

employing deductive reasoning and dredging what Ive read from several sources
I come to 4 classifications\motivations of rootkits

1. Otherwise legitimate applications hiding from end users
(DRM particularly)

2. Security applications hiding from malware to prevent subversion

3. Applications hiding from the system to fool it
(Daemon Tools)

4. Malware

of course as demonstrated by the Sony BMG fiasco a poorly employed rootkit if found out
poses a security threat, what precautions\exclusions might be employed by security aps I dont know
reading through Kernel Malware: The Attack from Within (http://www.wilderssecurity.com/showthread.php?t=167863) I suspect that if the malware is at a low enough level whatever precautions are employed would not be sufficient.

-{ Quote: "It would operate with the same privileges and share all the same resources as the operating system itself and compete with any security solutions protecting the systems integrity against malicious activities. This would end up in an arms race between the malware and the security suite. The one that is able to execute first or being able to control the lowest parts of the operating system eventually will be the winner." }-

[Escalader]

-{ Quote: "employing deductive reasoning and dredging what Ive read from several sources
I come to 4 classifications\motivations of rootkits

1. Otherwise legitimate applications hiding from end users
(DRM particularly)

2. Security applications hiding from malware to prevent subversion

3. Applications hiding from the system to fool it
(Daemon Tools)

4. Malware

of course as demonstrated by the Sony BMG fiasco a poorly employed rootkit if found out
poses a security threat, what precautions\exclusions might be employed by security aps I dont know" }-

-{ Quote: "Have played with several RK detectors. The results varied dramatically. Where several showed none, one showed many. All were related to my security apps. in general with ZA Pro being the leader of the pack by far. Do not know if the ones that showed none was by design or just missed them. Or if the one that showed many were in affect showing FPs or just showing everything so the User could decide. Sorry, do not remember which one showed and which ones did not." }-

Thanks guys. The issue then is to find and eliminate ICE's class 3 and 4. BTW what are Dameon Tools? Reminds me of a Gregory Peck movie some years back! I like that deductive reasoning Ice!

ThunderZ: I've got ZA Pro as you can see so it must fall into class 2 which is a good thing!

If say SS has 0 rk's that may mean it is open to tampering by the bad guys?

[Ice_Czar]

Virtual Optical Drive
http://en.wikipedia.org/wiki/DAEMON_Tools
http://en.wikipedia.org/wiki/Alcohol_120%25

I use Daemon Tools to mount ISO's
Have several of the older adware free versions but you can also opt out of the adware currently as well

http://www.daemon-tools.cc/dtcc/showthread.php?t=9581

you can also get RK hits with trialware
http://forum.sysinternals.com/forum_posts.asp?TID=5903&KW=Defrag

those are my two legitimate returns in most RK detectors

[ThunderZ]

-{ Quote: "ThunderZ: I've got ZA Pro as you can see so it must fall into class 2 which is a good thing!" }-


That is what I am figuring\counting on.


-{ Quote: "If say SS has 0 rk's that may mean it is open to tampering by the bad guys?" }-


With all the acronyms flying around the Forum I am drawing a blank on SS. ::) :-[ However whether it is open to easier tampering by the bad guys would probably be dependent on several things. Also, SS(?) may not require rootkits, or have them written into the code in order to perform it`s functions.

[Escalader]

SS= Spysweeper (webroot)

You are not alone on the short forms, we may need a forum dictionary!

[ThunderZ]

-{ Quote: "SS= Spysweeper (webroot)

You are not alone on the short forms, we may need a forum dictionary!" }-


Should have known that one. Have thought many times of making a Glossary of sorts with them all in it. Then perhaps it could be made into a sticky. I know it would be a huge help to myself at least.

[Ice_Czar]

-{ Quote: "Also, SS(?) may not require rootkits, or have them written into the code in order to perform it`s functions." }-

I think(?) that at the kernel level we are talking about it may not be fair to describe what a security ap does as a rootkit, at least with the definition most would recognize, maybe a better description is a kernel level driver operating on ring0 (full access), what its doing may in fact be hidden from the end user and malware but then alot of system functions are as well. In that light a malware kernel mode rootkit could be described as a rogue driver that "hides" itself and or other nefarious code.

I guess Im saying not only do we need a lexicon of acronyms for the forum
but a glossary of system vs malware definitions.


again from Kernel Malware: The Attack from Within (http://www.f-secure.com/weblog/archives/kasslin_AVAR2006_KernelMalware_paper.pdf)
-{ Quote: "Kernel Mode vs User Mode
One of the design goals for Windows N was reliability and robustness. The main requirement was to protect the kernel from external tampering by user mode applications. To address this, the system was divided into two different modes of operation: user mode and kernel mode. User applications run in user mode. They are unprivileged processes with limited access to system resources. User mode processes access these resources controlled by the kernel through services provided by the kernel.

Operating system services and third party drivers run in kernel mode. In kernel mode, they have access to all system memory, all CPU instructions, and all hardware. The architecure of the Intel x86 processor supports four privilege levels, or rings, numbered from 0 to 3. The greater numbers mean lesser privileges. Windows uses privilege level 0 for kernel mode and privilege level 3 for user mode.

To provide protection to virtual memory, the OS keeps track from which privilege level each memory page can be accessed. Pages in system address space can be only accessed from kernel mode, which protects them from user mode processes. Since code running in kernel mode has full access to system memory, it can easily bypass any security mechanism provided by the OS and destroy its integrity.

Drivers run in kernel mode and third party drivers can be installed and loaded with administrative privileges. This is the only documented and supported way of executing kernel mode code. Other undocumented means do exist and they are explained in more detail in a later section." }-

thus the definition of a rootkit is largely its malicious intent as well as its hidden actions
since most security at least has one process the end user can observe
I gather the real danger of "legitimate" rootkits is that they can be subverted to malicious purposes

we may find that the word rootkit needs further refining to reflect what level of privilege its working from. RK2 RK1 RK0. Im still digesting that paper :P