Get MAC address
in [Win32 Kernel]
|
Prev: Win64 , InterlockedCompareExchange128 and early AMDs
Next: Retrieving the filesystem name of each partition not mounted
From: Arkady Frenkel on 15 Feb 2007 03:37 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...... >> >> > >> >> Not exactly, hee we talk about specific IOCTL without any connection >> >> to >> >> device at all , OTOH any case DACL of user checked in anycase to >> >> allow/deny >> >> access to device. So there is no problem where to check that. >> >> > >> >> > >> >> > The best thing to do here is just to make NdisMRegisterDevice() >> >> > ignore >> >> > the >> >> > symbolic name string argument - if they do it this way, only >> >> > kernel-mode >> >> > components will be able to send IOCTLs to miniports. However, I am >> >> > not >> >> > sure >> >> > they want to do it either - probably, some MSFT-written stuff >> >> > (netstat, >> >> > Wisock,etc) sends IOCTLs to miniports from the user mode.... >> >> > >> >> >> >> 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. >> >> 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. >> >> >> >> Arkady >> >> >> >> > Anton Bassov >> >> > >> >> > "Arkady Frenkel" wrote: >> >> > >> >> >> Anton! >> >> >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in >> >> >> message >> >> >> news:79D44CFC-A70F-4349-9F8C-F5A916380E39(a)microsoft.com... >> >> >> > Arkady, >> >> >> > >> >> >> >> Obviously that should work even on Vista, but MSFT for years >> >> >> >> warning >> >> >> >> about >> >> >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for >> >> >> >> security >> >> >> >> reasons. >> >> >> > >> >> >> > Well, taking into consideration the fact that it is miniport >> >> >> > driver >> >> >> > and >> >> >> > not >> >> >> > TCPIP.SYS who handles this request (which is optional anyway), as >> >> >> > well >> >> >> > as >> >> >> > the >> >> >> > one that this IOCTL gets submitted to the standalone device that >> >> >> > is >> >> >> > not >> >> >> > on >> >> >> > any stack, there is not that much that they can do about it, >> >> >> > apart >> >> >> > from >> >> >> > removing NdisMRegisterDevice(), i.e. dropping the support for >> >> >> > standalone >> >> >> > devices. I don't think they want to go that far.... >> >> >> > >> >> >> 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 >> >> >> Arkady >> >> >> >> >> >> >> OTOH that give option to check MAC on local host only ( in >> >> >> >> addition >> >> >> >> to >> >> >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what OP >> >> >> >> mean >> >> >> >> if >> >> >> >> I >> >> >> >> understood him correctly. >> >> >> > >> >> >> > The way I understood it, the OP was asking about the local host. >> >> >> > Maybe >> >> >> > I >> >> >> > just got it wrong..... >> >> >> > >> >> >> > Anton Bassov >> >> >> > >> >> >> > >> >> >> > "Arkady Frenkel" wrote: >> >> >> > >> >> >> >> Obviously that should work even on Vista, but MSFT for years >> >> >> >> warning >> >> >> >> about >> >> >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for >> >> >> >> security >> >> >> >> reasons. >> >> >> >> OTOH that give option to check MAC on local host only ( in >> >> >> >> addition >> >> >> >> to >> >> >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what OP >> >> >> >> mean >> >> >> >> if >> >> >> >> I >> >> >> >> understood him correctly. >> >> >> >> In that case in addition to Netbios ( may not work if it >> >> >> >> disabled ) >> >> >> >> and >> >> >> >> SendARP() possible to use WMI's MACAddress property of >> >> >> >> Win32_NetworkAdapter >> >> >> >> interface . >> >> >> >> >> >> >> >> Arkady >> >> >> >> >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in >> >> >> >> message >> >> >> >> news:634A9F45-589A-410B-A3B2-A0651F90A19E(a)microsoft.com... >> >> >> >> >I would rather open a handle to the target adapter with >> >> >> >> >CreateFile(), >> >> >> >> >and >> >> >> >> >then >> >> >> >> > send OID_XXX_PERMANENT_ADDRESS request to it with >> >> >> >> > IOCTL_NDIS_QUERY_GLOBAL_STATS ..... >> >> >> >> > >> >> >> >> > Names of all adapters TCPIP is bound to (i.e. the ones that >> >> >> >> > can >> >> >> >> > be >> >> >> >> > passed >> >> >> >> > to >> >> >> >> > CreateFile() call) can be found under >> >> >> >> > HKLM >> >> >> >> > \\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Adapters >> >> >> >> > key in the registry. First I would send >> >> >> >> > OID_GEN_SUPPORTED_LIST >> >> >> >> > request >> >> >> >> > in >> >> >> >> > order to find all OIDs that adapter supports, and locate >> >> >> >> > OID_XXX_PERMANENT_ADDRESS >> >> >> >> > ( OID!= OID_GEN_SUPPORTED_LIST && OID&0xffffff== >> >> >> >> > OID_GEN_SUPPORTED_LIST). >> >> >> >> > At this point I would be able to send >> >> >> >> > OID_XXX_PERMANENT_ADDRESS, >> >> >> >> > and >> >> >> >> > obtain >> >> >> >> > the sought info.... >> >> >> >> > >> >> >> >> > Anton Bassov >> >> >> >> > >> >> >> >> > "Andrew Chalk" wrote: >> >> >> >> > >> >> >> >> >> Is there a SDK or Platform API call that will return the MAC >> >> >> >> >> address(es) >> >> >> >> >> in >> >> >> >> >> a host? >> >> >> >> >> >> >> >> >> >> Many thanks. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
From: Anton Bassov on 16 Feb 2007 21:51 Arkady, > What do you mean "FunctionCode don't get checked indirectly"? Write a driver that responds to IOCTL of say, 1000(dec) by reading from and writing to the system buffer, and send this IOCTL from your test application..... This code in itself is invalid. Its 'DeviceType' field is 0, which is not on the list of MSFT-defined device types (check ntddk.h declarations), and vendor-defined type has to be >= 0x8000. Its 'FunctionCode' field is 0xFA, i.e., again, some MSFT-reserved code, because vendor-defined codes have to be >=0x800. However, once ' TransferType' and 'RequiredAccess' fields are both 0 ( i.e. respectively METHOD_BUFFERED and FILE_ANY_ACCESS), the whole thing works just fine everywhere, including Vista > When > read/write request send to object ( device/regkey/... )without read/write > permissions OS do check FunctionCode and return error. 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, but if it gets blocked by the system, it happens not because of 'FunctionCode' field but because of 'RequiredAccess' one...... Anton Bassov "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...... > >> >> > > >> >> Not exactly, hee we talk about specific IOCTL without any connection > >> >> to > >> >> device at all , OTOH any case DACL of user checked in anycase to > >> >> allow/deny > >> >> access to device. So there is no problem where to check that. > >> >> > > >> >> > > >> >> > The best thing to do here is just to make NdisMRegisterDevice() > >> >> > ignore > >> >> > the > >> >> > symbolic name string argument - if they do it this way, only > >> >> > kernel-mode > >> >> > components will be able to send IOCTLs to miniports. However, I am > >> >> > not > >> >> > sure > >> >> > they want to do it either - probably, some MSFT-written stuff > >> >> > (netstat, > >> >> > Wisock,etc) sends IOCTLs to miniports from the user mode.... > >> >> > > >> >> > >> >> 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. > >> >> 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. > >> >> > >> >> Arkady > >> >> > >> >> > Anton Bassov > >> >> > > >> >> > "Arkady Frenkel" wrote: > >> >> > > >> >> >> Anton! > >> >> >> > >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in > >> >> >> message > >> >> >> news:79D44CFC-A70F-4349-9F8C-F5A916380E39(a)microsoft.com... > >> >> >> > Arkady, > >> >> >> > > >> >> >> >> Obviously that should work even on Vista, but MSFT for years > >> >> >> >> warning > >> >> >> >> about > >> >> >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for > >> >> >> >> security > >> >> >> >> reasons. > >> >> >> > > >> >> >> > Well, taking into consideration the fact that it is miniport > >> >> >> > driver > >> >> >> > and > >> >> >> > not > >> >> >> > TCPIP.SYS who handles this request (which is optional anyway), as > >> >> >> > well > >> >> >> > as > >> >> >> > the > >> >> >> > one that this IOCTL gets submitted to the standalone device that > >> >> >> > is > >> >> >> > not > >> >> >> > on > >> >> >> > any stack, there is not that much that they can do about it, > >> >> >> > apart > >> >> >> > from > >> >> >> > removing NdisMRegisterDevice(), i.e. dropping the support for > >> >> >> > standalone > >> >> >> > devices. I don't think they want to go that far.... > >> >> >> > > >> >> >> 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 > >> >> >> Arkady > >> >> >> > >> >> >> >> OTOH that give option to check MAC on local host only ( in > >> >> >> >> addition > >> >> >> >> to > >> >> >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what OP > >> >> >> >> mean > >> >> >> >> if > >> >> >> >> I > >> >> >> >> understood him correctly. > >> >> >> > > >> >> >> > The way I understood it, the OP was asking about the local host. > >> >> >> > Maybe > >> >> >> > I > >> >> >> > just got it wrong..... > >> >> >> > > >> >> >> > Anton Bassov > >> >> >> > > >> >> >> > > >> >> >> > "Arkady Frenkel" wrote: > >> >> >> > > >> >> >> >> Obviously that should work even on Vista, but MSFT for years > >> >> >> >> warning > >> >> >> >> about > >> >> >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for > >> >> >> >> security > >> >> >> >> reasons. > >> >> >> >> OTOH that give option to check MAC on local host only ( in > >> >> >> >> addition > >> >> >> >> to > >> >> >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what OP > >> >> >> >> mean > >> >> >> >> if > >> >> >> >> I > >> >> >> >> understood him correctly. > >> >> >> >> In that case in addition to Netbios ( may not work if it > >> >> >> >> disabled ) > >> >> >> >> and > >> >> >> >> SendARP() possible to use WMI's MACAddress property of > >> >> >> >> Win32_NetworkAdapter > >> >> >> >> interface . > >> >> >> >> > >> >> >> >> Arkady > >> >> >> >> > >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in > >> >> >> >> message > >> >> >> >> news:634A9F45-589A-410B-A3B2-A0651F90A19E(a)microsoft.com... > >> >> >> >> >I would rather open a handle to the target adapter with > >> >> >> >> >CreateFile(), > >> >> >> >> >and > >> >> >> >> >then > >> >> >> >> > send OID_XXX_PERMANENT_ADDRESS request to it with > >> >> >> >> > IOCTL_NDIS_QUERY_GLOBAL_STATS ..... > >> >> >> >> > > >> >> >> >> > Names of all adapters TCPIP is bound to (i.e. the ones that > >> >> >> >> > can > >> >> >> >> > be > >> >> >> >> > passed > >> >> >> >> > to > >> >> >> >> > CreateFile() call) can be found under > >> >> >> >> > HKLM > >> >> >> >> > \\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Adapters > >> >> >> >> > key in the registry. First I would send > >> >> >> >> > OID_GEN_SUPPORTED_LIST > >> >> >> >> > request > >> >> >> >> > in > >> >> >> >> > order to find all OIDs that adapter supports, and locate > >> >> >> >> > OID_XXX_PERMANENT_ADDRESS > >> >> >> >> > ( OID!= OID_GEN_SUPPORTED_LIST && OID&0xffffff== > >> >> >> >> > OID_GEN_SUPPORTED_LIST). > >> >> >> >> > At this point I would be able to send > >> >> >> >> > OID_XXX_PERMANENT_ADDRESS, > >> >> >> >> > and > >> >> >> >> > obtain > >> >> >> >> > the sought info....
From: Arkady Frenkel on 17 Feb 2007 16:15 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...... >> >> >> > >> >> >> Not exactly, hee we talk about specific IOCTL without any >> >> >> connection >> >> >> to >> >> >> device at all , OTOH any case DACL of user checked in anycase to >> >> >> allow/deny >> >> >> access to device. So there is no problem where to check that. >> >> >> > >> >> >> > >> >> >> > The best thing to do here is just to make NdisMRegisterDevice() >> >> >> > ignore >> >> >> > the >> >> >> > symbolic name string argument - if they do it this way, only >> >> >> > kernel-mode >> >> >> > components will be able to send IOCTLs to miniports. However, I >> >> >> > am >> >> >> > not >> >> >> > sure >> >> >> > they want to do it either - probably, some MSFT-written stuff >> >> >> > (netstat, >> >> >> > Wisock,etc) sends IOCTLs to miniports from the user mode.... >> >> >> > >> >> >> >> >> >> 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. >> >> >> 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. >> >> >> >> >> >> Arkady >> >> >> >> >> >> > Anton Bassov >> >> >> > >> >> >> > "Arkady Frenkel" wrote: >> >> >> > >> >> >> >> Anton! >> >> >> >> >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in >> >> >> >> message >> >> >> >> news:79D44CFC-A70F-4349-9F8C-F5A916380E39(a)microsoft.com... >> >> >> >> > Arkady, >> >> >> >> > >> >> >> >> >> Obviously that should work even on Vista, but MSFT for years >> >> >> >> >> warning >> >> >> >> >> about >> >> >> >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for >> >> >> >> >> security >> >> >> >> >> reasons. >> >> >> >> > >> >> >> >> > Well, taking into consideration the fact that it is miniport >> >> >> >> > driver >> >> >> >> > and >> >> >> >> > not >> >> >> >> > TCPIP.SYS who handles this request (which is optional anyway), >> >> >> >> > as >> >> >> >> > well >> >> >> >> > as >> >> >> >> > the >> >> >> >> > one that this IOCTL gets submitted to the standalone device >> >> >> >> > that >> >> >> >> > is >> >> >> >> > not >> >> >> >> > on >> >> >> >> > any stack, there is not that much that they can do about it, >> >> >> >> > apart >> >> >> >> > from >> >> >> >> > removing NdisMRegisterDevice(), i.e. dropping the support for >> >> >> >> > standalone >> >> >> >> > devices. I don't think they want to go that far.... >> >> >> >> > >> >> >> >> 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 >> >> >> >> Arkady >> >> >> >> >> >> >> >> >> OTOH that give option to check MAC on local host only ( in >> >> >> >> >> addition >> >> >> >> >> to >> >> >> >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what >> >> >> >> >> OP >> >> >> >> >> mean >> >> >> >> >> if >> >> >> >> >> I >> >> >> >> >> understood him correctly. >> >> >> >> > >> >> >> >> > The way I understood it, the OP was asking about the local >> >> >> >> > host. >> >> >> >> > Maybe >> >> >> >> > I >> >> >> >> > just got it wrong..... >> >> >> >> > >> >> >> >> > Anton Bassov >> >> >> >> > >> >> >> >> > >> >> >> >> > "Arkady Frenkel" wrote: >> >> >> >> > >> >> >> >> >> Obviously that should work even on Vista, but MSFT for years >> >> >> >> >> warning >> >> >> >> >> about >> >> >> >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for >> >> >> >> >> security >> >> >> >> >> reasons. >> >> >> >> >> OTOH that give option to check MAC on local host only ( in >> >> >> >> >> addition >> >> >> >> >> to >> >> >> >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what >> >> >> >> >> OP >> >> >> >> >> mean >> >> >> >> >> if >> >> >> >> >> I >> >> >> >> >> understood him correctly. >> >> >> >> >> In that case in addition to Netbios ( may not work if it >> >> >> >> >> disabled ) >> >> >> >> >> and >> >> >> >> >> SendARP() possible to use WMI's MACAddress property of >> >> >> >> >> Win32_NetworkAdapter >> >> >> >> >> interface . >> >> >> >> >> >> >> >> >> >> Arkady >> >> >> >> >> >> >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote >> >> >> >> >> in >> >> >> >> >> message >> >> >> >> >> news:634A9F45-589A-410B-A3B2-A0651F90A19E(a)microsoft.com... >> >> >> >> >> >I would rather open a handle to the target adapter with >> >> >> >> >> >CreateFile(), >> >> >> >> >> >and >> >> >> >> >> >then >> >> >> >> >> > send OID_XXX_PERMANENT_ADDRESS request to it with >> >> >> >> >> > IOCTL_NDIS_QUERY_GLOBAL_STATS ..... >> >> >> >> >> > >> >> >> >> >> > Names of all adapters TCPIP is bound to (i.e. the ones that >> >> >> >> >> > can >> >> >> >> >> > be >> >> >> >> >> > passed >> >> >> >> >> > to >> >> >> >> >> > CreateFile() call) can be found under >> >> >> >> >> > HKLM >> >> >> >> >> > \\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Adapters >> >> >> >> >> > key in the registry. First I would send >> >> >> >> >> > OID_GEN_SUPPORTED_LIST >> >> >> >> >> > request >> >> >> >> >> > in >> >> >> >> >> > order to find all OIDs that adapter supports, and locate >> >> >> >> >> > OID_XXX_PERMANENT_ADDRESS >> >> >> >> >> > ( OID!= OID_GEN_SUPPORTED_LIST && OID&0xffffff== >> >> >> >> >> > OID_GEN_SUPPORTED_LIST). >> >> >> >> >> > At this point I would be able to send >> >> >> >> >> > OID_XXX_PERMANENT_ADDRESS, >> >> >> >> >> > and >> >> >> >> >> > obtain >> >> >> >> >> > the sought info....
From: Anton Bassov on 18 Feb 2007 01:39 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...... > >> >> >> > > >> >> >> Not exactly, hee we talk about specific IOCTL without any > >> >> >> connection > >> >> >> to > >> >> >> device at all , OTOH any case DACL of user checked in anycase to > >> >> >> allow/deny > >> >> >> access to device. So there is no problem where to check that. > >> >> >> > > >> >> >> > > >> >> >> > The best thing to do here is just to make NdisMRegisterDevice() > >> >> >> > ignore > >> >> >> > the > >> >> >> > symbolic name string argument - if they do it this way, only > >> >> >> > kernel-mode > >> >> >> > components will be able to send IOCTLs to miniports. However, I > >> >> >> > am > >> >> >> > not > >> >> >> > sure > >> >> >> > they want to do it either - probably, some MSFT-written stuff > >> >> >> > (netstat, > >> >> >> > Wisock,etc) sends IOCTLs to miniports from the user mode.... > >> >> >> > > >> >> >> > >> >> >> 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. > >> >> >> 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. > >> >> >> > >> >> >> Arkady > >> >> >> > >> >> >> > Anton Bassov > >> >> >> > > >> >> >> > "Arkady Frenkel" wrote: > >> >> >> > > >> >> >> >> Anton! > >> >> >> >> > >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in > >> >> >> >> message > >> >> >> >> news:79D44CFC-A70F-4349-9F8C-F5A916380E39(a)microsoft.com... > >> >> >> >> > Arkady, > >> >> >> >> > > >> >> >> >> >> Obviously that should work even on Vista, but MSFT for years > >> >> >> >> >> warning > >> >> >> >> >> about > >> >> >> >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for > >> >> >> >> >> security > >> >> >> >> >> reasons. > >> >> >> >> > > >> >> >> >> > Well, taking into consideration the fact that it is miniport > >> >> >> >> > driver > >> >> >> >> > and > >> >> >> >> > not > >> >> >> >> > TCPIP.SYS who handles this request (which is optional anyway), > >> >> >> >> > as > >> >> >> >> > well > >> >> >> >> > as > >> >> >> >> > the > >> >> >> >> > one that this IOCTL gets submitted to the standalone device > >> >> >> >> > that > >> >> >> >> > is > >> >> >> >> > not > >> >> >> >> > on > >> >> >> >> > any stack, there is not that much that they can do about it, > >> >> >> >> > apart > >> >> >> >> > from > >> >> >> >> > removing NdisMRegisterDevice(), i.e. dropping the support for > >> >> >> >> > standalone > >> >> >> >> > devices. I don't think they want to go that far.... > >> >> >> >> > > >> >> >> >> 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 > >> >> >> >> Arkady > >> >> >> >> > >> >> >> >> >> OTOH that give option to check MAC on local host only ( in > >> >> >> >> >> addition > >> >> >> >> >> to > >> >> >> >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what > >> >> >> >> >> OP > >> >> >> >> >> mean > >> >> >> >> >> if > >> >> >> >> >> I > >> >> >> >> >> understood him correctly. > >> >> >> >> > > >> >> >> >> > The way I understood it, the OP was asking about the local > >> >> >> >> > host. > >> >> >> >> > Maybe > >> >> >> >> > I > >> >> >> >> > just got it wrong..... > >> >> >> >> > > >> >> >> >> > Anton Bassov > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > "Arkady Frenkel" wrote: > >> >> >> >> > > >> >> >> >> >> Obviously that should work even on Vista, but MSFT for years > >> >> >> >> >> warning > >> >> >> >> >> about > >> >> >> >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for > >> >> >> >> >> security > >> >> >> >> >> reasons. > >> >> >> >> >> OTOH that give option to check MAC on local host only ( in
From: Arkady Frenkel on 18 Feb 2007 02:10
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...... >> >> >> >> > >> >> >> >> Not exactly, hee we talk about specific IOCTL without any >> >> >> >> connection >> >> >> >> to >> >> >> >> device at all , OTOH any case DACL of user checked in anycase to >> >> >> >> allow/deny >> >> >> >> access to device. So there is no problem where to check that. >> >> >> >> > >> >> >> >> > >> >> >> >> > The best thing to do here is just to make >> >> >> >> > NdisMRegisterDevice() >> >> >> >> > ignore >> >> >> >> > the >> >> >> >> > symbolic name string argument - if they do it this way, only >> >> >> >> > kernel-mode >> >> >> >> > components will be able to send IOCTLs to miniports. However, >> >> >> >> > I >> >> >> >> > am >> >> >> >> > not >> >> >> >> > sure >> >> >> >> > they want to do it either - probably, some MSFT-written stuff >> >> >> >> > (netstat, >> >> >> >> > Wisock,etc) sends IOCTLs to miniports from the user mode.... >> >> >> >> > >> >> >> >> >> >> >> >> 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. >> >> >> >> 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. >> >> >> >> >> >> >> >> Arkady >> >> >> >> >> >> >> >> > Anton Bassov >> >> >> >> > >> >> >> >> > "Arkady Frenkel" wrote: >> >> >> >> > >> >> >> >> >> Anton! >> >> >> >> >> >> >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote >> >> >> >> >> in >> >> >> >> >> message >> >> >> >> >> news:79D44CFC-A70F-4349-9F8C-F5A916380E39(a)microsoft.com... >> >> >> >> >> > Arkady, >> >> >> >> >> > >> >> >> >> >> >> Obviously that should work even on Vista, but MSFT for >> >> >> >> >> >> years >> >> >> >> >> >> warning >> >> >> >> >> >> about >> >> >> >> >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for >> >> >> >> >> >> security >> >> >> >> >> >> reasons. >> >> >> >> >> > >> >> >> >> >> > Well, taking into consideration the fact that it is >> >> >> >> >> > miniport >> >> >> >> >> > driver >> >> >> >> >> > and >> >> >> >> >> > not >> >> >> >> >> > TCPIP.SYS who handles this request (which is optional >> >> >> >> >> > anyway), >> >> >> >> >> > as >> >> >> >> >> > well >> >> >> >> >> > as >> >> >> >> >> > the >> >> >> >> >> > one that this IOCTL gets submitted to the standalone device >> >> >> >> >> > that >> >> >> >> >> > is >> >> >> >> >> > not >> >> >> >> >> > on >> >> >> >> >> > any stack, there is not that much that they can do about >> >> >> >> >> > it, >> >> >> >> >> > apart >> >> >> >> >> > from >> >> >> >> >> > removing NdisMRegisterDevice(), i.e. dropping the support >> >> >> >> >> > for >> >> >> >> >> > standalone >> >> >> >> >> > devices. I don't think they want to go that far.... >> >> >> >> >> > >> >> >> >> >> 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 >> >> >> >> >> Arkady >> >> >> >> >> >> >> >> >> >> >> OTOH that give option to check MAC on local host only ( in >> >> >> >> >> >> addition >> >> >> >> >> >> to >> >> >> >> >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no >> >> >> >> >> >> what >> >> >> >> >> >> OP >> >> >> >> >> >> mean >> >> >> >> >> >> if >> >> >> >> >> >> I >> >> >> >> >> >> understood him correctly. >> >> >> >> >> > >> >> >> >> >> > The way I understood it, the OP was asking about the local >> >> >> >> >> > host. >> >> >> >> >> > Maybe >> >> >> >> >> > I >> >> >> >> >> > just got it wrong..... >> >> >> >> >> > >> >> >> >> >> > Anton Bassov >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > "Arkady Frenkel" wrote: >> >> >> >> >> > >> >> >> >> >> >> Obviously that should work even on Vista, but MSFT for >> >> >> >> >> >> years >> >> >> >> >> >> warning >> >> >> >> >> >> about >> >> >> >> >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for >> >> >> >> >> >> security >> >> >> >> >> >> reasons. >> >> >> >> >> >> OTOH that give option to check MAC on local host only ( in |