|
|
Subscribe / Log in / New account

Check Point's "QuadRooter" vulnerabilities

Check Point's "QuadRooter" vulnerabilities

Posted Aug 12, 2016 0:29 UTC (Fri) by Fowl (subscriber, #65667)
In reply to: Check Point's "QuadRooter" vulnerabilities by Jonno
Parent article: Check Point's "QuadRooter" vulnerabilities

OEMs do actually have the option to publish drivers and driver updates to Windows Updates. Since often "drivers" can be completely userspace components I'm not sure where MS draws the line as to what would be rejected.


to post comments

Check Point's "QuadRooter" vulnerabilities

Posted Aug 12, 2016 1:40 UTC (Fri) by Jonno (subscriber, #49613) [Link]

> OEMs do actually have the option to publish drivers and driver updates to Windows Updates.
Yes, though the limits are quite restrictive (for example a Windows Update supplied driver are no allowed to include any feature not included in the driver boxed with the hardware as sold), and if there is a security vulnerability in the driver the OEM is screwed, as updated versions of drivers are only allowed under even more restrictive conditions (and a security vulnerability is not one of them [1]):

> 2.3.1.1. The driver is among the top 20 Online Crash Analysis (OCA) driver issues report for an OEM’s systems over the last 90 days; or
> 2.3.1.2. The previous version of the code causes 10% or 10,000 (whichever is lower) of an OEM's systems to stop unexpectedly during driver installation over a two-week period or lose basic device or system functionality. Examples of this include: sound cards no longer emit sounds; a mouse cannot move the cursor; a storage unit cannot be accessed; or
> 2.3.1.3. At the sole discretion of Microsoft, the existing code results in excessive product support calls by OEMs, IHVs, or Microsoft.

[1]: http://download.microsoft.com/download/9/c/5/9c5b2167-801...


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds