I’m gathering some info about loaded drivers by looking at their PE headers
in memory. In particular, I’m looking at their import table that appears to
be (partially) placed into “INIT” segment which is gone for drivers that
were initialized before my driver got started.
P.S. It’s not a commercial product I’m talking about. It’s a development
tool that I wrote and have been using for a while to track my driver’s
memory allocations. But then I decided to improve it just a bit… and
voila! 
Regards,
Vladimir
-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: Wednesday, May 14, 2003 2:40 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Checking if an arbitrary address is accessible
i’m curious why you’re trying to access arbitrary pointers in kernel
space. Kernel components and other drivers are assumed to be “correct”
and thus shouldn’t be handing you bogus pointers.
-p
From: Vladimir Chtchetkine
[mailto:xxxxx@borland.com]
Sent: Wednesday, May 14, 2003 11:36 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Checking if an arbitrary address is
accessible
Still, question remains on how to safely access address in KM
space…
Thanks,
Vladimir
-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: Wednesday, May 14, 2003 11:37 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Checking if an arbitrary address is
accessible
Assuming you capture the parameters such that the driver can’t
trick you
into accessing a kernel-mode address i believe this should be
true.
-----Original Message-----
> From: Nick Ryan [mailto:xxxxx@nryan.com]
> Sent: Wednesday, May 14, 2003 11:05 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Checking if an arbitrary address is
accessible
>
> Thanks. My concern was that I was wondering if there is
> anything a user-mode program can do to a valid piece of
> user-mode memory to make it invalid in such a way that access
> to that address by a driver would cause a bugcheck instead of
> an exception that can be caught. If not, then once
> ProbeForRead/Write validates the address is in user-mode, and
> I wrap all subsequent access in __try/__except, I surmise
> that there is nothing the user-mode app can do to the memory
> crash my driver. Is this correct?
>
> Yes, calling ProbeForRead(UserBuffer->RandomPointer,
> UserBuffer->RandomLength) like that is bad, because
> UserBuffer is being
> dereferenced before it is probed, so an attacker can pass up
> an invalid kernel-mode address and cause a bugcheck. And yes,
> once UserBuffer is validated, UserBuffer->RandomLength should
> be copied to a local variable and then that variable used
> instead to guard against it being changed by a the user.
>
> - Nick Ryan
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Peter
Wieland
> > Sent: Wednesday, May 14, 2003 9:27 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: Checking if an arbitrary address is
accessible
> >
> >
> > there’s only a race if you assumed that
> ProbeFor[Read|Write] is enough
> > to make your access attempt safe. It’s not.
> >
> > ProbeFor[Read|Write] makes sure the buffer is initially
valid and
> > user-mode for parameter checking purposes. However you
> still need to
> > wrap your access of the buffer in a _try/_except to catch
the
> > exceptions that are raised when an invalid pageable address
is
> > accessed. Even ensuring the buffer’s protections can’t be
changed
> > (with secure virtual
> > memory) doesn’t entirely alleviate the need to wrap the
access in a
> > _try/_except since the page may not be resident, and the
> corresponding
> > page-fault could always fail (raising a
> > 0xc0000006 exception).
> >
> > The opportunity for the application to attack you rises if
> you write
> > code like
> >
> > ProbeForRead(UserBuffer->RandomPointer,
> > UserBuffer->RandomLength);
> > RtlCopyMemory(UserBuffer->RandomPointer,
> > InterestingBuffer, InterestingBufferLength);
> >
> > since the app could change the contents of UserBuffer
> between the two
> > instructions. This is why you need to copy (or
> > capture) the values of parameters residing in user-mode
> buffers before
> > validating them.
> >
> > -p
> >
> > > -----Original Message-----
> > > From: Nick Ryan [mailto:xxxxx@nryan.com]
> > > Sent: Tuesday, May 13, 2003 8:26 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] RE: Checking if an arbitrary address is
> accessible
> > >
> > > Bug check 0x50 cannot be protected by __try/__except, only
by a
> > > ProbeForRead/Write call. According to the DDK,
ProbeForRead/Write
> > > validates that a user-mode buffer actually resides in the
user
> > > portion of the address space, and is correctly aligned
> (and I infer
> > > it also checks that the memory is allocated). It
transforms these
> > > conditions into exceptions that can be caught by your
driver.
> > >
> > > A question to the list: Now isn’t there a race condition
> between the
> > > time right after the driver calls ProbeForRead/Write and
when it
> > > accesses the memory? Couldn’t another thread in the
user-mode app
> > > slip in and free that memory, thus causing the memory
> access in the
> > > driver to bugcheck? Or does accessing freed memory below
the 2GB
> > > boundary not bugcheck? There is a DDK function called
> > > MmSecureVirtualMemory that claims it can protect a given
range of
> > > process memory from being clobbered by the process until
the time
> > > MmUnsecureVirtualMemory, but wouldn’t the race condition
still
> > > exists if this API is called after ProbeForRead/Write? Or
can it
> > > replace ProbeForRead/Write?
> > >
> > > - Nick Ryan
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of
Vladimir
> > > Chtchetkine
> > > Sent: Tuesday, May 13, 2003 2:10 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Checking if an arbitrary address is
accessible
> > >
> > >
> > > Hello everyone.
> > > I was under impression (apparently wrong) that in order
> to check if
> > > a given address range is accessible I need to
> > > a) Allocate MDL for that address/range
> > > b) Within __try/__except call MmProbeAndLockPages and if
MDL gets
> > > allocated and MmProbeAndLockPages doesn’t cause an
exception I’m
> > > good to call MmGetSystemAddressForMdlSafe and use that
> address to do
> > > whatever I need to do (again, within __try/__except of
course).
> > > Apparently, this doesn’t work quite well since in some
> occasions I’m
> > > getting bugcheck 50 “page fault in nonpaged area” when I
> > > probeandlock virtual address that is invalid.
> > > So, what would be 100% bulletproof algorithm for
validating an
> > > arbitrary virtual address? I’m at APC level here, so I
can’t call
> > > ProbeForXxx…
> > > TIA,
> > > Vladimir
> > > —
> > > 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:
> > > xxxxx@microsoft.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:
> xxxxx@microsoft.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
You are currently subscribed to ntdev as:
xxxxx@borland.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com