1. 23
  1.  

  2. 10

    The real gem is at the end of the article:

    I reported the issue to MSRC, but they ignored the bug report citing a need of PoC, which I had already provided, they had also expressed disbelief towards the exploitability of this bug.

    Supposedly there’s a whole new Microsoft but some things never change :-D.

    1. 3

      There’s no doubt this is a bad look, but it’s not a BitLocker bypass. The vulnerability has absolutely nothing to do with BitLocker, and will work on systems meeting the constraints the author specifies with or without BitLocker. How the claim there’s any relation is there, let alone in the headline, I have absolutely no idea.

      Addressing the vulnerability itself, it goes to show the perils of running any more code than you absolutely have to in a privileged context, especially in security critical code like the login/lock screen. It’s a shame, but unsurprising, that so much of these issues come from accessibility related functionality. Not because it’s necessarily bad code, but it’s inherently complex (magnifiers, narrators, on-screen keyboards, internationalization, etc …), and complexity tends to be the enemy of security.

      I saw just recently XScreenSaver 6.0 has been released:

      These changes greatly reduce the amount of code running in the “critical” section: the part of the code where a crash would cause the screen to unlock. That critical section is now only around 1,800 lines of code, a reduction of roughly 87%.

      How much code do you think is running in a privileged context on the Windows lockscreen for which bugs could cause a security issue. It’s surely many 10’s of thousands conservatively …

      1. 1

        “via ridiculous” says it all, really.