Get MAC address
in [Win32 Kernel]
|
Prev: Win64 , InterlockedCompareExchange128 and early AMDs
Next: Retrieving the filesystem name of each partition not mounted
From: Anton Bassov on 18 Feb 2007 04:05 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 > >> >> >> absence > >> >> >> of > >> >> >> traffic rules on the road :) ? > >> >> >> BTW Windows 9x/Me do not support IOCTL_NDIS_QUERY_GLOBAL_STATS at > >> >> >> all > >> >> >> from > >> >> >> the beginning and nothing terrible happen > >> >> >> > >> >> >> Arkady > >> >> >> > >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in > >> >> >> message > >> >> >> news:E881CAE5-8CAD-421D-8B48-15BC959FF97A(a)microsoft.com... > >> >> >> > Arkady, > >> >> >> > > >> >> >> >> Not exactly, hee we talk about specific IOCTL without any > >> >> >> >> connection > >> >> >> >> to > >> >> >> >> device at all.... > >> >> >> > > >> >> >> > IOCTL in itself is nothing more than just a DWORD value. What if > >> >> >> > some > >> >> >> > totally unrelated driver,particularly third-party one, accepts > >> >> >> > IOCTL > >> >> >> > that > >> >> >> > is > >> >> >> > numerically equal to IOCTL_NDIS_QUERY_GLOBAL_STATS??? Are we > >> >> >> > going > >> >> >> > to > >> >> >> > block > >> >> >> > it as well??? > >> >> >> > Therefore, no matter how you look at it, you have to relate > >> >> >> > IOCTLs > >> >> >> > to > >> >> >> > their > >> >> >> > target devices > >> >> >> > > >> >> >> >> OTOH any case DACL of user checked in anycase to allow/deny > >> >> >> >> access to device. So there is no problem where to check that. > >> >> >> > > >> >> >> > Well, DACL check is done when you open a handle - once you have > >> >> >> > it, > >> >> >> > no > >> >> >> > more > >> >> >> > access checks are made. In any case, as far as admin accounts are > >> >> >> > concerned, > >> >> >> > DACL check is not a solution - after all, they can easily adjust > >> >> >> > it. > >> >> >> > > >> >> >> >> No, the idea that user have to use WMI which have it's own > >> >> >> >> kernel > >> >> >> >> driver > >> >> >> >> to > >> >> >> >> send OIDs to NDIS when it receive IOCTLs from > >> >> >> >> user part of WMI. > >> >> >> > > >> >> >> > This is already a bit different story - this thing can be done > >> >> >> > pretty > >> >> >> > easily. However, as long as the possibility of sending IOCTLs to > >> >> >> > standalone > >> >> >> > devices exists, this is not a solution. The only thing they can > >> >> >> > do > >> >> >> > is > >> >> >> > to > >> >> >> > disable IOCTL_NDIS_QUERY_GLOBAL_STATS for user-mode WMI clients > >> >> >> > plus > >> >> >> > make > >> >> >> > NdisMRegisterDevice() ignore the symbolic link. If they do it > >> >> >> > this > >> >> >> > way, > >> >> >> > the > >> >> >> > whole thing will work. > >> >> >> > > >> >> >> >> AFAIK nor netstat ( due to Russinoch's netstatp already > >> >> >> >> disappeared > >> >> >> >> when > >> >> >> >> site moved to Msft :( ), not winsock send IOCTLs directly to > >> >> >> >> miniport, > >> >> >> >> but > >> >> >> >> winsock talk ( with IOCTL ) through LSP, WSH to tcpip.sys for > >> >> >> >> info, > >> >> >> >> not > >> >> >> >> for > >> >> >> >> data interchange , that use msafd.dll/afd.sys/tdi.sys path > >> >> >> >> before > >> >> >> >> tcpip.sys. > >> >> >> > > >> >> >> > If it works this way and they are sure that their user-mode > >> >> >> > components > >> >> >> > will > >> >> >> > never ever need to talk directly to miniports, probably, they can > >> >> >> > disable > >> >> >> > user-mode access to devices, created by NdisMRegisterDevice(). > >> >> >> > After > >> >> >> > all, > >> >> >> > their components can submit private IOCTLs to afd.sys, and, at > >> >> >> > this > >> >> >> > point, > >> >> >> > afd.sys has two ways to reach miniport drivers (i.e. directly via > >> >> >> > standalone > >> >> >> > device or via TCPIP.SYS that does everything via NdisRequest()) > >> >> >> > > >> >> >> > > >> >> >> > Anton Bassov > >> >> >> > > >> >> >> > > >> >> >> > "Arkady Frenkel" wrote: > >> >> >> > > >> >> >> >> Anton! > >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in > >> >> >> >> message > >> >> >> >> news:11D2755D-6CB3-4FE3-9D41-993CB084CBBF(a)microsoft.com... > >> >> >> >> > Arkady, > >> >> >> >> > > >> >> >> >> >> I don't think that it's a problem for MSFT to decline that > >> >> >> >> >> already > >> >> >> >> >> in > >> >> >> >> >> DeviceIoControl() in user mode or > >> >> >> >> >> before extract/send OID in kernel mode > >> >> >> >> > > >> >> >> >> > *THEORETICALLY* doing things this way is feasible. However, > >> >> >> >> > look > >> >> >> >> > at > >> >> >> >> > the > >> >> >> >> > whole thing in practical terms. Both user-mode > >> >> >> >> > DeviceIoControl() > >> >> >> >> > and > >> >> >> >> > actual > >> >> >> >> > kernel-mode implementation of ZwDeviceIoControlFile() are > >> >> >> >> > meant > >> >> >> >> > to > >> >> >> >> > be > >> >> >> >> > used > >> >> >> >> > for sending*ANY* IOCTL to *ANY* device that registers a > >> >> >> >> > symbolic > >> >> >> >> > link. > >> >> >> >> > I > >> >> >> >> > hope > >> >> >> >> > you can imagine what it is like to watch and block some > >> >> >> >> > certain > >> >> >> >> > IOCTLs > >> >> >> >> > that > >> >> >> >> > get sent to some certain > >> >> >> >> > (unknown at compile-time) devices that get sent by callers > >> >> >> >> > that > >> >> >> >> > don't > >> >> >> >> > meet > >> >> >> >> > some certain criteria......
From: Arkady Frenkel on 18 Feb 2007 04:34 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 >> >> >> >> absence >> >> >> >> of >> >> >> >> traffic rules on the road :) ? >> >> >> >> BTW Windows 9x/Me do not support IOCTL_NDIS_QUERY_GLOBAL_STATS >> >> >> >> at >> >> >> >> all >> >> >> >> from >> >> >> >> the beginning and nothing terrible happen >> >> >> >> >> >> >> >> Arkady >> >> >> >> >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in >> >> >> >> message >> >> >> >> news:E881CAE5-8CAD-421D-8B48-15BC959FF97A(a)microsoft.com... >> >> >> >> > Arkady, >> >> >> >> > >> >> >> >> >> Not exactly, hee we talk about specific IOCTL without any >> >> >> >> >> connection >> >> >> >> >> to >> >> >> >> >> device at all.... >> >> >> >> > >> >> >> >> > IOCTL in itself is nothing more than just a DWORD value. What >> >> >> >> > if >> >> >> >> > some >> >> >> >> > totally unrelated driver,particularly third-party one, accepts >> >> >> >> > IOCTL >> >> >> >> > that >> >> >> >> > is >> >> >> >> > numerically equal to IOCTL_NDIS_QUERY_GLOBAL_STATS??? Are we >> >> >> >> > going >> >> >> >> > to >> >> >> >> > block >> >> >> >> > it as well??? >> >> >> >> > Therefore, no matter how you look at it, you have to relate >> >> >> >> > IOCTLs >> >> >> >> > to >> >> >> >> > their >> >> >> >> > target devices >> >> >> >> > >> >> >> >> >> OTOH any case DACL of user checked in anycase to allow/deny >> >> >> >> >> access to device. So there is no problem where to check that. >> >> >> >> > >> >> >> >> > Well, DACL check is done when you open a handle - once you >> >> >> >> > have >> >> >> >> > it, >> >> >> >> > no >> >> >> >> > more >> >> >> >> > access checks are made. In any case, as far as admin accounts >> >> >> >> > are >> >> >> >> > concerned, >> >> >> >> > DACL check is not a solution - after all, they can easily >> >> >> >> > adjust >> >> >> >> > it. >> >> >> >> > >> >> >> >> >> No, the idea that user have to use WMI which have it's own >> >> >> >> >> kernel >> >> >> >> >> driver >> >> >> >> >> to >> >> >> >> >> send OIDs to NDIS when it receive IOCTLs from >> >> >> >> >> user part of WMI. >> >> >> >> > >> >> >> >> > This is already a bit different story - this thing can be done >> >> >> >> > pretty >> >> >> >> > easily. However, as long as the possibility of sending IOCTLs >> >> >> >> > to >> >> >> >> > standalone >> >> >> >> > devices exists, this is not a solution. The only thing they >> >> >> >> > can >> >> >> >> > do >> >> >> >> > is >> >> >> >> > to >> >> >> >> > disable IOCTL_NDIS_QUERY_GLOBAL_STATS for user-mode WMI >> >> >> >> > clients >> >> >> >> > plus >> >> >> >> > make >> >> >> >> > NdisMRegisterDevice() ignore the symbolic link. If they do it >> >> >> >> > this >> >> >> >> > way, >> >> >> >> > the >> >> >> >> > whole thing will work. >> >> >> >> > >> >> >> >> >> AFAIK nor netstat ( due to Russinoch's netstatp already >> >> >> >> >> disappeared >> >> >> >> >> when >> >> >> >> >> site moved to Msft :( ), not winsock send IOCTLs directly to >> >> >> >> >> miniport, >> >> >> >> >> but >> >> >> >> >> winsock talk ( with IOCTL ) through LSP, WSH to tcpip.sys >> >> >> >> >> for >> >> >> >> >> info, >> >> >> >> >> not >> >> >> >> >> for >> >> >> >> >> data interchange , that use msafd.dll/afd.sys/tdi.sys path >> >> >> >> >> before >> >> >> >> >> tcpip.sys. >> >> >> >> > >> >> >> >> > If it works this way and they are sure that their user-mode >> >> >> >> > components >> >> >> >> > will >> >> >> >> > never ever need to talk directly to miniports, probably, they >> >> >> >> > can >> >> >> >> > disable >> >> >> >> > user-mode access to devices, created by NdisMRegisterDevice(). >> >> >> >> > After >> >> >> >> > all, >> >> >> >> > their components can submit private IOCTLs to afd.sys, and, at >> >> >> >> > this >> >> >> >> > point, >> >> >> >> > afd.sys has two ways to reach miniport drivers (i.e. directly >> >> >> >> > via >> >> >> >> > standalone >> >> >> >> > device or via TCPIP.SYS that does everything via >> >> >> >> > NdisRequest()) >> >> >> >> > >> >> >> >> > >> >> >> >> > Anton Bassov >> >> >> >> > >> >> >> >> > >> >> >> >> > "Arkady Frenkel" wrote: >> >> >> >> > >> >> >> >> >> Anton! >> >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote >> >> >> >> >> in >> >> >> >> >> message >> >> >> >> >> news:11D2755D-6CB3-4FE3-9D41-993CB084CBBF(a)microsoft.com... >> >> >> >> >> > Arkady, >> >> >> >> >> > >> >> >> >> >> >> I don't think that it's a problem for MSFT to decline that >> >> >> >> >> >> already >> >> >> >> >> >> in >> >> >> >> >> >> DeviceIoControl() in user mode or >> >> >> >> >> >> before extract/send OID in kernel mode >> >> >> >> >> > >> >> >> >> >> > *THEORETICALLY* doing things this way is feasible. However, >> >> >> >> >> > look >> >> >> >> >> > at >> >> >> >> >> > the >> >> >> >> >> > whole thing in practical terms. Both user-mode >> >> >> >> >> > DeviceIoControl() >> >> >> >> >> > and >> >> >> >> >> > actual >> >> >> >> >> > kernel-mode implementation of ZwDeviceIoControlFile() are >> >> >> >> >> > meant >> >> >> >> >> > to >> >> >> >> >> > be >> >> >> >> >> > used >> >> >> >> >> > for sending*ANY* IOCTL to *ANY* device that registers a >> >> >> >> >> > symbolic >> >> >> >> >> > link. >> >> >> >> >> > I >> >> >> >> >> > hope >> >> >> >> >> > you can imagine what it is like to watch and block some >> >> >> >> >> > certain >> >> >> >> >> > IOCTLs >> >> >> >> >> > that >> >> >> >> >> > get sent to some certain >> >> >> >> >> > (unknown at compile-time) devices that get sent by callers >> >> >> >> >> > that >> >> >> >> >> > don't >> >> >> >> >> > meet >> >> >> >> >> > some certain criteria......
From: Anton Bassov on 18 Feb 2007 05:33 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 > >> >> >> >> absence > >> >> >> >> of > >> >> >> >> traffic rules on the road :) ? > >> >> >> >> BTW Windows 9x/Me do not support IOCTL_NDIS_QUERY_GLOBAL_STATS > >> >> >> >> at > >> >> >> >> all > >> >> >> >> from > >> >> >> >> the beginning and nothing terrible happen > >> >> >> >> > >> >> >> >> Arkady > >> >> >> >> > >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in > >> >> >> >> message > >> >> >> >> news:E881CAE5-8CAD-421D-8B48-15BC959FF97A(a)microsoft.com... > >> >> >> >> > Arkady, > >> >> >> >> > > >> >> >> >> >> Not exactly, hee we talk about specific IOCTL without any > >> >> >> >> >> connection > >> >> >> >> >> to > >> >> >> >> >> device at all.... > >> >> >> >> > > >> >> >> >> > IOCTL in itself is nothing more than just a DWORD value. What > >> >> >> >> > if > >> >> >> >> > some > >> >> >> >> > totally unrelated driver,particularly third-party one, accepts > >> >> >> >> > IOCTL > >> >> >> >> > that > >> >> >> >> > is > >> >> >> >> > numerically equal to IOCTL_NDIS_QUERY_GLOBAL_STATS??? Are we > >> >> >> >> > going > >> >> >> >> > to > >> >> >> >> > block > >> >> >> >> > it as well??? > >> >> >> >> > Therefore, no matter how you look at it, you have to relate > >> >> >> >> > IOCTLs > >> >> >> >> > to > >> >> >> >> > their > >> >> >> >> > target devices > >> >> >> >> > > >> >> >> >> >> OTOH any case DACL of user checked in anycase to allow/deny > >> >> >> >> >> access to device. So there is no problem where to check that. > >> >> >> >> > > >> >> >> >> > Well, DACL check is done when you open a handle - once you > >> >> >> >> > have > >> >> >> >> > it, > >> >> >> >> > no > >> >> >> >> > more > >> >> >> >> > access checks are made. In any case, as far as admin accounts > >> >> >> >> > are > >> >> >> >> > concerned, > >> >> >> >> > DACL check is not a solution - after all, they can easily > >> >> >> >> > adjust > >> >> >> >> > it. > >> >> >> >> > > >> >> >> >> >> No, the idea that user have to use WMI which have it's own > >> >> >> >> >> kernel > >> >> >> >> >> driver > >> >> >> >> >> to > >> >> >> >> >> send OIDs to NDIS when it receive IOCTLs from > >> >> >> >> >> user part of WMI. > >> >> >> >> > > >> >> >> >> > This is already a bit different story - this thing can be done
From: Arkady Frenkel on 18 Feb 2007 07:40 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 >> >> >> >> >> absence >> >> >> >> >> of >> >> >> >> >> traffic rules on the road :) ? >> >> >> >> >> BTW Windows 9x/Me do not support >> >> >> >> >> IOCTL_NDIS_QUERY_GLOBAL_STATS >> >> >> >> >> at >> >> >> >> >> all >> >> >> >> >> from >> >> >> >> >> the beginning and nothing terrible happen >> >> >> >> >> >> >> >> >> >> Arkady >> >> >> >> >> >> >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote >> >> >> >> >> in >> >> >> >> >> message >> >> >> >> >> news:E881CAE5-8CAD-421D-8B48-15BC959FF97A(a)microsoft.com... >> >> >> >> >> > Arkady, >> >> >> >> >> > >> >> >> >> >> >> Not exactly, hee we talk about specific IOCTL without any >> >> >> >> >> >> connection >> >> >> >> >> >> to >> >> >> >> >> >> device at all.... >> >> >> >> >> > >> >> >> >> >> > IOCTL in itself is nothing more than just a DWORD value. >> >> >> >> >> > What >> >> >> >> >> > if >> >> >> >> >> > some >> >> >> >> >> > totally unrelated driver,particularly third-party one, >> >> >> >> >> > accepts >> >> >> >> >> > IOCTL >> >> >> >> >> > that >> >> >> >> >> > is >> >> >> >> >> > numerically equal to IOCTL_NDIS_QUERY_GLOBAL_STATS??? Are >> >> >> >> >> > we >> >> >> >> >> > going >> >> >> >> >> > to >> >> >> >> >> > block >> >> >> >> >> > it as well??? >> >> >> >> >> > Therefore, no matter how you look at it, you have to relate >> >> >> >> >> > IOCTLs >> >> >> >> >> > to >> >> >> >> >> > their >> >> >> >> >> > target devices >> >> >> >> >> > >> >> >> >> >> >> OTOH any case DACL of user checked in anycase to >> >> >> >> >> >> allow/deny >> >> >> >> >> >> access to device. So there is no problem where to check >> >> >> >> >> >> that. >> >> >> >> >> > >> >> >> >> >> > Well, DACL check is done when you open a handle - once you >> >> >> >> >> > have >> >> >> >> >> > it, >> >> >> >> >> > no >> >> >> >> >> > more >> >> >> >> >> > access checks are made. In any case, as far as admin >> >> >> >> >> > accounts >> >> >> >> >> > are >> >> >> >> >> > concerned, >> >> >> >> >> > DACL check is not a solution - after all, they can easily >> >> >> >> >> > adjust >> >> >> >> >> > it. >> >> >> >> >> > >> >> >> >> >> >> No, the idea that user have to use WMI which have it's own >> >> >> >> >> >> kernel >> >> >> >> >> >> driver >> >> >> >> >> >> to >> >> >> >> >> >> send OIDs to NDIS when it receive IOCTLs from >> >> >> >> >> >> user part of WMI. >> >> >> >> >> > >> >> >> >> >> > This is already a bit different story - this thing can be >> >> >> >> >> > done
From: Anton Bassov on 19 Feb 2007 15:55
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 |