Si comme moi vous êtes utilisateur de ce logiciel https://github.com/openhardwaremonitor
Windows Defender sous Windows 11 signale depuis peu une faille.
Ce qui est étonnant c'est que la librairie incriminée (OpenHardwareMonitorLib.sys) est saine.
Certes, sur Github il est reconnu qu'elle donne accès de façon "non sécurisée" à du matériel, mais Microsoft semble plus vicieux en la catégorisant comme cheval de Troie !
https://www.microsoft.com/en-us/wdsi/th ... 2147714384
Même son de cloche sur des logiciels de gestion des ventilateurs ou de gestion led RGB en provenance de grandes marques de cartes mères, cette fois-ci sous WinRing0.
A quoi joue MS, il y a une différence entre avertir d'une faille potentielle et affirmer que c'est une menace type cheval de Troie.
Alerte virale Open Hardware Monitor Win. Defender.
Re: Alerte virale Open Hardware Monitor Win. Defender.
Même fichier, menace différente signalée. Que croire ?
Ce qui est étonnant tout de même c'est qu'il n'y a pas de "OpenHardwareMonitorLib.sys" dans OHM mais un .dll.
Alors j'ai tenté une expérience :
je créé un fichier "OpenHardwareMonitorLib.sys" et ne donne que des droits au système en le passant au préalable en lecture seule
Puis en lançant l'exécutable, déclenchement d'alerte à nouveau, cette fois-ci il y a une intention manifeste Sur un autre PC je tente autre chose, je télécharge la v0.9.6 sur SourceForge, et l'exécute.
Au moment du lancement il y a bien un "OpenHardwareMonitorLib.sys" de 15Ko que se créé.
Après ce lancement, Windows Defender s'adapte et agit immédiatement.
Intrigant.
Quel est le besoin de créer un fichier, ou alors il est créé en se basant sur le matériel trouvé par l'instance afin de ne pas avoir à recchercher à quaque fois ? Étonnant étant donné que le temps d'exécution ne semble pas varier.
Ce qui est étonnant tout de même c'est qu'il n'y a pas de "OpenHardwareMonitorLib.sys" dans OHM mais un .dll.
Alors j'ai tenté une expérience :
je créé un fichier "OpenHardwareMonitorLib.sys" et ne donne que des droits au système en le passant au préalable en lecture seule
Puis en lançant l'exécutable, déclenchement d'alerte à nouveau, cette fois-ci il y a une intention manifeste Sur un autre PC je tente autre chose, je télécharge la v0.9.6 sur SourceForge, et l'exécute.
Au moment du lancement il y a bien un "OpenHardwareMonitorLib.sys" de 15Ko que se créé.
Après ce lancement, Windows Defender s'adapte et agit immédiatement.
Intrigant.
Quel est le besoin de créer un fichier, ou alors il est créé en se basant sur le matériel trouvé par l'instance afin de ne pas avoir à recchercher à quaque fois ? Étonnant étant donné que le temps d'exécution ne semble pas varier.
Re: Alerte virale Open Hardware Monitor Win. Defender.
Documenté ici
https://eclypsium.com/wp-content/upload ... rivers.pdf
mais alors serait-ce WinDef. qui bloquerait "par principe" ce fichier qui a effectivement été une source de menace (une fois modifié) et ce , quel que soit son hash ?
autre documentation https://www.safebreach.com/blog/hp-touc ... 2019-6333/
la lecture de l'article démontre comment la librairie PEUT être utilisée. En revanche elle n'est pas une menace en elle même, c'est juste que de par un "manque de rigueur" dans son code, elle permettrait de mener des actions irrégulières.
Me voilà 'rassuré'.
Ce qui est étonnant c'est que ce fichier .sys créé par OHM est vital pour son exécution. Cependant si WinDif le bloque ça n’empêche pas OHM de fonctionner et de lire les valeurs du matériel.
https://eclypsium.com/wp-content/upload ... rivers.pdf
mais alors serait-ce WinDef. qui bloquerait "par principe" ce fichier qui a effectivement été une source de menace (une fois modifié) et ce , quel que soit son hash ?
autre documentation https://www.safebreach.com/blog/hp-touc ... 2019-6333/
ok, c'est donc le comportement que j'observe aussi.The Open Hardware Monitor library provides a signed kernel driver named “WinRing0,” which is extracted and installed during runtime.
la lecture de l'article démontre comment la librairie PEUT être utilisée. En revanche elle n'est pas une menace en elle même, c'est juste que de par un "manque de rigueur" dans son code, elle permettrait de mener des actions irrégulières.
Me voilà 'rassuré'.
Ce qui est étonnant c'est que ce fichier .sys créé par OHM est vital pour son exécution. Cependant si WinDif le bloque ça n’empêche pas OHM de fonctionner et de lire les valeurs du matériel.