The Kernal Is A Huge Security Whole In Windows

[CHANGE USERNAME TO westes]

I'm starting to believe that the largest, and most dangerous, security hole
in Windows 2000 is the kernel itself. All a virus needs to do is replace
a key system file that will load into the kernel, or alternately install as
a device driver, and it can hide its behavior to the system. As far as I
can tell, there are no utilities that let me see how much CPU, disk, or
network activity is performed by any component of the Windows 2000 kernel.

On one of my user's machines, her CPU goes to 100% as soon as she starts up.
We have stopped every single service and application on her machine, and it
doesn't change anything. Is this a virus? Is it a badly written device
driver? Is some hardware generating interrupts that overwhelm the device
driver? How can we know?

As far as I can tell, there is nothing left to do here but re-install, which
risks that the entire sequence may happen yet again. If Microsoft values
security, this is a huge back door that they cannot allow to remain.

 

[Miha Pihler]

Hi,

critical system files are digitally signed and system checks for this
signature. If you replace these files with new one that is not digitally
signed system will restore it from e.g. dllcache
(%systemroot%/system32/dllcache). If it cannot restore it it will ask for
installation CD. Same thing happens if you change anything in any of these
files -- you invalidate digital signature.

You can check digital signatures on files by running "sigverif"...

Also all patches and all service packs are digitally signed.

I can't say that for system drivers, but that's up on vendors... You can see
amount of processor used by Kernel if you open Task Manager and click on
Performance Tab > View > Show Kernel Times. You can also check some
additional settings by clicking on Processes Tab > View > Select Columns.

I hope this helps,

Mike

 

[CHANGE USERNAME TO westes]

Regarding the dll cache, I have always wondered how does that get updated as
you apply various service packs? Does Microsoft patch the dllcache at the
same time? Should we put file security on that cache so that only
administrators or system can access it?

The easiest way to exploit the security hole I am discussing is obviously
the device driver. Putting off security responsibilities on the device
driver writer is ridiculous, I'm sorry. You want to make the virus writer
responsible for making his device driver secure?

 

[Miha Pihler]

Hi,

for details on Windows File Protection Feature check this article:

Description of the Windows File Protection Feature
http://support.microsoft.com/default.aspx?scid=kb;EN-US;222193

Beside System files, drivers can also be signed, but it is up to
manufacturer to send it to Microsoft for testing and if the drivers pass
Microsoft tests it will be signed.

Digital Signature Benefits for Windows Users
http://www.microsoft.com/winlogo/benefits/signature-benefits.mspx

I don't it's reasonable to ask Microsoft to be responsible for every driver
and every peace of the software written in this world - specially again all
possible combination of hardware and software.
Any software that you install and run on your PC can damage (infect or steal
information from your PC). It is up to you to choose wisely. You have an
option to choose digitally signed drivers...

Mike

 

[CHANGE USERNAME TO westes]

I think it is reasonable to ask Microsoft to either expand Task Manager, or
write a parallel utility for the kernel, that lets us clearly see which
components in the kernel use CPU, network, and disk resources on the system.

It's not different than applications. The OS is subject to corruption both
at application and kernel levels, and the least a user needs is tools to
inspect how those applications behave at either level of the system.

 

[Roger Abell]

Between SFC and use of signed driver requirements you
can start to feel you have tightened the type of exploit path
you have been outlining.

This is not really unique to Windows. After OS became able
to dynamically load into the kernel, and we no longer had to
hand make each changed kernel, this became an increasingly
feasible route to compromise.

To see detail within the kernel you need to use the debugger.
The kernel is highly optimized, and some "borders" may be
blurred more than you are used to with services and applications,
and slowing the kernel in order to account by bits and pieces
and reflect this up to the user interface is not all that realistic
of an approach. Instead you need to diag the system in a boot
with debugger hooked in, which takes a fair degree of sophistication.

But think about it. Some driver is say causing issues - like your
100% cpu use. If blind, prefabricated statistics were shown of
the different kernel "parts", you might see that driver getting very
small %age of cpu, but some valid and errorfree part of kernel
consuming high amount of cycles - not because it is in error but
because it is being driven by something that is in error. With
debugger you see the call stack and what is driving what how.

In a more general sense, the issues you have pointed to are
a current problem with all operating systems, that it is possible
to hide things at a very low level. This is not just a Windows
issue, but it certainly is one the MS people are aware of and
looking for a future where their OS has immunity.

 

[Karl Levinson [x y] mvp]

I'm starting to believe that the largest, and most dangerous, security hole
in Windows 2000 is the kernel itself. All a virus needs to do is replace
a key system file that will load into the kernel, or alternately install as
a device driver, and it can hide its behavior to the system. As far as I
can tell, there are no utilities that let me see how much CPU, disk, or
network activity is performed by any component of the Windows 2000 kernel.

On one of my user's machines, her CPU goes to 100% as soon as she starts up.
We have stopped every single service and application on her machine, and it
doesn't change anything. Is this a virus? Is it a badly written device
driver? Is some hardware generating interrupts that overwhelm the device
driver? How can we know?

As far as I can tell, there is nothing left to do here but re-install, which
risks that the entire sequence may happen yet again. If Microsoft values
security, this is a huge back door that they cannot allow to remain.

An OS kernel is not in itself a security hole. A kernel may *have* holes,
as the kernel of Windows, Linux, etc. has had vulnerabilities found in them
over time. A kernel is a widely accepted part of an OS security model where
the necessarily high privileges of the OS are kept separate from the lower
privileges of the user in an attempt to improve both security and system
stability. The kernel is thus a desirable target for an attacker or
malicious code to try to hijack.

Because the kernel plays a role in key system tasks like memory management
and display of information back to the user, a problem that affects the
kernel becomes a serious system problem. None of this means it's
necessarily beneficial, or even possible, to remove the kernel from Windows
or any other OS. I'm also not sure I see enough evidence in your situation
to point the finger at the kernel as being the problem.

 

[CHANGE USERNAME TO westes]

Because the kernel plays a role in key system tasks like memory management
and display of information back to the user, a problem that affects the
kernel becomes a serious system problem. None of this means it's
necessarily beneficial, or even possible, to remove the kernel from Windows
or any other OS. I'm also not sure I see enough evidence in your situation
to point the finger at the kernel as being the problem.

Karl, I'm not asking Microsoft to remove the kernel. Nor is it really
productive to debate whether my user's kernel taking 100% of CPU 100% of the
time is a virus or a bad driver or something else. All I am really asking
MIcrosoft to do is to give users *TOOLS* that they can use to see activity
inside the kernel, for purposes of diagnosing behavior in the kernel that
affects performance, stability, or security. How can any person argue
against the value of having tools to inspect the core layer of the OS?

Would it be easy to provide this? Maybe no, maybe yes. Does Microsoft
have the resources to do it? Obviously yes. Do users need it to defend
against bad guys or badly written drivers. Obviously yes.

 

[CHANGE USERNAME TO westes]

Between SFC and use of signed driver requirements you
can start to feel you have tightened the type of exploit path
you have been outlining.

By the way, I'm still not clear on this: when I enable SFC, it seems to
want to populate the dllcache with files from the original CD. How can it
rely on these when the system may already be running a very late SP with
lots of minor patches as well? Does Windows Update automatically keep
the dllcache up to date?

Wouldn't a virus defeat this just by writing itself to both the cache and
system32 directories?

But think about it. Some driver is say causing issues - like your
100% cpu use. If blind, prefabricated statistics were shown of
the different kernel "parts", you might see that driver getting very
small %age of cpu, but some valid and errorfree part of kernel
consuming high amount of cycles - not because it is in error but
because it is being driven by something that is in error. With
debugger you see the call stack and what is driving what how.

That's obviously an excellent point. So it suggests to me that a
diagnostic tool for the kernel, if it is to be used by relatively junior
system administrators, must have the ability to show who are the primary
users of different shared components. It must be possible for Microsoft
to do this, but first they have to believe there is a requirement for it in
the first place.

It's depressing to me that someone in our company won't be able to do their
job for a week, while their whole user environment is reconstructed from
scratch, because we cannot do any diagnosis on what is wrong with their
system.

 

[serverguy]

Regarding the 100% cpu issue, it could be related to the Sasser patch, see
this:
http://support.microsoft.com/default.aspx?kbid=841382

 

[Miha Pihler]

I see you haven't looked at this posted in one of my previous posts.

Description of the Windows File Protection Feature
http://support.microsoft.com/default.aspx?scid=kb;EN-US;222193

In this article it is explained:

If WFP finds the file in the cache folder or if the installation source is
automatically located, WFP silently replaces the file. If WFP cannot
automatically find the file in any of these locations, you receive one of
the following messages, where file_name is the name of the file that was
replaced and product is the Windows product you are using:


Windows File Protection
Files that are required for Windows to run properly have been replaced by
unrecognized versions. To maintain system stability, Windows must restore
the original versions of these files. Insert your product CD-ROM now.
This means that if the virus is to replace a system file in e.g.
%systemroot%\system32 folder AND in %systemroot%\system32\dllcache folder at
the same time, operating system will demand from you to insert a CD with
original installation and replaced files are copied from there. Yes, if you
inserted a CD that doesn't have SP4 applied to it you will have to apply SP4
manually... You can then also use MBSA to scan for any other critical
patches that need to be applied... MBSA actually looks for version of .dll
file that must exist on system - it doesn't look only for existing registry
keys.

Mike

 

[Guest]

That's why God made Anti-Virus. I'm not convinced that a
Linux or Mac system would be any better given
the "opportunity" for a virus to attack the main "guts" or
kernel.

I switched from McAfee to the freeware AVAST! program and
it's super - but not as "invasive" as McAfee and free
updates for 2 years. Whenever you download ANY file, it
will be checked - but I go ahead and check it again.