Form a security standpoint I don't understand why Microsoft would even 'launch' any app (that's not necessary for login) while lock screen is on. The lock screen should be completely decoupled. It would be like trying to enter a URL in a browser while the browser app is closed which is basically impossible (I'm not talking about adding it as a cmd param).

Accessibility tools are necessary for login.

Then they should be part of the login application.

That would be even worse than the current state of things.

Accessibility services are necessarily kernel services, since they tie deeply into considerations of what the OS should/shouldn’t allow the user to do at any point.

Giving the login application its own copy of those services, would mean giving the login application (⇒ applications in general) the ability to tie as deeply into the OS as the accessibility services themselves do. Avoiding that is the whole reason accessibility was made an OS-level feature in the first place!

> Giving the login application its own copy of these services...

It’s much easier to have a lock/login screen that ties closely with the rest if the OS, but that’s not an actual requirement. As an extreme example Windows could split things so you have the login screen and the rest of windows as effectively two completely different VM’s that get swapped between.

I am not saying that’s a good idea, but Microsoft is building the OS from the ground up they have a lot of options.

The idea is that the screen lock should directly call the kernel accessibility API, and not start other processes at all.

IIRC, in this case it's the kernel accessibility API that's spawning these client processes from kernel-space, due to events the kernel is observing directly, rather than events being reported to the kernel from a userspace process — which is precisely how these accessibility helper UX processes get to be privileged in a way that regular userland processes aren't.

What about third-party accessibility tools, input methods, logon methods, etc?

Unfortunately, for people who need to type on letter at a time, or type with a mouthstick, there's a need to run accessibility helper programs.

Backdoor for law enforcement?

What’s funny is we used to replace each other’s sticky keys program if we left our computer unlocked. Hours of entertainment while they try to figure out how you keep getting back in. Lock your machine. And if it’s windows, apparently, don’t have USB ports. It’s been a known “problem” forever (When you remake the sticky keys program you can unlock the machine by pressing SHIFT 5 times :)

>It’s been a known “problem” forever

It's a known problem forever because there's literally no solution. You can very well patch lsass.exe to add a backdoor, for instance.

Yeah, if the attacker has the right to replace arbitrary system executables, we're not really talking about privilege escalation any more. The solution is not to give people root access to your machine.

Not sure what the "don't have USB ports" aside was about: plugging in arbitrary USB peripherals shouldn't give you that kind of access, though they certainly are an attack vector.

USB has been a classic attack vector for local attacks forever. I have used them on red team social engineering engagements for a long time. An few innocuous auto run usb thrown into a few machines will be all you would need to compromise an internal network easily. The pint is you can harden physical security and a big part of that is disabling usb (physically if possible)

>An few innocuous auto run usb

autoruns have been disabled for USBs since windows xp SP3

True. We tend to use things like inline keystroke loggers on keyboards these days for socials engineering gigs. You can also just convince people to run your stuff by giving it intriguing names (e.g. Q4 layoffs). Excel sheet, exe... etc :)

My favourite has always been to steal the password hash of the user from the lockscreen using a bash bunny, im still amazed that it actually works.

They didn’t fix the insecure directory creation when media is mounted?

Yes, that seems to be the much more concerning aspect of this vulnerability.

Without that, this vulnerability seems to only let you create local unprivileged user accounts which isn't such a big deal.

It's not as big a deal, but not without impact. You only need a local privilege escalation to go from a user with no rights to a fully open system. And systems are much harder to secure against code running on them with access to all those juicy kernel facing unprivileged APIs...

Windows has special protocol schemes specifically for opening various settings pages. I feel like an accessibility feature will probably make it possible to launch such a URL. Maybe the camera app's QR code integration (if any) can launch URLs if accessible via the lockscreen.