The Kernal Is A Huge Security Whole In Windows

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

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.

--
Will
westes AT earthbroadcast.com

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

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" <DELETE_westes@earthbroadcast.com> wrote in
message news:eflHw7oaEHA.2840@TK2MSFTNGP11.phx.gbl...
> 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.
>
> --
> Will
> westes AT earthbroadcast.com
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

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?

--
Will
westes AT earthbroadcast.com

"Miha Pihler" <miha-news@atlantis.si> wrote in message
news:eWHs5LpaEHA.3596@tk2msftngp13.phx.gbl...
> 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" <DELETE_westes@earthbroadcast.com> wrote in
> message news:eflHw7oaEHA.2840@TK2MSFTNGP11.phx.gbl...
> > 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.
> >
> > --
> > Will
> > westes AT earthbroadcast.com
> >
> >
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

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" <DELETE_westes@earthbroadcast.com> wrote in
message news:%239Z1cYpaEHA.3664@TK2MSFTNGP12.phx.gbl...
> 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 driver writer is ridiculous, I'm sorry. You want to
make the virus writer
> responsible for making his device driver secure?
>
> --
> Will
> westes AT earthbroadcast.com
>
> "Miha Pihler" <miha-news@atlantis.si> wrote in message
> news:eWHs5LpaEHA.3596@tk2msftngp13.phx.gbl...
> > 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" <DELETE_westes@earthbroadcast.com> wrote in
> > message news:eflHw7oaEHA.2840@TK2MSFTNGP11.phx.gbl...
> > > 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.
> > >
> > > --
> > > Will
> > > westes AT earthbroadcast.com
> > >
> > >
> >
> >
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

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.

--
Will
westes AT earthbroadcast.com

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

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.
--
Roger Abell
Microsoft MVP (Windows Server System: Security)
MCSE (W2k3,W2k,Nt4) MCDBA
"CHANGE USERNAME TO westes" <DELETE_westes@earthbroadcast.com> wrote in
message news:O3A1ClqaEHA.1656@TK2MSFTNGP09.phx.gbl...
> 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.
>
> --
> Will
> westes AT earthbroadcast.com
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

"CHANGE USERNAME TO westes" <DELETE_westes@earthbroadcast.com> wrote in
message news:eflHw7oaEHA.2840@TK2MSFTNGP11.phx.gbl...
> 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.

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

"Karl Levinson [x y] mvp" <levinson_k@despammed.com> wrote in message
news:uCalSmyaEHA.2388@TK2MSFTNGP11.phx.gbl...

> 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.

--
Will
westes AT earthbroadcast.com

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

"Roger Abell" <mvpNOSpam@asu.edu> wrote in message
news:uWH51PuaEHA.3356@tk2msftngp13.phx.gbl...
> 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.

--
Will
westes AT earthbroadcast.com

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

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

"CHANGE USERNAME TO westes" <DELETE_westes@earthbroadcast.com> wrote in
message news:eflHw7oaEHA.2840@TK2MSFTNGP11.phx.gbl...
> 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.
>
> --
> Will
> westes AT earthbroadcast.com
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

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

"CHANGE USERNAME TO westes" <DELETE_westes@earthbroadcast.com> wrote in
message news:ukvKpS1aEHA.3988@tk2msftngp13.phx.gbl...
>
> "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
> news:uWH51PuaEHA.3356@tk2msftngp13.phx.gbl...
> > 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.
>
> --
> Will
> westes AT earthbroadcast.com
>
>