OpenSSL vulnerability in icls driver version 1.71.99.0

[MaximvL]

According to Microsoft Defender, the icls driver installed on 80% of our devices uses OpenSSL version 3.0.12. This version has known vulnerabilities.

The driverversion is 1.71.99.0 which is the latest from Windows Update and also the lastest I can find on the Intel-site (https://www.intel.com/content/www/us/en/download/682431/intel-management-engine-drivers-for-windows-10-and-windows-11.html?wapkw=intel%20r%20icss%20client).

Is there  a newer version which I missed? If not, when can we expect an updated driverpackage?

[Bowserker]

It's pretty crazy that Zoom is keeping up with this better than intel is. 

[saulov8]

I recently resolved an issue on my laptop where Microsoft Defender flagged OpenSSL vulnerabilities in the following Intel Client Security (ICLS) driver files:

c:\windows\system32\driverstore\filerepository\iclsclient.inf_amd64_c25dbc60ad3b371a\lib\libcrypto-3-x64.dll (OpenSSL Version: 3.0.14.0)
c:\windows\system32\driverstore\filerepository\iclsclient.inf_amd64_c25dbc60ad3b371a\lib\libssl-3-x64.dll (OpenSSL Version: 3.0.14.0)

Here’s how I fixed it, step by step:

1) Confirmed the Issue:
In Device Manager, under System devices, I located Intel(R) Management Engine Interface. The installed ICLS driver version was 1.74.210.0. Checking the file properties of the flagged DLLs confirmed they were using OpenSSL 3.0.14.0, matching Defender’s alert.

2) Updated the Driver:
I downloaded the latest Intel Management Engine driver package (Intel_R_ME_SW_2507.7.10.0.zip) from Intel’s website. Using the ICLS driver included in this package, I updated the driver via Device Manager. Post-update, the new driver version loaded was 1.75.121.0, and the bundled OpenSSL version upgraded to 3.0.15, which patches the vulnerabilities.

3) Noticed Residual Files:
The update created a new folder in c:\windows\system32\driverstore\filerepository\ with the updated files but left the old folder (iclsclient.inf_amd64_c25dbc60ad3b371a) intact. Defender could still detect the vulnerable 3.0.14.0 files in the old folder.

4) Removed the Old Driver:
I ran pnputil /enum-drivers in an Admin Command Prompt to list all installed driver packages. This showed both the old (1.74.210.0) and new (1.75.121.0) ICLS drivers, each tied to an oemXX.inf file.
I removed the old driver with: pnputil /delete-driver oemXX.inf /uninstall (Replace oemXX.inf with the actual name from your list.)
This deleted the old folder and its vulnerable OpenSSL files. Then I rebooted to verify nothing has been broken.

5) Verified the Fix:
The vulnerable files were no longer flagged on Defender, confirming the issue was resolved.

Notes:
OpenSSL 3.0.14.0 has known vulnerabilities (e.g., CVE-2024-5535), fixed in 3.0.15.
Manually deleting DriverStore folders isn’t advised—use pnputil to avoid issues.
Check your specific oemXX.inf number in the pnputil /enum-drivers output before deleting.
This worked for me without breaking anything. Hopefully, it helps others facing the same Defender alerts!

[AndAuf]

That's nice for you, and it is obvious that such things work. I bet it is also possible to manually change the DLLs with newer ones.

But we are talking about hundreds or thousands of devices!

[NiKiZe]

Spent a month or so on this as well, reading this post and some others over and over

In the end as mentioned by @saulov8 version 1.75.121.0 is (for now) a fix for some units, however newer devices uses a different ID which the new driver does not support, so still need to stay on 1.74.210.0.

However, if the parent MEI interface driver is updated, the iCLS device "goes away" and no driver is needed.
So the fix is to update MEI, and then cleanup CLS device, or update it's driver, depending on your hardware.

Writeup at https://gist.github.com/NiKiZe/a7946813c6bcb884c256157b66b215d2

[NiKiZe]

So iclsclient.inf_amd64_bc9b92a50d527061 1.75.121.0 is now vulnerable again CVE-2024-13176, CVE-2024-9143
Latest version at https://www.intel.com/content/www/us/en/download/682431/intel-management-engine-drivers-for-windows-10-and-windows-11.html is 2512.7.13.0 and does not contain any more recent drivers

[dcpoirier]

This is a very good thread. I see the same issue in my environment. I am trying to get Dell to step up as anything from Intel should be updated automatically by Dell Command | Update. I am not getting the desired reaction from Dell who is accountable (we paid Dell, not Intel) and needs to act accordingly.  Thanks to all for pushing on this common and unacceptable issue.

[Sven7]

There is a very simple rule: if you use a library, you are responsible for updating it.

Intel is using an openssl-library, so they need to update their software as soon as openssl is updated.

I have to manage the computers in my company. We have about 2000 software products that I need to manage. There is no way for me to check whether a vulnerable library is being used in a way that this vulnerability can be exploited - I don't care how the library is being used: if you use it, you need to keep it up-to-date. If a library is vulnerable, replace it now - that's it. Not in 2 months, not next time a release cycle is planned - just now.

If intel is not able to keep drivers up-to-date and replace libraries with updated libraries when a vulnerability has been uncovered and fixed in a newer version, then I cannot use intel products in my company anymore. It's as simple as this.

Developers as well as product managers in big companies should start acting like grown-up, professional people. They need to take into account that developing any software will generate a stream of events that will add additional work and cost: updating the libraries and adapting to new OS versions.