Thanks for investigation, I didn’t have time for it. Now it makes sense. I
didn’t know SDs can be shared and in this case you’re right on-place change
isn’t safe; it can be really dangerous.
As for touching object header: I noticed it only under special conditions.
OSR DeviceTree utility causes it when scanning all devices. The second case
is WinObj when device is selectect and security tab selected.
NtQuerySecurityObject is called which in turn causes a call to
_ObReferenceSecurityDescriptor and _ObDereferenceSecurityDescriptor later.
I’m not sure if it is touched during standard device use.
P.S. I like SoftICE at SMP 
Now one CPU is in busy loop trying to recover
from page fault in kernel (there were zeroes before SD) and I can continue
on the second one.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
From: xxxxx@nryan.com[SMTP:xxxxx@nryan.com]
Reply To: xxxxx@lists.osr.com
Sent: Monday, March 03, 2003 10:41 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] RE: Device driver object security settings to enable
non-priv’d user accessAfter some snooping I’ve partially figured out what’s going on. The
security descriptor is created and assigned to the device object deep in
undocumented function ObAssignSecurity. What happens is this function
creates the base descriptor using SeAssignSecurity - which returns
memory allocated simply by ExAllocatePool. Then the undocumented
function _IopGetSetSecurityObject is called to assign the descriptor to
the device object. However, it doesn’t simply point the device object to
this descriptor - instead it uses an identical descriptor allocated from
a private cache of security descriptors maintained by the Object
Manager. (The original descriptor passed in is just freed). Apparently
this is done for memory savings since objects in this cache are
refcounted to avoid duplication. The additional header you’re seeing
before the memory for the descriptor proper is the header for objects in
this cache.This still doesn’t explain why the header is being touched while the
device object is in use. However, I’m not sure your method of modifying
the descriptor in-place is safe either, since this is a cached and
potentially shared descriptor (descriptors in the cache are indexed by a
hash of the descriptor’s contents). What a mess.
- Nicholas Ryan
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> Sent: Monday, March 03, 2003 11:28 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Device driver object security settings
> to enable non-priv’d user access
>
>
> You missed the point. XP seem to expect object header before
> the SD pointed by device object. So if it points to your
> block of memory, OS accesses and writes to random memory
> before your new SD.
>
> What you describe would only cure symptom and shield the real problem.
>
> Best regards,
>
> Michal Vodicka
> STMicroelectronics Design and Application s.r.o.
> [michal.vodicka@st.com, http:://www.st.com]
>
> > ----------
> > From: xxxxx@nryan.com[SMTP:xxxxx@nryan.com]
> > Reply To: xxxxx@lists.osr.com
> > Sent: Monday, March 03, 2003 8:17 PM
> > To: xxxxx@lists.osr.com
> > Subject: [ntdev] RE: Device driver object security
> settings to enable
> > non-priv’d user access
> >
> > Easiest solution when using the SysInternals approach: save the
> > pointer to the original descriptor, and point the device object to
> > your new descriptor. When it comes time to delete your
> device object,
> > free your descriptor, then point the device object back to the
> > original descriptor, and then delete the device.
> >
> > - Nicholas Ryan
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of
> Michal Vodicka
> > > Sent: Monday, March 03, 2003 10:35 AM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] RE: Device driver object security settings
> > > to enable non-priv’d user access
> > >
> > >
> > > It seems there is a problem with this approach at XP. Last
> > > week I encountered something similar with VMware parallel
> > > driver which access caused random data overwrite. It seemed
> > > as the problem caused my driver I’m working on so I
> > > investigated the problem and found OS tried to access data
> > > before security descriptor for this driver device. The
> > > descriptor was created the way you describe; they create new
> > > one and change
> > > DeviceObject->SecurityDescriptor to its address. They don’t
> > > free the old
> > > DeviceObject->one
> > > and I presume it is because it caused the same problem as
> you have.
> > >
> > > I guess device security descriptor at XP are objects and OS
> > > expects object header prepended to memory pointed with
> > > DeviceObject->SecurityDescriptor. It would explain why
> > > ExFreePool fails: the real allocation starts several bytes
> > > before. Please note I only guess; I’d appreciate if somebody
> > > can confirm or disprove this observation or give any more
> > > info about XP device SDs.
> > >
> > > Also please note above described approach (ignore problem and
> > > don’t free original descriptor) is plain wrong and can cause
> > > BSODs or worse, random data overwrite. You can try different
> > > approach: change original SD contents instead. It is usable
> > > way if all you need is to change an ACE mask. I used it at
> > > w2k with no problem.
> > >
> > > Best regards,
> > >
> > > Michal Vodicka
> > > STMicroelectronics Design and Application s.r.o.
> > > [michal.vodicka@st.com, http:://www.st.com]
> > >
> > > > ----------
> > > > From: Barry.Kierstein@HP.Com[SMTP:Barry.Kierstein@HP.Com]
> > > > Reply To: xxxxx@lists.osr.com
> > > > Sent: Monday, March 03, 2003 6:42 PM
> > > > To: xxxxx@lists.osr.com
> > > > Subject: [ntdev] RE: Device driver object security
> > > settings to enable
> > > > non-priv’d user access
> > > >
> > > > All,
> > > >
> > > > Thanks for your great suggestions. I have followed the
> > > > SysInternals example in modifying the security
> descriptor in the
> > > > device object. There is one remaining oddity.
> > > >
> > > > Basically, the SysInternals example does the following:
> > > > 1) gets the security descriptor from the device object
> > > > (it is in relative format),
> > > > 2) creates an empty absolute format security descriptor,
> > > > 3) reads the device object security descriptor for various
> > > attributes
> > > > and sets these in the absolute security descriptor,
> > > > 4) converts the absolute security descriptor to relative
> > > format security
> > > > descriptor,
> > > > 5) frees the device object’s security descriptor using
> > > ExFreePool, and
> > > > 6) sets the device object’s security descriptor pointer
> to the new
> > > > relative format security descriptor.
> > > >
> > > > This works fine on Windows 2000. On Windows XP, it
> > > bugchecks when
> > > > trying to execute the ExFreePool call with a stop code of 0xC2.
> > > >
> > > > BAD_POOL_CALLER (c2)
> > > > The current thread is making a bad pool request.
> Typically this is
> > > > at a bad IRQL level or double freeing the same allocation, etc.
> > > > Arguments:
> > > > Arg1: 00000007, Attempt to free pool which was already freed
> > > > Arg2: 00000cd4, (reserved)
> > > > Arg3: 00000027, Memory contents of the pool block
> > > > Arg4: e13f5318, Pointer to pool header
> > > >
> > > > Any ideas why this is happening? Thanks…
> > > >
> > > > Barry Kierstein
> > > >
> > > > —
> > > > You are currently subscribed to ntdev as:
> michal.vodicka@st.com To
> > > > unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@nryan.com To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: michal.vodicka@st.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
You are currently subscribed to ntdev as: michal.vodicka@st.com
To unsubscribe send a blank email to xxxxx@lists.osr.com