Prev: Win64 , InterlockedCompareExchange128 and early AMDs
Next: Retrieving the filesystem name of each partition not mounted
From: Arkady Frenkel on 20 Feb 2007 01:46
Obviously we started this thread talking about very specific IOCTL :), but
any case because read/write access checked for any IOCTL that IMHO have no
problem for big brother to control the situation as he declare
Arkady
"Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in message
news:F6B4572F-48BF-4B55-A146-81FB5DEBACA4(a)microsoft.com...
> Arkady,
>
> Judging from your description of the situation, the whole thing is private
> to
> NDISUIO - if IO Manager or ZwDeviceIoControlFile() had to be aware of
> changes that are applied to individual drivers, it would just violate the
> basic principle of code modularity, defeat the common sense, and make the
> life of code maintainance staff at MSFT a nightmare.
>
>
> This is why I think that blocking specific IOCTLs right by IO Manager or
> DeviceIoControlFile() will never introduced by MSFT, although
> *THEORETICALLY*
> this task is feasible - after all, terms 'feasible' and 'reasonable' are
> not
> synonymous. Up to this point MSFT doesn't seem to have introduced even
> those
> checks that should be done, i.e. DeviceType.....
>
> Anton Bassov
>
> "Arkady Frenkel" wrote:
>
>> Anton!
>> Good question. I have no straight approvement, but if you compare
>> nuiouser.h
>> from DDK ( old when NDISUIO was there ) and and Platform builder one
>> you'll
>> see few new IOCTLS added for windows CE but basic old definitions ( from
>> big
>> windows ) are there and wzc in platform builder use them. All the stucts
>> of
>> wzc were absolutely the same until SP2 and used exactly the same in XP
>> and
>> CE so I appreciate that code of wzc should be the same too. The structs
>> were
>> changed in SP2 members added inside and not at the end so from SP2 was
>> not
>> possible to use code of wzc from CE on XP, as custom wzc developers do
>> before.
>>
>> Arkady
>>
>>
>> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in message
>> news:929076A3-40AE-48EA-B0C2-67C3FB9F35DC(a)microsoft.com...
>> > Arkady,
>> >
>> > What makes you believe that it is IO Manager and not NDISUIO (which
>> > happens
>> > to be MSFT-provided driver) itself who fails these IOCTLs????
>> >
>> > Anton Bassov
>> >
>> > "Arkady Frenkel" wrote:
>> >
>> >> Anton!
>> >> Just recollect example of IOCTL blocking which I somehow forgot even
>> >> with
>> >> custom IOCTLs :
>> >> the example is custom IOCTLs of NDISUIO. When MSFT start to use this
>> >> protocol driver for wireless control ( wzc ) and give NDISPROT instead
>> >> ,
>> >> all
>> >> custom ( once ) IOCTLs of it now denied by the system
>> >>
>> >> Arkady
>> >>
>> >>
>> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in
>> >> message
>> >> news:1D74AB39-E262-433D-B94B-FB1A561344F6(a)microsoft.com...
>> >> > Arkady,
>> >> >
>> >> >> OTOH from the beginning you tried to stand that it's no place where
>> >> >> system
>> >> >> checked IOCTLs and I'm standing from the very begining of this
>> >> >> thread
>> >> >> that
>> >> >> it v.v and IOCTL do checked for that each time IOCTL send from app
>> >> >> to
>> >> >> the
>> >> >> driver.
>> >> >
>> >> >
>> >> > I never said that IOCTLs don't get checked at all - TransferType and
>> >> > RequiredAccess
>> >> > have to get checked, because IO Manager's actions depend on them.
>> >> > What
>> >> > I
>> >> > am
>> >> > saying is that DeviceType and FunctionCode ones don't seem to get
>> >> > checked.
>> >> > In
>> >> > practice, it means that you can send IOCTL_NDIS_QUERY_GLOBAL_STATS
>> >> > in
>> >> > place
>> >> > of any IOCTL that relies upon METHOD_OUT_DIRECT transfer type
>> >> >
>> >> >> IMHO that not important which field of IOCTL checked because if
>> >> >> MSFT
>> >> >> deside to deny that IOCTL OS can check any bit of that but in the
>> >> >> place
>> >> >> where access checked
>> >> >
>> >> > As I said from the very beginning, *THEORETICALLY* this is true.
>> >> > However,
>> >> > let's look at at from the practical point of view. All codes below
>> >> > 0x800
>> >> > are
>> >> > MSFT-reserved. This means that IO Manager would have to check all
>> >> > possible
>> >> > MSFT-defined codes, with the maximal number of 2048(!!!) checks.
>> >> > Imagine
>> >> > the
>> >> > size of
>> >> > switch-case block.....
>> >> >
>> >> > This is about generic checking of whether IOCTL code is appropriate.
>> >> > Certainly, when it comes to blocking some particular code, i.e.
>> >> > IOCTL_NDIS_QUERY_GLOBAL_STATS .... well, they can just block it
>> >> > without
>> >> > any
>> >> > further checks, no matter what (they can justify it by saying that
>> >> > IOCTL_NDIS_QUERY_GLOBAL_STATS implies device of
>> >> > FILE_DEVICE_PHYSICAL_NETCARD
>> >> > type, so that sending it to device of any other type is illegal)
>> >> > without
>> >> > even
>> >> > reaching the point where access type gets checked.
>> >> >
>> >> > However, I am still not sure they want to do things this way -
>> >> > probably,
>> >> > they would not mind to use this IOCTL internally.....
>> >> >
>> >> >
>> >> > Anton Bassov
>> >> >
>> >> >
>> >> > "Arkady Frenkel" wrote:
>> >> >
>> >> >> Anton!
>> >> >>
>> >> >> I write you about registry key or file ( just open registry editor
>> >> >> and
>> >> >> try
>> >> >> to set key forbidden to write ) only with purpose as I understand
>> >> >> that
>> >> >> you
>> >> >> don't want to check that with driver.
>> >> >> OTOH from the beginning you tried to stand that it's no place where
>> >> >> system
>> >> >> checked IOCTLs and I'm standing from the very begining of this
>> >> >> thread
>> >> >> that
>> >> >> it v.v and IOCTL do checked for that each time IOCTL send from app
>> >> >> to
>> >> >> the
>> >> >> driver. IMHO that not important which field of IOCTL checked
>> >> >> because
>> >> >> if
>> >> >> MSFT
>> >> >> deside to deny that IOCTL OS can check any bit of that but in the
>> >> >> place
>> >> >> where access checked
>> >> >>
>> >> >> Arkady
>> >> >>
>> >> >>
>> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in
>> >> >> message
>> >> >> news:81DEE103-97E7-4DF3-BB21-EC17683ADC3B(a)microsoft.com...
>> >> >> >
>> >> >> > Arkady,
>> >> >> >
>> >> >> >> If you have doubts that system will reject writing if only read
>> >> >> >> access
>> >> >> >> allowed , you can check that without any driver, but setting
>> >> >> >> such
>> >> >> >> permissions to files or registry keys and check what happen.
>> >> >> >
>> >> >> > I am afraid you are mixing up two types of access checks...
>> >> >> >
>> >> >> > Basically, there are 2 types of access checks:
>> >> >> >
>> >> >> > 1. Checking whether a user is allowed to open a handle with RW
>> >> >> > access.
>> >> >> > This
>> >> >> > has to be done by ZwCreateFile()
>> >> >> >
>> >> >> > 2. Checking whether requested operation on a handle corresponds
>> >> >> > to
>> >> >> > access
>> >> >> > rights the handle has been opened with. This is done by the
>> >> >> > function
>> >> >> > that
>> >> >> > handles an operation (ZwWriteFile(), ZwDeviceIoControlFile(),
>> >> >> > etc)
>> >> >> >
>> >> >> >
>> >> >> > What you are speaking about is access check of the former type.
>> >> >> > As
>> >> >> > I
>> >> >> > said
>> >> >> > in my previous post, if you haven't got RW access to the file,
>> >> >> > device
>> >> >> > or
>> >> >> > key
>> >> >> > because of the registry settings, you will just fail to open a
>> >> >> > handle
>> >> >> > to
>> >> >> > it
>> >> >> > with RW access - access check of the former type seems to work
>> >> >> > pretty
>> >> >> > well.
>> >> >> >
>> >> >> >
>> >> >> > However, our discussion is all about the check of the latter
>> >> >> > type,
>> >> >> > i.e.
>> >> >> > the
>> >> >> > one that has to be performed by ZwDeviceIoControlFile(). The
>> >> >> > only
>> >> >> > indicative
>> >> >> > test here would be opening a handle to a writeable device with RO
>> >> >> > access,
>> >> >> > and
>> >> >> > sending some IOCTL that involves writing (not calling WriteFile()
>> >> >> > but
>> >> >> > exactly
>> >> >> > sending IOCTL - we speak about implementation of
>> >> >> > ZwDeviceIoControlFile()
>> >> >> > and
>> >> >> > not of ZwWiteFile() here) on this handle.
>> >> >> >
>> >> >> >
>> >> >> > As I said in my previous post, if IOCTL gets blocked (and I
>> >> >> > really
>> >> >> > hope
>> >> >> > it
>> >> >> > does), it happens because of RequiredAccess field and not of
>> >> >> > FunctionCode
>> >> >> > one. As I told you from the very beginning, IOCTL's TransferType
>> >> >> > and
>> >> >> > RequiredAccess fields do matter, but DeviceType and FunctionCode
>> >> >> > ones
>> >> >> > seem
>> >> >> > to get ignored - otherwise,
>> >> >> > sending IOCTL of 1000(dec) would have no chance of success.....
>> >> >> >
>> >> >> >> That is exactly
>> >> >> >> the place where IOCTL_NDIS_QUERY_GLOBAL_STATS or any other
>> >> >> >> IOCTL
>> >> >> >> announced as depricated can be checked for denying.
>> >> >> >
>> >> >> > As you can see, this check has to be done only upon sending
>> >> >> > IOCTL.
>> >> >> > This
>> >> >> > is
>> >> >> > when it *CAN* get checked ...... if MSFT introduces validation of
>> >> >> > DeviceType
>> >> >> > and FunctionCode fields. However, for this or that reason, MSFT
>> >> >> > does
>> >> >> > not
>> >> >> > seem
>> >> >> > to be doing anything in this direction. I think that the main
>> >> >> > reason
>> >> >> > for
>> >> >> > this
>> >> >> > is that checking FunctionCode field may be quite cumbersome
>> >> >> > task.....
>> >> >> >
>> >> >> > Anton Bassov
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > "Arkady Frenkel" wrote:
>> >> >> >
>> >> >> >> Anton!
>> >> >> >> > Well, before you can send IOCTL to the device, you have to
>> >> >> >> > open
>> >> >> >> > its
>> >> >> >> > handle,
>> >> >> >> > in the first place. This is when access check is done. In
>> >> >> >> > fact, I
>> >> >> >> > haven't
>> >> >> >> > tried sending write IOCTL on the handle that has been opened
>> >> >> >> > with
>> >> >> >> > RO
>> >> >> >> > access
>> >> >> >>
>> >> >> >> If you have doubts that system will reject writing if only read
>> >> >> >> access
>> >> >> >> allowed , you can check that without any driver, but setting
>> >> >> >> such
>> >> >> >> permissions to files or registry keys and check what happen.
>> >> >> >> That
>> >> >> >> is
>> >> >> >> exactly
>> >> >> >> the place where IOCTL_NDIS_QUERY_GLOBAL_STATS or any other
>> >> >> >> IOCTL
>> >> >> >> announced as depricated can be checked for denying.
>> >> >> >>
>> >> >> >> Arkady
>> >> >> >>
>> >> >> >> > "Arkady Frenkel" wrote:
>> >> >> >> >
>> >> >> >> >> Anton!
>> >> >> >> >> What do you mean "FunctionCode don't get checked indirectly"?
>> >> >> >> >> When
>> >> >> >> >> read/write request send to object (
>> >> >> >> >> device/regkey/... )without
>> >> >> >> >> read/write
>> >> >> >> >> permissions OS do check FunctionCode and return error.
>> >> >> >> >> Arkady
>> >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote
>> >> >> >> >> in
>> >> >> >> >> message
>> >> >> >> >> news:BA011F4E-6DD3-4E60-8A73-05876B42A804(a)microsoft.com...
>> >> >> >> >> > Arkady,
>> >> >> >> >> >
>> >> >> >> >> > The rules of creating IOCTLs are very strict in
>> >> >> >> >> > windows.....
>> >> >> >> >> >
>> >> >> >> >> > Not really....
>> >> >> >> >> >
>> >> >> >> >> > What really matters are TransferType and RequiredAccess
>> >> >> >> >> > fields
>> >> >> >> >> > (just 4
>> >> >> >> >> > bits
>> >> >> >> >> > out of 32), because IO Manager's actions depend on it.
>> >> >> >> >> > However,
>> >> >> >> >> > when
>> >> >> >> >> > it
>> >> >> >> >> > comes
>> >> >> >> >> > to DeviceType and FunctionCode, no one seems to check them
>> >> >> >> >> >
>> >> >> >> >> > I see what you mean - if some other driver accepts
>> >> >> >> >> > IOCTL_NDIS_QUERY_GLOBAL_STATS, then blocking the request
>> >> >> >> >> > may
>> >> >> >> >> > be
>> >> >> >> >> > excused,
>> >> >> >> >> > because they may say that this driver does not follow the
>> >> >> >> >> > rules.
>> >> >> >> >> > However,
>> >> >> >> >> > the fact that DeviceType and FunctionCode don't get checked
>> >> >> >> >> > indirectly
>> >> >> >> >> > supports my statement that MSFT is quite unlikely to solve
>> >> >> >> >> > the
>> >> >> >> >> > problem
>> >> >> >> >> > this
>> >> >> >> >> > way....
>> >> >> >> >> >
>> >> >> >> >> > Anton Bassov
>> >> >> >> >> >
>> >> >> >> >> > "Arkady Frenkel" wrote:
>> >> >> >> >> >
>> >> >> >> >> >> Anton! The rules of creating IOCTLs are very strict in
>> >> >> >> >> >> windows (
>> >> >> >> >> >> the
>> >> >> >> >> >> same
>> >> >> >> >> >> in
>> >> >> >> >> >> Unix decades before windows ) and obviously possible to
>> >> >> >> >> >> stand
>> >> >> >> >> >> that
>> >> >> >> >> >> write
>> >> >> >> >> >> will be translated as read for the device, is it not the
>> >> >> >> >> >> same
>> >> >> >> >> >> as


First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: Win64 , InterlockedCompareExchange128 and early AMDs
Next: Retrieving the filesystem name of each partition not mounted