1. Help Center
  2. Frequently Asked Questions
  3. Post-End-of-Support Security Micropatches for Windows 7, 10 and 11, Windows Servers 2008 R2, 2012 and 2012 R2

Do you provide all security patches that would otherwise be delivered via Microsoft's Extended Security Updates?

mitja.kolsek -

No. Microsoft's Extended Security Updates (ESU) include Critical and Important security patches for Windows Server 2012 and Windows Server 2008 R2 according to their definition in Microsoft's Security Update Severity Rating System.

Our criteria for micropatching a vulnerability are specified here and are not identical to Microsoft's; while we expect ours and Microsoft's criteria to mostly overlap when it comes to high-risk vulnerabilities, it may happen that we decide not to micropatch some vulnerabilities Microsoft includes in ESU, but also that we do micropatch issues on Windows Server 2012 or Windows Server 2008 R2 that aren't included in ESU.

Furthermore, it may happen that for whatever technical or other reason, we are unable to port a security fix to Windows Server 2012 or Windows Server 2008 R2 as a micropatch (e.g., we may not be able to obtain a proof-of-concept for triggering the vulnerability while the vulnerability is already getting exploited in the wild, or the vulnerability may be in code that can't be micropatched). If that happens for a highly critical vulnerability, we'll provide recommendations for users to mitigate such vulnerability on their computers in some other way.

On the other hand, with 0patch you also get our "0day" patches for vulnerabilities that haven't been fixed by Microsoft yet. Some recent cases are Follina, DogWalk and ZippyReads, where our patches were available (and applied on users' computers) weeks before Microsoft has provided their official fixes.

Have more questions? Submit a request

4 Comments

Date Votes
  • 1
    Avatar
    scott.perry

    Based on previous experience, has it ever occurred before that you could not micropatch a Windows vulnerability?  If so, how did that (or those) incidents resolve themselves?  

     

    Thanks,

     

    Scott Perry

  • 1
    Avatar
    mitja.kolsek

    Hi Scott,

    Indeed, 0patch can currently only patch vulnerabilities in native code running in user space (see this article: https://0patch.zendesk.com/hc/en-us/articles/360011047979). For example, we could not patch BlueKeep in the kernel code as Microsoft did, although we then did find another place in user space code that we could use to the same effect instead (see this article: https://0patch.zendesk.com/hc/en-us/articles/360011077939).

    There have also been numerous local privilege escalation vulnerabilities in Windows kernel code that we could not patch; however, our criteria for patching (see https://0patch.zendesk.com/hc/en-us/articles/360018110474) prioritizes remotely exploitable issues as these can directly lead to a compromise in a single-step attack.

  • 1
    Avatar
    scott.perry

    Admittedly, I am just taking a guess here, but this sounds to me like despite the fact that Microsoft no longer officially supports Windows 7, there are still concerns that they may not (or will not) permit folks such as yourselves to alter "OS-space" portions of their code, despite the fact that such alterations might even be helpful (or even essential) to the operation of their own customers machines.

    If Microsoft were to allow you to access their "OS-space" code, do you feel that in some cases you would be able to do as good as, or possibly even better than they are currently doing with their own code in Windows 7?  If so, and it turns out that Microsoft is intentionally causing serious harm to their old customers for their own economic gain, then I would say it's time for Microsoft to let go of their proprietary claims over their "OS-space," whenever they let go of their "official support" for any such system.

    Would you tend to generally agree with this "sentiment?"

  • 0
    Avatar
    mitja.kolsek

    scott.perry, we believe Microsoft, and all their employees, genuinely want their users to be secure. They also want, as everyone else including us wants, to provide a service that will benefit someone and pay their bills. As stated many times before in our blog posts and elsewhere, we believe the original vendor is in the best position to fix their own code, with access to the source code and all the brains that were actively engaged in writing it. Our advantage, on the other hand, is our technology that allows for less risky and quicker patch development, testing, distribution and application/removal - and this allows us to be sometimes better or quicker, but not in general. No doubt it would be ideal if Microsoft and other software vendors combined such technology with their own access to source code and brains.

Please sign in to leave a comment.