Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Full Disclosure: Full-Disclosure

Vista Protected Processes Bypassed

 

 

Full Disclosure full-disclosure RSS feed   Index | Next | Previous | View Threaded


randallm at fidmail

Apr 7, 2007, 4:27 PM

Post #1 of 6 (1476 views)
Permalink
Vista Protected Processes Bypassed

___________________________
From: CowboyNeal
Posted At: Saturday, April 07, 2007 11:41 AM
Posted To: Technology
Conversation: Slashdot
Subject: Vista Protected Processes Bypassed

Anonymous Hero writes "Security Researcher Alex Ionescu strikes again, this
time with a proof of concept program that will arbitrarily enable and
foremost disable the protection of so-called 'protected processes' in
Windows Vista. Not only threatening Vista DRM and friends, it's also another
step towards hardened and even more annoying malware. Normally, only
specially signed processes made by special companies (decided by Microsoft)
can be protected, but now the bad guys can protect any evil process they
want, including the latest version of their own keylogger, spambot, or worm,
as well as unprotect any 'good' one."


http://rss.slashdot.org/~r/Slashdot/slashdot/~3/107345575/article.pl

_______________________________--

I am beginning to believe that Vista will be the avenue that catapults
malware writers way ahead of the rest of us. When you "wrestle" with a
better opponent you gain strength and ability.
Attachments: slashdot_3fi_3dE3x2nu (10.7 KB)


redhowlingwolves at bellsouth

Apr 7, 2007, 5:40 PM

Post #2 of 6 (1376 views)
Permalink
Re: Vista Protected Processes Bypassed [In reply to]

If this was the end.........I've heard it all!
From the days when Microsoft wrote the OS for IBM,people were
saying,nay,swearing,to the ends of the earth,how good Bill Gates & Co.'s
code was.Granted,without IBM & MS,the web MAY not be what it is
today.....You know..Ease of use,and so and,and so forth,....

In reality,it's probably very much true.Maybe to the chagrine of many of
the current,and past users of Unix systems.
New OS'es breed new 0Day's,same as ever!
(
I try to use both,MS and many different flavors of
*nix, as many as I can take at one time,OS'es as possible.That way I can
learn,and understand,different feels for,basically the child of a long
ago parent.

Knowledge is only as good as what you choose to use it for.Correct?

Happy Easter to ALL.
Scott

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


kyle.c.quest at gmail

Apr 8, 2007, 8:42 AM

Post #3 of 6 (1364 views)
Permalink
Re: [funsec] Vista Protected Processes Bypassed [In reply to]

This is just a common example of sensationalism...
I don't know where this security researcher struck before,
but he definitely didn't strike anything groundbreaking here :-)

This article is misleading... It confuses features
from the 32-bit Vista and from the 64-bit Vista.

It talks about how only signed drivers are suppose to be allowed...
This is only for 64-bits... It doesn't really apply to the 32-bit
version...

The tool that this security researcher released would work
only on the 32-bit version because it actually hides a simple
driver in the executable. First, it calls RtlAdjustPrivilege
to be able to install a driver (meaning that if you don't
have admin priviledges it's not gonna work). Then it
drops its hidden driver calling RtlDecompressBuffer,
creating a hidden alternative data stream in the crusoe.sys
driver. Next it sets up a registry entry for this hidden driver
and calls NtLoadDriver. The driver itself simply grabs
the process id (passed by the user through what seems
to be the KUSER_SHARED_DATA region), calls
PsLookupProcessByProcessId(pid,&pEprocess), and if the call is successful
it simply clears the 'ProtectedProcess' flag
(pEprocess->Flags2.ProtectedProcess = 0).

This is the same approach used to unlock files that were
open for exclusive I/O operations... you go into the kernel
finding the corresponding data structure and then set the bit
that prevents you from accessing your target :-)

This wouldn't work if the driver really needed to be signed
(which would be the case for the 64-bit version of Vista) unless
somebody finds an exploit to load unsigned code.

Overall, it's not really worse than what you'd have with XP...
I'm not a big fan of Vista, but this is definitely not what
people make it to be.

Kyle


kyle.c.quest at gmail

Apr 8, 2007, 9:07 AM

Post #4 of 6 (1375 views)
Permalink
Re: [funsec] Vista Protected Processes Bypassed [In reply to]

This is just a common example of sensationalism...
I don't know where this security researcher struck before,
but he definitely didn't strike anything groundbreaking here :-)

This article is misleading... It confuses features
from the 32-bit Vista and from the 64-bit Vista.

It talks about how only signed drivers are suppose to be allowed...
This is only for 64-bits... It doesn't really apply to the 32-bit
version...

The tool that this security researcher released would work
only on the 32-bit version because it actually hides a simple
driver in the executable. First, it calls RtlAdjustPrivilege
to be able to install a driver (meaning that if you don't
have admin priviledges it's not gonna work). Then it
drops its hidden driver calling RtlDecompressBuffer,
creating a hidden alternative data stream in the crusoe.sys
driver. Next it sets up a registry entry for this hidden driver
and calls NtLoadDriver. The driver itself simply grabs
the process id (passed by the user through what seems
to be the KUSER_SHARED_DATA region), calls
PsLookupProcessByProcessId(pid,&pEprocess), and if the call is successful
it simply clears the 'ProtectedProcess' flag
(pEprocess->Flags2.ProtectedProcess = 0).

This is the same approach used to unlock files that were
open for exclusive I/O operations... you go into the kernel
finding the corresponding data structure and then set the bit
that prevents you from accessing your target :-)

This wouldn't work if the driver really needed to be signed
(which would be the case for the 64-bit version of Vista) unless
somebody finds an exploit to load unsigned code.

Overall, it's not really worse than what you'd have with XP...
I'm not a big fan of Vista, but this is definitely not what
people make it to be.

Kyle


Valdis.Kletnieks at vt

Apr 8, 2007, 10:41 AM

Post #5 of 6 (1376 views)
Permalink
Re: [funsec] Vista Protected Processes Bypassed [In reply to]

On Sun, 08 Apr 2007 12:07:47 EDT, C Q said:
>
> Overall, it's not really worse than what you'd have with XP...
> I'm not a big fan of Vista, but this is definitely not what
> people make it to be.

That protection bit isn't what people make it to be either, which is
the whole point.

Quite often, the *real* security issue is that the protection a given feature
*actually* provides by design isn't the security that people *think* it
provides. For example, some of us may remember a while ago, when there was
a whole flurry of activity regarding TCP sequence numbers and RST packets.

Turned out that in fact, TCP has *always* worked that way, in that an RST
doesn't have to match exactly, it only needs to be inside the window. When
RTT*bandwidth products were low and windows were small, in a 2**32 sequence
space, the distinction between "match" and "within 16K" was easily overlooked.
The community just needed a slap upside the head, because with multi-megabyte
windows on today's high-speed links, the distinction *is* important....


fernando.gont at gmail

Apr 8, 2007, 2:24 PM

Post #6 of 6 (1375 views)
Permalink
Re: [funsec] Vista Protected Processes Bypassed [In reply to]

At 02:41 p.m. 08/04/2007, Valdis.Kletnieks [at] vt wrote:

>Quite often, the *real* security issue is that the protection a given feature
>*actually* provides by design isn't the security that people *think* it
>provides. For example, some of us may remember a while ago, when there was
>a whole flurry of activity regarding TCP sequence numbers and RST packets.
>
>Turned out that in fact, TCP has *always* worked that way, in that an RST
>doesn't have to match exactly, it only needs to be inside the window. When
>RTT*bandwidth products were low and windows were small, in a 2**32 sequence
>space, the distinction between "match" and "within 16K" was easily overlooked.
>The community just needed a slap upside the head, because with multi-megabyte
>windows on today's high-speed links, the distinction *is* important....

There are some interesting lessons around the RST stuff.

First, while everybody rushed for fancy mechanisms for preventing
reset attacks (e.g., the one we are standardizing at the IETF), many
vendors (still in 2007) do not yet implement TCP port randomization,
which is an obvious mitigation for most attacks against TCP.

Second, in 2005 (a year later after the RST issues) I worked on ICMP
attacks against TCP. One of the attacks had exactly the same impact
as the TCP-based reset attack. However, it required much less effort
on the side of the attacker (no need to guess TCP sequence
numbers)... yet it was overlooked (even after being hit a year later
by the TCP-based counterpart).

Third, regarding the protection people *thinks* that some mechanisms
provide, probably two great examples are IPsec and the TCP MD5
option. Everybody assumed that IPsec and TCP MD5 provided protection
against ICMP-based attacks, when they really didn't, and still do not.

Finally, I'd say that probably the biggest problem with the security
issues in TCP and other core protocols is that everybody assumes that
they know by heart how these protocols work, and that any issues in
them have already already been fixed. Recent history has shown that
both of these assumptions are incorrect.

Kind regards,

--
Fernando Gont
e-mail: fernando [at] gont || fgont [at] acm
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Full Disclosure full-disclosure RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.