So sounds like the Dell driver should be added to the @dwizzzleMSFT block list, or does it get a pass because it’s a big hardware vendor? cc @rickmartinez06

@aionescu @dwizzzleMSFT @rickmartinez06 You know I'm with you on this but you know as well that MSFT doesn't consider Admin->Kernel a security boundary; incorrectly in my opinion since signing requirements are already a soft boundary. It's a disaster show since telemetry evasion is moving to the Kernel gradually.

@aionescu @dwizzzleMSFT @rickmartinez06 Yes I mean I understand that part. Personally I think organizations should work towards driver allow listing with Device Guard, which should be one of the more easy policies to implement. I just think it is a mistake not to acknowledge the boundary.

@aionescu @dwizzzleMSFT @rickmartinez06 It is was considered a hard boundary to would dramatically change the incentives for the OS and the vendors where as now that is not that case. People yolo develop their code and then someone get's to report it. How many of these are winio clones 👀

@aionescu @FuzzySec @dwizzzleMSFT @rickmartinez06 The blog post doesn’t mention explicitly if the problem is with drivers exposing IOCTL to any local user or admin user only. Obviously risk is higher when kernel can be compromised by non-admin user. Having said that it doesn’t harm to also eliminate such IOCTL for admin user too

@aionescu @dwizzzleMSFT @rickmartinez06 Isn’t the post saying that it prevents low level users from talking to the driver now? So the risk is that admins can talk to the driver and cause a LSA protect change? Is this a big risk or am I misunderstanding?

@mubix @aionescu @dwizzzleMSFT @rickmartinez06 Does it matter if it's a big risk? The pull request Alex screenshot outlined a specific scenario where an attacker can use the drivers to achieve a task an administrator cannot. Sure, there are many bad drivers. But these are the ones I was playing with (thanks to other's work).

@aionescu @dwizzzleMSFT @rickmartinez06 MS: We care about blocking bad drivers.. unless of course they are also actually used by customers.. or are a from a major vendor.. or are windows core components.. in which case we dont care .. but are sending thoughts and prayers while we consider blocking all the other cruft

@aionescu @dwizzzleMSFT @rickmartinez06 I see- it would be nice if they could stop oems in shipping with winio derivates, that is way more important then a driver end user can choose to install or not..

@jonasLyk @aionescu @dwizzzleMSFT @rickmartinez06 Those winio drivers are great for mapping my cheats tho.. i just unmap phys before AC starts

@aionescu @dwizzzleMSFT @rickmartinez06 Privileged users can write-what-where in the kernel? *shocked pikachu face* Wait until people find out they can execute kernel code! Memes aside, what reason would M$ give Dell for a blacklist? Admin to kernel is not a boundary, and there is no cert req. for this IOCTL behavior.

@aionescu @dwizzzleMSFT Thanks Alex! v2.3 has been submitted for the block list by the team. Will work with them to understand the timeline and clarify v2.5/v2.7 plans in this area. #iwork4dell, of course.

@aionescu @dwizzzleMSFT @rickmartinez06 It should, and in the mean-time people should block it with WDAC

@aionescu @etguenni @dwizzzleMSFT @rickmartinez06 If I were @Microsoft or the cert issuer I would revoke the cert and the OS would/should stop loading it. @Dell working for a Titanium Partner this driver and the deployment of fixes seem to have a extreme low priority at customers using #Dell products affected. Cc @lisaattheedge