Hi,
I am using ObRegisterCallbacks and per searching the archives I learned that I need to specify /INTEGRITYCHECK for the routine to succeed.
What does this linker flag actually do? I can’t find documentation on this anywhere.
Thanks,
Matt
Why it should have an impact I don’t know, but for what it does:
http://blogs.msdn.com/maartenb/archive/2009/07/23/performance-impact-of-integritycheck.aspx
–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
wrote in message news:xxxxx@ntdev…
> Hi,
>
> I am using ObRegisterCallbacks and per searching the archives I learned
> that I need to specify /INTEGRITYCHECK for the routine to succeed.
>
> What does this linker flag actually do? I can’t find documentation on this
> anywhere.
>
> Thanks,
> Matt
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4589 (20091109)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
Information from ESET NOD32 Antivirus, version of virus signature database 4589 (20091109)
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
I believe that it sets
IMAGE_OPTIONAL_HEADER::DllCharacteristics | IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY
ntimage.h:
422: #define IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY 0x0080 // Code Integrity Image
See:
Kernel Data and Filtering Support for Windows Server 2008:
AppInit DLLS in Windows 7 and Windows Server 2008 R2:
http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/AppInit_Win7.docx
Good luck,
mm
wrote in message news:xxxxx@ntdev…
> What does this linker flag actually do? I can’t find documentation on this
> anywhere.
This flag seems to be required to sign the file with KMCS (otherwise it
failed for me)
–pa
This option should turn on verification of image page hash signatures when inpaging from disk, IIRC.
- S
-----Original Message-----
From: xxxxx@yahoo.com
Sent: Monday, November 09, 2009 12:40
To: Windows System Software Devs Interest List
Subject: [ntdev] /INTEGRITYCHECK
Hi,
I am using ObRegisterCallbacks and per searching the archives I learned that I need to specify /INTEGRITYCHECK for the routine to succeed.
What does this linker flag actually do? I can’t find documentation on this anywhere.
Thanks,
Matt
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Wanna share what that actually means, and why Windows views this as required for callers of ObRegisterCallback?
I feel like I’m missing an important part of the plot here, because I don’t get why this is a requirement,
Peter
OSR
And if it is a requirment should not this be called out in the WDK
documentation?
–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
wrote in message news:xxxxx@ntdev…
>
>
> Wanna share what that actually means, and why Windows views this as
> required for callers of ObRegisterCallback?
>
> I feel like I’m missing an important part of the plot here, because I
> don’t get why this is a requirement,
>
> Peter
> OSR
>
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4592 (20091110)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
Information from ESET NOD32 Antivirus, version of virus signature database 4592 (20091110)
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
This is mentioned here (and perhaps elsewhere, but this was the first search hit): http://download.microsoft.com/download/4/4/b/44bb7147-f058-4002-9ab2-ed22870e3fe9/Kernal%20Data%20and%20Filtering%20Support%20for%20Windows%20Server%202008.doc
/INTEGRITYCHECK requires that whenever image contents are read in from the disk, they can be validated as matching their signed hashes.
The new-style filtering APIs enforce a policy that they can only be used in conjunction with integrity-verified code. Check out the “4 Requirements and Constraints” section of the above document.
- S
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, November 10, 2009 6:42 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] /INTEGRITYCHECK
Wanna share what that actually means, and why Windows views this as required for callers of ObRegisterCallback?
I feel like I’m missing an important part of the plot here, because I don’t get why this is a requirement,
Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
OK… maybe I get it now. Maybe.
So the point is that the executable has to be signed by the vendor and the per-page hashes computed by the linker… thus indicating (a) the definite origin of the executable and (b) that the executable itself has not been tampered with? Is THAT the intent??
Peter
OSR
> So the point is that the executable has to be signed by the vendor and
the per-page hashes computed by the linker… thus indicating (a) the
definite origin of the executable and (b) that the executable itself has
not been tampered with? Is THAT the intent??
Wouldn’t it also allow to check the page at a later time. Consider the bad habit of some people to patch images in memory, say NTOSKRNL. One could imagine some piece of code checking the “known page hash(es)” against the actual memory contents at a certain interval and bugchecking if they don’t match, for example …
// Oliver
DDKWizard and DDKBUILD: http:
Trunk (potentially unstable) version: http:</http:></http:>
Good question! Does Windows DO that? I don’t know.
Hence my question…
Peter
OSR
+1 - I would like to understand this better too - and all of this should be documented clearly somewhere. (i.e. definitely a reference on ObRegisterCallbacks and the linker documentation should have this flag documented).
So, here is what I think this means:
- Basic signing is just checked once at image load. It doesn’t prevent tampering once the image is loaded.
- /INTEGRITY check has per page hashes so that when a code page is paged out and paged back in it is hashed and checked to make sure it wasn’t modified? I’m assuming that Windows does not do any in-memory verification?
Yes, the intent is that only signed and identified code should use the new filtering APIs.
- S
-----Original Message-----
From: xxxxx@osr.com
Sent: Wednesday, November 11, 2009 19:46
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] /INTEGRITYCHECK
OK… maybe I get it now. Maybe.
So the point is that the executable has to be signed by the vendor and the per-page hashes computed by the linker… thus indicating (a) the definite origin of the executable and (b) that the executable itself has not been tampered with? Is THAT the intent??
Peter
OSR
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
To be honest, I’d imagine that the quickest route to discovering the answer to that would be to spend 5 minutes to write a test driver in a lab environment with testsigning on and try it out.
In any case, however, I would not make any assumptions about being able to tamper with code integrity enforced binaries as that’s clearly going against the grain of what the system is trying to do.
- S
-----Original Message-----
From: xxxxx@osr.com
Sent: Thursday, November 12, 2009 7:13
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] /INTEGRITYCHECK
Good question! Does Windows DO that? I don’t know.
Hence my question…
Peter
OSR
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
We’re asking a broad range of questions here, Ken, very few of which are amenable to answering by “spend[ing] 5 minutes to write a test driver.”
I figured as a security person (I think you are, maybe I’m wrong) and a Microsoft employee you might have and be willing to share some insight into the overall goal/intent of this very unusual requirement. I dunno, maybe you know the guy who’s responsible for architecting or implementing this? Maybe it’s you. Like I said, I don’t know… That’s why I’m asking.
This IS highly unusual, right? I mean, you don’t have to turn on any mystic flags to call KeBugCheck (or whatever) from your driver. Why THESE functions?
I thought that was a reasonable question and you (or somebody else on the list) might be in the right position to answer it. If not, no problem. I’ll track down the dev owner of this feature and ask them next time I’m on campus,
Peter
OSR
No, I don’t do a whole lot of work with code integrity (CI) directly. I’ll try to answer your question as best as I can, though.
It’s the case for a couple of reasons.
- You could use these APIs to subvert the security and auditing capabilities built in to the platform[1], and so there’s a desire to ensure that only folks with at least something of an audit trail leading to their code use them that an administrator could follow up with. The document I linked attempts to capture this fact. There’s a desire to ensure that if there’s to be a platform feature directly exposing those capabilities in supported fashion going forward, that they’re not just going to be purely used by malware from who-knows-where[2].
- Because these are new platform APIs, there’s no compatibility hit with attempting to require that they only be used by identified callers on x86 as they’ve first been introduced with a platform that supports CI.
There has been a gradual shift towards something you might call “platform integrity” for some time with Windows, with visible products such as KMCS, disallowing \Device\PhysicalMemory access from user mode, and soforth. You could consider this a small extension of that into the x86 world, given that the platform is providing a supported mechanism to perform that sort of filtering outside the purview of the normal security system.
[1] Certainly, there are other ways to do this if you can load kernel mode code in today’s world and have malicious intent. I’m simply trying to inform and explain things as the way they are and not descend the whole thread into a tit-for-tat on the whole thing on the perceived merits of X. Code integrity is certainly not going to solve the world’s problems all at once in one release of the platform.
[2] Clearly also, malware can become signed as well, but at least you have a certificate issued by a well-known CA to start your investigation from at that point.
- S
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, November 12, 2009 10:03 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] /INTEGRITYCHECK
We’re asking a broad range of questions here, Ken, very few of which are amenable to answering by “spend[ing] 5 minutes to write a test driver.”
I figured as a security person (I think you are, maybe I’m wrong) and a Microsoft employee you might have and be willing to share some insight into the overall goal/intent of this very unusual requirement. I dunno, maybe you know the guy who’s responsible for architecting or implementing this? Maybe it’s you. Like I said, I don’t know… That’s why I’m asking.
This IS highly unusual, right? I mean, you don’t have to turn on any mystic flags to call KeBugCheck (or whatever) from your driver. Why THESE functions?
I thought that was a reasonable question and you (or somebody else on the list) might be in the right position to answer it. If not, no problem. I’ll track down the dev owner of this feature and ask them next time I’m on campus,
Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
If the following blog entry is true and the implementation details haven’t
changed, this security measure will be very easy to circumvent -
especially since the driver object conveniently provides a pointer to the
image’s data table entry:
http://d.hatena.ne.jp/xna/20080517/1210984806
- Cay
On Thu, 12 Nov 2009 21:12:43 +0100, Skywing
wrote:
> No, I don’t do a whole lot of work with code integrity (CI) directly.
> I’ll try to answer your question as best as I can, though.
>
> It’s the case for a couple of reasons.
>
> - You could use these APIs to subvert the security and auditing
> capabilities built in to the platform[1], and so there’s a desire to
> ensure that only folks with at least something of an audit trail leading
> to their code use them that an administrator could follow up with. The
> document I linked attempts to capture this fact. There’s a desire to
> ensure that if there’s to be a platform feature directly exposing those
> capabilities in supported fashion going forward, that they’re not just
> going to be purely used by malware from who-knows-where[2].
> - Because these are new platform APIs, there’s no compatibility hit with
> attempting to require that they only be used by identified callers on
> x86 as they’ve first been introduced with a platform that supports CI.
>
> There has been a gradual shift towards something you might call
> “platform integrity” for some time with Windows, with visible products
> such as KMCS, disallowing \Device\PhysicalMemory access from user mode,
> and soforth. You could consider this a small extension of that into the
> x86 world, given that the platform is providing a supported mechanism to
> perform that sort of filtering outside the purview of the normal
> security system.
>
> [1] Certainly, there are other ways to do this if you can load kernel
> mode code in today’s world and have malicious intent. I’m simply trying
> to inform and explain things as the way they are and not descend the
> whole thread into a tit-for-tat on the whole thing on the perceived
> merits of X. Code integrity is certainly not going to solve the world’s
> problems all at once in one release of the platform.
>
> [2] Clearly also, malware can become signed as well, but at least you
> have a certificate issued by a well-known CA to start your investigation
> from at that point.
>
> - S
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
> Sent: Thursday, November 12, 2009 10:03 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] /INTEGRITYCHECK
>
>
>
> We’re asking a broad range of questions here, Ken, very few of which are
> amenable to answering by “spend[ing] 5 minutes to write a test driver.”
>
> I figured as a security person (I think you are, maybe I’m wrong) and a
> Microsoft employee you might have and be willing to share some insight
> into the overall goal/intent of this very unusual requirement. I dunno,
> maybe you know the guy who’s responsible for architecting or
> implementing this? Maybe it’s you. Like I said, I don’t know… That’s
> why I’m asking.
>
> This IS highly unusual, right? I mean, you don’t have to turn on any
> mystic flags to call KeBugCheck (or whatever) from your driver. Why
> THESE functions?
>
> I thought that was a reasonable question and you (or somebody else on
> the list) might be in the right position to answer it. If not, no
> problem. I’ll track down the dev owner of this feature and ask them
> next time I’m on campus,
>
> Peter
> OSR
Awesome reply, Ken. Nicely described, clear, and satisfying. Much appreciated, as well.
Thanks for taking the time to explain this.
Peter
OSR
“Cay Bremer” wrote in message news:xxxxx@ntdev…
> If the following blog entry is true and the implementation details haven’t
> changed, this security measure will be very easy to circumvent -
> especially since the driver object conveniently provides a pointer to the
> image’s data table entry:
> http://d.hatena.ne.jp/xna/20080517/1210984806
>
> - Cay
Nothing prevents to keep another pointer, and double-check.
DRM promoters just won’t give up 
– pa