Validating a WDFOBJECT handle

This legacy driver I am porting has a set of related IOCTLs, one of
which creates an object (in kernel mode) and returns an “ID”, and the
others which pass that ID in. The “ID” is simply a pointer to a
structure which retains state across the different requests; the
existing code uses that pointer directly, with no validation (ick).

I know there’s no real way to validate a pointer in kernel mode. I
thought perhaps I could instead create a WDF object and attach the state
structure as the context. However, I don’t see a call which validates a
WDF handle as being valid either.

How to others solve this problem? One way I can see is to create the
object, return the context pointer, and use WdfObjectContextGetObject to
validate the “ID” in subsequent calls. However, the docs don’t say what
happens if the context pointer passed to WdfObjectContextGetObject is
not a valid pointer, or is not context pointer for a valid object.

I also thought of adding the objects to a WDF collection, returning the
handle, and scanning the collection to see if the handle was present.
There won’t normally be lots of these objects (usually only one or two,
perhaps as many as 8), so this won’t be a performance issue.

Figured I’d ask the list in case there’s a cleaner way to deal with this.

Cheers,

– mkj


//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________

Change the pointer to a hash or similar random value, to be looked up in a
small table (one per file object assuming the possibility of multiple
applications). The table would then contain the pointer to the WDFOBJECT.


Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Michael Jones” wrote in message
news:xxxxx@ntdev…
> This legacy driver I am porting has a set of related IOCTLs, one of which
> creates an object (in kernel mode) and returns an “ID”, and the others
> which pass that ID in. The “ID” is simply a pointer to a structure which
> retains state across the different requests; the existing code uses that
> pointer directly, with no validation (ick).
>
> I know there’s no real way to validate a pointer in kernel mode. I
> thought perhaps I could instead create a WDF object and attach the state
> structure as the context. However, I don’t see a call which validates a
> WDF handle as being valid either.
>
> How to others solve this problem? One way I can see is to create the
> object, return the context pointer, and use WdfObjectContextGetObject to
> validate the “ID” in subsequent calls. However, the docs don’t say what
> happens if the context pointer passed to WdfObjectContextGetObject is not
> a valid pointer, or is not context pointer for a valid object.
>
> I also thought of adding the objects to a WDF collection, returning the
> handle, and scanning the collection to see if the handle was present.
> There won’t normally be lots of these objects (usually only one or two,
> perhaps as many as 8), so this won’t be a performance issue.
>
> Figured I’d ask the list in case there’s a cleaner way to deal with this.
>
> Cheers,
>
> – mkj
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //

>

Other’s solve this problem with a ‘handle table’. The validation step is to
search the handle table to determine if the handle passed from usermode

  1. Exists.
  2. Identifies an object of the correct ‘type’ (if you have such a thing).

The value of the handle may well be a pointer but you cannot dereference it
until it is validated (as you well have pointed out). The only way to
‘validate’ it without dereferencing it that I can think of is to have a
table of valid values somewhere that you can search on. Of course there
are a myriad of choices of how to implement this (efficiently in time &
space) but the basic concept is table search.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michael Jones
Sent: Wednesday, February 18, 2009 9:33 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Validating a WDFOBJECT handle

This legacy driver I am porting has a set of related IOCTLs, one of
which creates an object (in kernel mode) and returns an “ID”, and the
others which pass that ID in. The “ID” is simply a pointer to a
structure which retains state across the different requests; the
existing code uses that pointer directly, with no validation (ick).

I know there’s no real way to validate a pointer in kernel mode. I
thought perhaps I could instead create a WDF object and attach the state
structure as the context. However, I don’t see a call which validates a
WDF handle as being valid either.

How to others solve this problem? One way I can see is to create the
object, return the context pointer, and use WdfObjectContextGetObject to
validate the “ID” in subsequent calls. However, the docs don’t say what
happens if the context pointer passed to WdfObjectContextGetObject is
not a valid pointer, or is not context pointer for a valid object.

I also thought of adding the objects to a WDF collection, returning the
handle, and scanning the collection to see if the handle was present.
There won’t normally be lots of these objects (usually only one or two,
perhaps as many as 8), so this won’t be a performance issue.

Figured I’d ask the list in case there’s a cleaner way to deal with this.

Cheers,

– mkj


//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________


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

There is no way to validate a random vlaue to see if it is a kmdf handle. Same for

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Michael Jones
Sent: Wednesday, February 18, 2009 6:35 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Validating a WDFOBJECT handle

This legacy driver I am porting has a set of related IOCTLs, one of
which creates an object (in kernel mode) and returns an “ID”, and the
others which pass that ID in. The “ID” is simply a pointer to a
structure which retains state across the different requests; the
existing code uses that pointer directly, with no validation (ick).

I know there’s no real way to validate a pointer in kernel mode. I
thought perhaps I could instead create a WDF object and attach the state
structure as the context. However, I don’t see a call which validates a
WDF handle as being valid either.

How to others solve this problem? One way I can see is to create the
object, return the context pointer, and use WdfObjectContextGetObject to
validate the “ID” in subsequent calls. However, the docs don’t say what
happens if the context pointer passed to WdfObjectContextGetObject is
not a valid pointer, or is not context pointer for a valid object.

I also thought of adding the objects to a WDF collection, returning the
handle, and scanning the collection to see if the handle was present.
There won’t normally be lots of these objects (usually only one or two,
perhaps as many as 8), so this won’t be a performance issue.

Figured I’d ask the list in case there’s a cleaner way to deal with this.

Cheers,

– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//



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

There is no way to validate a random value to see if it is a kmdf handle, even if there was, you should not use it because if you did it gives a malicious app the ability to probe structures it should not have access to. WdfObjectContextGetObject also requires a valid context pointer, the docs do not mention invalid pointers because invalid pointers are treated the same across all KM APIs, they are treated as valid pointers because there is no way to validate them.

So, in the cases where i have done the same thing as you, i have kept a linked list with LIST_ENTRYs for the app sent cookies i want to validate, guarded by a spinlock. Since the number of objects are small, there was no need for something fancier like a table, self balancing tree, or other complex data structure. You can use a wdf collection, just be aware that adding an object to it can fail because it requires an alloc internally to add the object to its list

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Michael Jones
Sent: Wednesday, February 18, 2009 6:35 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Validating a WDFOBJECT handle

This legacy driver I am porting has a set of related IOCTLs, one of
which creates an object (in kernel mode) and returns an “ID”, and the
others which pass that ID in. The “ID” is simply a pointer to a
structure which retains state across the different requests; the
existing code uses that pointer directly, with no validation (ick).

I know there’s no real way to validate a pointer in kernel mode. I
thought perhaps I could instead create a WDF object and attach the state
structure as the context. However, I don’t see a call which validates a
WDF handle as being valid either.

How to others solve this problem? One way I can see is to create the
object, return the context pointer, and use WdfObjectContextGetObject to
validate the “ID” in subsequent calls. However, the docs don’t say what
happens if the context pointer passed to WdfObjectContextGetObject is
not a valid pointer, or is not context pointer for a valid object.

I also thought of adding the objects to a WDF collection, returning the
handle, and scanning the collection to see if the handle was present.
There won’t normally be lots of these objects (usually only one or two,
perhaps as many as 8), so this won’t be a performance issue.

Figured I’d ask the list in case there’s a cleaner way to deal with this.

Cheers,

– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//



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

There most likely will be multiple apps, so thanks for pointing out the
need to key this by file object; I had forgotten about that.

Not sure what hashing the pointer would buy me though; as long as I am
looking up the {pointer | handle} value in some sort of list, before I
ever try using it, what benefit does the hashing provide? I suppose it
obscures the pointer value from user-mode, but it’s not really providing
any security. I feel like there’s something I’m missing…

Cheers,

–mkj

Don Burn wrote:

Change the pointer to a hash or similar random value, to be looked up in a
small table (one per file object assuming the possibility of multiple
applications). The table would then contain the pointer to the WDFOBJECT.


//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________

The main reason for hashing or permuting it is, that you can then be fairly
certain that there is no probing for a “handle” or that somehow a stale
handle is used.


Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Michael Jones” wrote in message
news:xxxxx@ntdev…
> There most likely will be multiple apps, so thanks for pointing out the
> need to key this by file object; I had forgotten about that.
>
> Not sure what hashing the pointer would buy me though; as long as I am
> looking up the {pointer | handle} value in some sort of list, before I
> ever try using it, what benefit does the hashing provide? I suppose it
> obscures the pointer value from user-mode, but it’s not really providing
> any security. I feel like there’s something I’m missing…
>
> Cheers,
>
> --mkj
>
> Don Burn wrote:
>> Change the pointer to a hash or similar random value, to be looked up in
>> a small table (one per file object assuming the possibility of multiple
>> applications). The table would then contain the pointer to the
>> WDFOBJECT.
>>
>>
>
> –
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //

>

Hashing can provide some protection against ‘guessing’ the value of a
pointer from usermode. It can also provide some protection against having a
‘stale’ value become ‘valid’ again if the hash also takes into account some
‘salt’ like system time or some such.

The per-FILE_OBJECT handle table is very useful (indeed, necessary) if the
handle represents a ‘reference’ to the object that keeps the object ‘alive’.
You need to be able to release the references when the FILE_OBJECT is
closed. If your system does not actually grant a ‘reference’ to the
usermode application but simply an ‘identifier’ (that may or may not be
valid in the future) and lifetime is completely controlled by the kernel
mode driver, you might not need a per-FileObj table but you *definitely*
needs some way to know a handle (when issued) referred to an object now
deleted.

By using a some ‘temporal’ (or random) salt in the hash, you can distribute
the handle values to reduce the likelyhood of a stale handle being reused.

-Dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michael Jones
Sent: Wednesday, February 18, 2009 11:47 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Validating a WDFOBJECT handle

There most likely will be multiple apps, so thanks for pointing out the
need to key this by file object; I had forgotten about that.

Not sure what hashing the pointer would buy me though; as long as I am
looking up the {pointer | handle} value in some sort of list, before I
ever try using it, what benefit does the hashing provide? I suppose it
obscures the pointer value from user-mode, but it’s not really providing
any security. I feel like there’s something I’m missing…

Cheers,

–mkj

Don Burn wrote:

Change the pointer to a hash or similar random value, to be looked up in a

small table (one per file object assuming the possibility of multiple
applications). The table would then contain the pointer to the WDFOBJECT.


//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________


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, I’m going stop duplicating what Don says now … :slight_smile:

-Dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, February 18, 2009 11:53 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Validating a WDFOBJECT handle

The main reason for hashing or permuting it is, that you can then be fairly
certain that there is no probing for a “handle” or that somehow a stale
handle is used.


Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

If the list is per file object and the list only contains “handles” that you have handed back on that fileobj, what is the harm in probing? It is not as if another app can even get to the list. If you has on the pointer value itself, stale values will hash to the same bucket. Imho you hash for speed based on the number of items in the collection, not necessarily for additional sanity checks.

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Don Burn
Sent: Wednesday, February 18, 2009 8:55 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Validating a WDFOBJECT handle

The main reason for hashing or permuting it is, that you can then be fairly
certain that there is no probing for a “handle” or that somehow a stale
handle is used.


Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Michael Jones” wrote in message
news:xxxxx@ntdev…
> There most likely will be multiple apps, so thanks for pointing out the
> need to key this by file object; I had forgotten about that.
>
> Not sure what hashing the pointer would buy me though; as long as I am
> looking up the {pointer | handle} value in some sort of list, before I
> ever try using it, what benefit does the hashing provide? I suppose it
> obscures the pointer value from user-mode, but it’s not really providing
> any security. I feel like there’s something I’m missing…
>
> Cheers,
>
> --mkj
>
> Don Burn wrote:
>> Change the pointer to a hash or similar random value, to be looked up in
>> a small table (one per file object assuming the possibility of multiple
>> applications). The table would then contain the pointer to the
>> WDFOBJECT.
>>
>>
>
> –
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //

>


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

Doron,

I’m paranoid on security, so I do not assume the application that did
the open is friendly, the cost of the check is going to be essentially the
same, so there is no performance problem. Years ago, I cracked a security
product which used the pointer approach and was amazed to find what I could
do to the system (up to and including wiping the disk), so to me the
paranoia is always justified.


Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Doron Holan” wrote in message
news:xxxxx@ntdev…
If the list is per file object and the list only contains “handles” that you
have handed back on that fileobj, what is the harm in probing? It is not as
if another app can even get to the list. If you has on the pointer value
itself, stale values will hash to the same bucket. Imho you hash for speed
based on the number of items in the collection, not necessarily for
additional sanity checks.

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Don Burn
Sent: Wednesday, February 18, 2009 8:55 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Validating a WDFOBJECT handle

The main reason for hashing or permuting it is, that you can then be fairly
certain that there is no probing for a “handle” or that somehow a stale
handle is used.


Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Michael Jones” wrote in message
news:xxxxx@ntdev…
> There most likely will be multiple apps, so thanks for pointing out the
> need to key this by file object; I had forgotten about that.
>
> Not sure what hashing the pointer would buy me though; as long as I am
> looking up the {pointer | handle} value in some sort of list, before I
> ever try using it, what benefit does the hashing provide? I suppose it
> obscures the pointer value from user-mode, but it’s not really providing
> any security. I feel like there’s something I’m missing…
>
> Cheers,
>
> --mkj
>
> Don Burn wrote:
>> Change the pointer to a hash or similar random value, to be looked up in
>> a small table (one per file object assuming the possibility of multiple
>> applications). The table would then contain the pointer to the
>> WDFOBJECT.
>>
>>
>
> –
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //

>


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

Of course, the driver must handle the case of a stale handle anyway. The sole benefit of that concept is to hide application bugs from the app, wherein it uses a handle (of some sort, keeping in mind that we’re not speaking of EXHANDLEs) after deleting it.

For example, this is what the uniqifier field in user/gdi handles is for, to guard apps from blowing themselves over due to their own bugs.

However, none of this excuses the driver writer from ensuring that anything getting by said handle table is valid and guaranteed to remain valid for its usage by the driver.

  • S

-----Original Message-----
From: Don Burn
Sent: Wednesday, February 18, 2009 08:53
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Validating a WDFOBJECT handle

The main reason for hashing or permuting it is, that you can then be fairly
certain that there is no probing for a “handle” or that somehow a stale
handle is used.


Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Michael Jones” wrote in message
news:xxxxx@ntdev…
> There most likely will be multiple apps, so thanks for pointing out the
> need to key this by file object; I had forgotten about that.
>
> Not sure what hashing the pointer would buy me though; as long as I am
> looking up the {pointer | handle} value in some sort of list, before I
> ever try using it, what benefit does the hashing provide? I suppose it
> obscures the pointer value from user-mode, but it’s not really providing
> any security. I feel like there’s something I’m missing…
>
> Cheers,
>
> --mkj
>
> Don Burn wrote:
>> Change the pointer to a hash or similar random value, to be looked up in
>> a small table (one per file object assuming the possibility of multiple
>> applications). The table would then contain the pointer to the
>> WDFOBJECT.
>>
>>
>
> –
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //

>


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

That is exactly my line of thought. The driver already has to validate the cookie and then the state of the underlying object regardless of how the cookie was created. The object state validation covers the stale handle reuse or misuse by the app itself (let’s say there is a clear set of IOCTLs that must be in sequence a->b->c and they send a->c, you still have to catch this if they send the right cookie value).

So it comes back down to how you find the object in your data structure, obscuring the hash value you created by salting with some temporal inputs is fine I guess, it just means that brute force is a little harder, not impossible. I would much rather concentrate on keeping the code simple and doing the right type of validation of input rather than making it harder to guess what the correct input could be.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, February 18, 2009 9:58 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Validating a WDFOBJECT handle

Of course, the driver must handle the case of a stale handle anyway. The sole benefit of that concept is to hide application bugs from the app, wherein it uses a handle (of some sort, keeping in mind that we’re not speaking of EXHANDLEs) after deleting it.

For example, this is what the uniqifier field in user/gdi handles is for, to guard apps from blowing themselves over due to their own bugs.

However, none of this excuses the driver writer from ensuring that anything getting by said handle table is valid and guaranteed to remain valid for its usage by the driver.

  • S

-----Original Message-----
From: Don Burn
Sent: Wednesday, February 18, 2009 08:53
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Validating a WDFOBJECT handle

The main reason for hashing or permuting it is, that you can then be fairly
certain that there is no probing for a “handle” or that somehow a stale
handle is used.


Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Michael Jones” wrote in message
news:xxxxx@ntdev…
> There most likely will be multiple apps, so thanks for pointing out the
> need to key this by file object; I had forgotten about that.
>
> Not sure what hashing the pointer would buy me though; as long as I am
> looking up the {pointer | handle} value in some sort of list, before I
> ever try using it, what benefit does the hashing provide? I suppose it
> obscures the pointer value from user-mode, but it’s not really providing
> any security. I feel like there’s something I’m missing…
>
> Cheers,
>
> --mkj
>
> Don Burn wrote:
>> Change the pointer to a hash or similar random value, to be looked up in
>> a small table (one per file object assuming the possibility of multiple
>> applications). The table would then contain the pointer to the
>> WDFOBJECT.
>>
>>
>
> –
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //

>


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


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

Doron is of course right by stating a requirement that the validation
*ensure* the handle does not represent some long deleted object.

I was simply explaining that if ‘reducing the likelyhood’ is your goal
(instead of *ensuring*), a hash can help reduce the likelihood.

Differing requirements. I was not pretending to know what yours actually
are. Doron is being very astute and safe by assuming the most stringent
possible requirement.

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, February 18, 2009 1:20 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Validating a WDFOBJECT handle

That is exactly my line of thought. The driver already has to validate the
cookie and then the state of the underlying object regardless of how the
cookie was created. The object state validation covers the stale handle
reuse or misuse by the app itself (let’s say there is a clear set of IOCTLs
that must be in sequence a->b->c and they send a->c, you still have to catch
this if they send the right cookie value).

So it comes back down to how you find the object in your data structure,
obscuring the hash value you created by salting with some temporal inputs is
fine I guess, it just means that brute force is a little harder, not
impossible. I would much rather concentrate on keeping the code simple and
doing the right type of validation of input rather than making it harder to
guess what the correct input could be.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, February 18, 2009 9:58 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Validating a WDFOBJECT handle

Of course, the driver must handle the case of a stale handle anyway. The
sole benefit of that concept is to hide application bugs from the app,
wherein it uses a handle (of some sort, keeping in mind that we’re not
speaking of EXHANDLEs) after deleting it.

For example, this is what the uniqifier field in user/gdi handles is for, to
guard apps from blowing themselves over due to their own bugs.

However, none of this excuses the driver writer from ensuring that anything
getting by said handle table is valid and guaranteed to remain valid for its
usage by the driver.

  • S

-----Original Message-----
From: Don Burn
Sent: Wednesday, February 18, 2009 08:53
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Validating a WDFOBJECT handle

The main reason for hashing or permuting it is, that you can then be fairly
certain that there is no probing for a “handle” or that somehow a stale
handle is used.


Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Michael Jones” wrote in message
news:xxxxx@ntdev…
> There most likely will be multiple apps, so thanks for pointing out the
> need to key this by file object; I had forgotten about that.
>
> Not sure what hashing the pointer would buy me though; as long as I am
> looking up the {pointer | handle} value in some sort of list, before I
> ever try using it, what benefit does the hashing provide? I suppose it
> obscures the pointer value from user-mode, but it’s not really providing
> any security. I feel like there’s something I’m missing…
>
> Cheers,
>
> --mkj
>
> Don Burn wrote:
>> Change the pointer to a hash or similar random value, to be looked up in
>> a small table (one per file object assuming the possibility of multiple
>> applications). The table would then contain the pointer to the
>> WDFOBJECT.
>>
>>
>
> –
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //

>


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


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


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

Well, given that the existing (legacy) driver does essentially nothing
(worse, it trusts the app :-), anything I do will be an improvement.
The way the IOCTLs work, I can’t really *ensure* the handle is not
stale; I can only reduce the likelihood. Basically, there’s a create
IOCTL, a destroy IOCTL, and then 4 others that only really depend on the
create having happened.

At a minimum I want to verify that the handle currently exists. I will
reduce the likelihood of stale pointers by generating my own “cookie”
instead of returning a pointer or handle value directly. I’m not too
worried about the “probing” problem; I don’t see what I can do to
prevent it beyond maintaining my cookie lists per file object. There’s
also a limit to how much time the client will pay me to fix a driver
that they’ve been happy with for some time ;-).

The whole discussion has been interesting and useful, especially the
per-file-object and the staleness issues, which I hadn’t thought of. As
usual, I always learn something useful from the group!

Cheers,

–mkj

David R. Cattley wrote:

Doron is of course right by stating a requirement that the validation
*ensure* the handle does not represent some long deleted object.

I was simply explaining that if ‘reducing the likelyhood’ is your goal
(instead of *ensuring*), a hash can help reduce the likelihood.

Differing requirements. I was not pretending to know what yours actually
are. Doron is being very astute and safe by assuming the most stringent
possible requirement.

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, February 18, 2009 1:20 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Validating a WDFOBJECT handle

That is exactly my line of thought. The driver already has to validate the
cookie and then the state of the underlying object regardless of how the
cookie was created. The object state validation covers the stale handle
reuse or misuse by the app itself (let’s say there is a clear set of IOCTLs
that must be in sequence a->b->c and they send a->c, you still have to catch
this if they send the right cookie value).

So it comes back down to how you find the object in your data structure,
obscuring the hash value you created by salting with some temporal inputs is
fine I guess, it just means that brute force is a little harder, not
impossible. I would much rather concentrate on keeping the code simple and
doing the right type of validation of input rather than making it harder to
guess what the correct input could be.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, February 18, 2009 9:58 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Validating a WDFOBJECT handle

Of course, the driver must handle the case of a stale handle anyway. The
sole benefit of that concept is to hide application bugs from the app,
wherein it uses a handle (of some sort, keeping in mind that we’re not
speaking of EXHANDLEs) after deleting it.

For example, this is what the uniqifier field in user/gdi handles is for, to
guard apps from blowing themselves over due to their own bugs.

However, none of this excuses the driver writer from ensuring that anything
getting by said handle table is valid and guaranteed to remain valid for its
usage by the driver.

  • S

-----Original Message-----
From: Don Burn
> Sent: Wednesday, February 18, 2009 08:53
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Validating a WDFOBJECT handle
>
>
> The main reason for hashing or permuting it is, that you can then be fairly
> certain that there is no probing for a “handle” or that somehow a stale
> handle is used.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
> “Michael Jones” wrote in message
> news:xxxxx@ntdev…
>> There most likely will be multiple apps, so thanks for pointing out the
>> need to key this by file object; I had forgotten about that.
>>
>> Not sure what hashing the pointer would buy me though; as long as I am
>> looking up the {pointer | handle} value in some sort of list, before I
>> ever try using it, what benefit does the hashing provide? I suppose it
>> obscures the pointer value from user-mode, but it’s not really providing
>> any security. I feel like there’s something I’m missing…
>>
>> Cheers,
>>
>> --mkj
>>
>> Don Burn wrote:
>>> Change the pointer to a hash or similar random value, to be looked up in
>>> a small table (one per file object assuming the possibility of multiple
>>> applications). The table would then contain the pointer to the
>>> WDFOBJECT.
>>>
>>>
>> –
>>
>> //
>> // Michael K. Jones
>> // Stone Hill Consulting, LLC
>> // http://www.stonehill.com
>> //

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



//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//

>

This legacy driver I am porting has a set of related IOCTLs, one of
which creates an object (in kernel mode) and returns an “ID”, and the
others which pass that ID in. The “ID” is simply a pointer to a
structure which retains state across the different requests; the
existing code uses that pointer directly, with no validation (ick).

I know there’s no real way to validate a pointer in kernel mode. I
thought perhaps I could instead create a WDF object and attach the
state
structure as the context. However, I don’t see a call which validates
a
WDF handle as being valid either.

How to others solve this problem? One way I can see is to create the
object, return the context pointer, and use WdfObjectContextGetObject
to
validate the “ID” in subsequent calls. However, the docs don’t say
what
happens if the context pointer passed to WdfObjectContextGetObject is
not a valid pointer, or is not context pointer for a valid object.

I also thought of adding the objects to a WDF collection, returning
the
handle, and scanning the collection to see if the handle was present.
There won’t normally be lots of these objects (usually only one or
two,
perhaps as many as 8), so this won’t be a performance issue.

Figured I’d ask the list in case there’s a cleaner way to deal with
this.

How many of these are you planning on having per ‘file object’? I would
just create a ‘magic’ value (random number) and embed the index in it,
eg if you had a maximum of 16 objects then my ‘magic’ number would look
like 0xRRRRRIRR, where R is a random digit and I is the index. That
would be the handle you return to user space. The index would be into an
array of structures with the following members:

ULONG magic_value; /* must be same as the handle */
BOOLEAN is_open;
WDFOBJECT object;

If you had more than 16 possible objects then the memory space required
by the array starts to get a bit expensive… at that point maybe you
would have an array of pointers and allocate the elements on demand.
Over 256 though and you need to start looking for another way. A hash
table with a chain of objects (for where you have hash collisions) would
probably still give good performance.

James

The number of these things really depends on the system configuration
and the application design. Although *I* can’t imagine having more than
one or two, 8 at the most per application, it is theoretically possible
to have up to 2048. I doubt it is actually possible (the max depends on
the particular system configuration, where the hardware is external to
the PC), but there’s really no reason to limit it to a small number.
Building a list (actually, I’m using a WDFCOLLECTION) is simple enough,
and then the app engineers can create these things until they run out of
RAM.

Cheers,

–mkj

James Harper wrote:

> This legacy driver I am porting has a set of related IOCTLs, one of
> which creates an object (in kernel mode) and returns an “ID”, and the
> others which pass that ID in. The “ID” is simply a pointer to a
> structure which retains state across the different requests; the
> existing code uses that pointer directly, with no validation (ick).
>
> I know there’s no real way to validate a pointer in kernel mode. I
> thought perhaps I could instead create a WDF object and attach the
state
> structure as the context. However, I don’t see a call which validates
a
> WDF handle as being valid either.
>
> How to others solve this problem? One way I can see is to create the
> object, return the context pointer, and use WdfObjectContextGetObject
to
> validate the “ID” in subsequent calls. However, the docs don’t say
what
> happens if the context pointer passed to WdfObjectContextGetObject is
> not a valid pointer, or is not context pointer for a valid object.
>
> I also thought of adding the objects to a WDF collection, returning
the
> handle, and scanning the collection to see if the handle was present.
> There won’t normally be lots of these objects (usually only one or
two,
> perhaps as many as 8), so this won’t be a performance issue.
>
> Figured I’d ask the list in case there’s a cleaner way to deal with
this.

How many of these are you planning on having per ‘file object’? I would
just create a ‘magic’ value (random number) and embed the index in it,
eg if you had a maximum of 16 objects then my ‘magic’ number would look
like 0xRRRRRIRR, where R is a random digit and I is the index. That
would be the handle you return to user space. The index would be into an
array of structures with the following members:

ULONG magic_value; /* must be same as the handle */
BOOLEAN is_open;
WDFOBJECT object;

If you had more than 16 possible objects then the memory space required
by the array starts to get a bit expensive… at that point maybe you
would have an array of pointers and allocate the elements on demand.
Over 256 though and you need to start looking for another way. A hash
table with a chain of objects (for where you have hash collisions) would
probably still give good performance.

James


//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________