Longboard
August 15th, 2006, 09:49 AM
This si a slightly long read;
From one of my favourite coding geniuses, I cant follow more than the basic outline, but, all our winboxes are in the firing line:
-{ Quote: "95% of the planet are dependent on Windows. That's a sad 95%. And no,
there's never been an excuse. Ever. But that's the sad truth. 95%. Or
thereabouts.
So as Vista rolls out, guess what? So does a new kernel model. And it
isn't just about security - there's an ulterior motive. Think about the
classic answer to the following and that should be clue enough.
* Why did Bill Gates abandon Internet Explorer for so many years? *
And notice as well that as always when something stupid is about to
happen, Chief Software Architect Bill Gates will be found peeking from
around the corner.
But we're jumping ahead of our story.
Symantec
Symantec have published a white paper. And it's a good one. And
Symantec are pissed - rightfully.
The paper is called 'Assessment of Vista Kernel Mode Security' and it's
a good paper. And keep in mind that Symantec currently control over 50%
of the Windows security market.
Vista has new kernel mode security, the paper points out.
* driver signing
* 'PatchGuard'
* kernel code integrity checks
* optional 'Secure Bootup' with TPM hardware
* restricted access to \Device\PhysicalMemory
The paper goes on at length about the boot process, and then the
business of driver signing (pointing out that today only eight firms
are allowed to sign drivers) and 'PatchGuard'. The paper shows how one
would go about disabling this feature - against Bill's explicit wishes
of course.
Writing in Phrack, 'Crazylord' showed how physical memory scans could
be used to locate sensitive parts of the kernel. This memory is by
default read-only, but there are ways around everything.
One cute technique, the paper points out, is to find the Global
Descriptor Table and add a ring 0 (kernel mode) call gate. Code can
then issue a 'CALL FAR' to jump right in.
Another trick is to find the Interrupt Descriptor Table and install an
interrupt gate: code can then use an INT to jump into the kernel. All
cute.
On the other hand, the author of this white paper has previously used
physical memory access to fight back: physical memory can be used to
detect BIOS rootkits.
Code Integrity
CI.DLL is a new Windows DLL (shared library). 'CI' stands for 'code
integrity'. CI.DLL is statically linked into the kernel. Of course it
is.
Microsoft's own blurb:
'Code Integrity (CI) protects Windows Vista by verifying that system
binaries haven't been tampered with by malicious code and by ensuring
that there are no unsigned drivers running in kernel mode on the
system. CI starts as Windows starts up. The boot loader checks the
integrity of the kernel, the HAL, and the boot-start drivers. After
these have been verified, the system starts and the memory manager
calls CI to verify any binaries loaded into the kernel memory space.
These binaries are verified by looking up their signatures in system
catalogs. Aside from kernel memory space, CI verifies binaries loaded
into a protected process and system installed dynamic libraries that
implement core cryptographic functions.'
[Maybe you can see it coming already?]
CI and PatchGuard overlap, but CI can be disabled and PatchGuard can
never be. Further, PatchGuard is made by the Windows Core team and
meant to prevent hooking into the OS, whereas CI is made by the DRM
unit and is meant to ensure the integrity of userland code handling
protected content.
[Now you know, right?]
Signed Drivers
Vista signed drivers handling network protocols include the following.
Driver Function
------ --------
NETIO.SYS IP4/IP6 stack
HTTP.SYS HTTP requests
MRXSMB10.SYS SMB 1
MRXSMB20.SYS SMB 2
MRXDAV.sys WebDav
MSRPC.sys RPC
If a hole is found in one of these signed drivers, it could obviously
allow a complete system compromise by remote attack.
Can driver signing be disabled? Yes. To load unsigned drivers, one
needs to patch the kernel (NTOSKRNL) but patching it will invalidate
its signature so WINLOAD will refuse to load it - thus WINLOAD must be
patched first.
[There's always an easy way around, isn't there?]
But Windows Resource Protection (WRP) puts ACLs on files (this is
assuming NTFS) that are not modifiable by admins or the 'LocalSystem'
account - only the 'TrustedInstaller' [sic] has access.
----------------------------------------
The Catch
But here's the catch: both admins and 'LocalSystem' have, as
traditionally, enough privilege to assume ownership of securable
objects - even those owned by the system itself.
So first one enables the SeTakeOwnership privilege, then one takes
ownership of the file with the bitchy ACL, and finally one grants
admins full access via AdjustTokenPrivileges and SetNamedSecurityInfo.
Once WINLOAD is botched, NTOSKRNL can be botched, and after that all
driver signing can be disabled.
And the machine is toast.
All the hacker has to do at this point is 1) disable PatchGuard (which
it now can do) and 2) hook into the NtQueryInformationFile and
NtCreateFile APIs to flip calls to the original unmodified copy - this
prevents userland tools from detecting malfeasance in the system.
----------------------------------------
What's It All Mean?
1. It means that Symantec's Matthew Conover, the author of this white
paper, with assistance from Ollie Whitehouse and Chris Wee, already
discovered a way to totally crack Vista - to the point they in effect
have a rootkit on the system - and this before the danged Vista's even
been released.
2. Microsoft read the papers too, and Conover knows this. Read between
the lines with his paper.
3. Conover knows Microsoft are going to fix this again and change
everything - but he also knows who Microsoft are, and he knows it's
only a matter of time before he cracks their revised system too. And
the next revision after that. And after that. The basic mechanism for
the current crack has been in XPT code for ten years. And the XPT is
not exploiting a bug: this is a design flaw. It's been there ten years.
And Microsoft programmers should know of it. In fact, this entire thing
smacks of the kind of DRM we've seen so many times before: wobbly and
full of holes.
4. This is the painful issue: hackers can always break through, but
third party software houses cannot use illicit methods to access
drivers - and yet the security industry NEED to access these drivers.
5. See where this is leading? Symantec, McAfee, et al: they're all
basically out of business. Microsoft won't grant them access, and even
if they did, they wouldn't be able to keep up with Microsoft's
ever-changing code and security strategy.
6. Customers will be forced to rely only on microsoft security products.
7. But there's another reason for this - with Bill Gates there's always
another reason: DRM. Bill must ensure the ??AA that protected media
make it to the computer with no one eavesdropping on the line. They
will encrypt the **** out of all sorts of media files and only Mister
Bill will be able to decrypt them. If anyone does publish a hack for
his DRM, the US have their trusty DMCA all ready and waiting.
Gee whiz. How convenient. What's IE anyway?
" }-
From one of my favourite coding geniuses, I cant follow more than the basic outline, but, all our winboxes are in the firing line:
-{ Quote: "95% of the planet are dependent on Windows. That's a sad 95%. And no,
there's never been an excuse. Ever. But that's the sad truth. 95%. Or
thereabouts.
So as Vista rolls out, guess what? So does a new kernel model. And it
isn't just about security - there's an ulterior motive. Think about the
classic answer to the following and that should be clue enough.
* Why did Bill Gates abandon Internet Explorer for so many years? *
And notice as well that as always when something stupid is about to
happen, Chief Software Architect Bill Gates will be found peeking from
around the corner.
But we're jumping ahead of our story.
Symantec
Symantec have published a white paper. And it's a good one. And
Symantec are pissed - rightfully.
The paper is called 'Assessment of Vista Kernel Mode Security' and it's
a good paper. And keep in mind that Symantec currently control over 50%
of the Windows security market.
Vista has new kernel mode security, the paper points out.
* driver signing
* 'PatchGuard'
* kernel code integrity checks
* optional 'Secure Bootup' with TPM hardware
* restricted access to \Device\PhysicalMemory
The paper goes on at length about the boot process, and then the
business of driver signing (pointing out that today only eight firms
are allowed to sign drivers) and 'PatchGuard'. The paper shows how one
would go about disabling this feature - against Bill's explicit wishes
of course.
Writing in Phrack, 'Crazylord' showed how physical memory scans could
be used to locate sensitive parts of the kernel. This memory is by
default read-only, but there are ways around everything.
One cute technique, the paper points out, is to find the Global
Descriptor Table and add a ring 0 (kernel mode) call gate. Code can
then issue a 'CALL FAR' to jump right in.
Another trick is to find the Interrupt Descriptor Table and install an
interrupt gate: code can then use an INT to jump into the kernel. All
cute.
On the other hand, the author of this white paper has previously used
physical memory access to fight back: physical memory can be used to
detect BIOS rootkits.
Code Integrity
CI.DLL is a new Windows DLL (shared library). 'CI' stands for 'code
integrity'. CI.DLL is statically linked into the kernel. Of course it
is.
Microsoft's own blurb:
'Code Integrity (CI) protects Windows Vista by verifying that system
binaries haven't been tampered with by malicious code and by ensuring
that there are no unsigned drivers running in kernel mode on the
system. CI starts as Windows starts up. The boot loader checks the
integrity of the kernel, the HAL, and the boot-start drivers. After
these have been verified, the system starts and the memory manager
calls CI to verify any binaries loaded into the kernel memory space.
These binaries are verified by looking up their signatures in system
catalogs. Aside from kernel memory space, CI verifies binaries loaded
into a protected process and system installed dynamic libraries that
implement core cryptographic functions.'
[Maybe you can see it coming already?]
CI and PatchGuard overlap, but CI can be disabled and PatchGuard can
never be. Further, PatchGuard is made by the Windows Core team and
meant to prevent hooking into the OS, whereas CI is made by the DRM
unit and is meant to ensure the integrity of userland code handling
protected content.
[Now you know, right?]
Signed Drivers
Vista signed drivers handling network protocols include the following.
Driver Function
------ --------
NETIO.SYS IP4/IP6 stack
HTTP.SYS HTTP requests
MRXSMB10.SYS SMB 1
MRXSMB20.SYS SMB 2
MRXDAV.sys WebDav
MSRPC.sys RPC
If a hole is found in one of these signed drivers, it could obviously
allow a complete system compromise by remote attack.
Can driver signing be disabled? Yes. To load unsigned drivers, one
needs to patch the kernel (NTOSKRNL) but patching it will invalidate
its signature so WINLOAD will refuse to load it - thus WINLOAD must be
patched first.
[There's always an easy way around, isn't there?]
But Windows Resource Protection (WRP) puts ACLs on files (this is
assuming NTFS) that are not modifiable by admins or the 'LocalSystem'
account - only the 'TrustedInstaller' [sic] has access.
----------------------------------------
The Catch
But here's the catch: both admins and 'LocalSystem' have, as
traditionally, enough privilege to assume ownership of securable
objects - even those owned by the system itself.
So first one enables the SeTakeOwnership privilege, then one takes
ownership of the file with the bitchy ACL, and finally one grants
admins full access via AdjustTokenPrivileges and SetNamedSecurityInfo.
Once WINLOAD is botched, NTOSKRNL can be botched, and after that all
driver signing can be disabled.
And the machine is toast.
All the hacker has to do at this point is 1) disable PatchGuard (which
it now can do) and 2) hook into the NtQueryInformationFile and
NtCreateFile APIs to flip calls to the original unmodified copy - this
prevents userland tools from detecting malfeasance in the system.
----------------------------------------
What's It All Mean?
1. It means that Symantec's Matthew Conover, the author of this white
paper, with assistance from Ollie Whitehouse and Chris Wee, already
discovered a way to totally crack Vista - to the point they in effect
have a rootkit on the system - and this before the danged Vista's even
been released.
2. Microsoft read the papers too, and Conover knows this. Read between
the lines with his paper.
3. Conover knows Microsoft are going to fix this again and change
everything - but he also knows who Microsoft are, and he knows it's
only a matter of time before he cracks their revised system too. And
the next revision after that. And after that. The basic mechanism for
the current crack has been in XPT code for ten years. And the XPT is
not exploiting a bug: this is a design flaw. It's been there ten years.
And Microsoft programmers should know of it. In fact, this entire thing
smacks of the kind of DRM we've seen so many times before: wobbly and
full of holes.
4. This is the painful issue: hackers can always break through, but
third party software houses cannot use illicit methods to access
drivers - and yet the security industry NEED to access these drivers.
5. See where this is leading? Symantec, McAfee, et al: they're all
basically out of business. Microsoft won't grant them access, and even
if they did, they wouldn't be able to keep up with Microsoft's
ever-changing code and security strategy.
6. Customers will be forced to rely only on microsoft security products.
7. But there's another reason for this - with Bill Gates there's always
another reason: DRM. Bill must ensure the ??AA that protected media
make it to the computer with no one eavesdropping on the line. They
will encrypt the **** out of all sorts of media files and only Mister
Bill will be able to decrypt them. If anyone does publish a hack for
his DRM, the US have their trusty DMCA all ready and waiting.
Gee whiz. How convenient. What's IE anyway?
" }-