Vulnérabilités sur processeur neuf

Pause Café
#1

Bonjour,

J’ai acheté, il y a moins de quatre semaines, un processeur AMD Ryzen 5 5500 neuf pour ma machine.
Quand je lance lscpu, je peux lire les lignes suivantes :

Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP always-on, RSB filling, PBRSB-eIBRS Not affected

Je ne comprends pas, ça veut dire que les vulnérabilités Spectre ne sont toujours pas corrigées ou c’est le noyau qui applique les corrections dans le doute ?

#2

Bonjour,

Cela veut dire que le noyau applique les mesures de réduction des risques (mitigations) auquel le processeur est vulnérable (les AMD Ryzen 5000 sont bien vulnérables à spectre et variantes)
Les fabricants de processeurs fournissent des patchs dans leur micrologiciels, possiblement présents dans le paquet amd64-microcode.

1 J'aime
#3

je confirme ce que dit @anon70622873 , j’utilise aussi de l’AMD Ryzen 5 et j’ai la même chose.

#4

salut
suite au post j’ai vu mon lscpu

Vulnerability Itlb multihit:            Not affected
Vulnerability L1tf:                     Not affected
Vulnerability Mds:                      Not affected
Vulnerability Meltdown:                 Not affected
Vulnerability Mmio stale data:          Not affected
Vulnerability Spec store bypass:        Mitigation; Speculative Store Bypass dis
                                        abled via prctl and seccomp
Vulnerability Spectre v1:               Mitigation; usercopy/swapgs barriers and
                                         __user pointer sanitization
Vulnerability Spectre v2:               Mitigation; Retpolines, IBPB conditional
                                        , IBRS_FW, STIBP conditional, RSB fillin
                                        g
Vulnerability Srbds:                    Not affected
Vulnerability Tsx async abort:          Not affected

avec amd64-microcode installé

j’ai alors installé spectre-meltdown-checker

et spectre-meltdown-checker --live
me donne un résultat avec plein de
STATUS: NOT VULNERABLE
mais un
STATUS: VULNERABLE
( je ne donne pas lequel ici pour l’instant ), le temps de voir

#5

Ah, je n’ai pas installé ce paquet, sans doute devrais-je le faire…

Ou pas, je vais attendre de voir ce qui se dit par la suite.

#6

n’oubliez pas une chose pourtant simple:

  • l’existence d’une vulnérabilité n’en présuppose pas pour autant son exploitabilité

en simple, pour pouvoir exploiter une vulnerabilité, encore faut il avoir accès à cette vulnerabilité.

Votre frigo n’a pas de serrure, donc on pourrait penser que n’importe qui peut se servir. ce qui n’est aps le cas car il faut d’abord pénétrer dans la maison.

c’est ici le même principe.

2 J'aime
#7

Tout à fait
je vais de ce pas mettre une serrure sur mon frigo
d’ailleurs ça existe , je viens de voir ça!

Mais pour la vulnérabilité/exploitation, le but de nos programmes est aussi de faire le boulot à notre place.

Mais sur mon proc, j’aimerais savoir comment on peut hacker pour savoir justement si cette vulnerabilité est exploitable et comment.

#8

non les developpeur sont aussi mauvais souvent que les architectes, donc ne faire confiance completement ni aux uns ni aux autres reste la meilleure defense

donc quand tu sais que tu as une faille, que le soft ne suis pas dans les temps (ce qui est toujours le cas, ça a meme ete démontré mathématiquement, comme les virus) alors il faut faire en sorte de rendre l’exploitation difficile voir impossible. tans que les admin et users ne sont pas complètement débile, et c’est d’ailleurs cette partie qui est la plus difficile

2 J'aime
#9

et comment tu fais sans utiliser des programmes qui font le boulot à ta place ? tu mets une pile sur chaque bit?

#10

Quel manque d’imagination.
Principalement en faisant de l’ingénierie sociale.
Si une faille nécessite d’avoir accès à la console, ou physiquement à la machine, tu limites l’accès à la machine.
Si une faille necessite de passer par une autre faille pour l’exploiiter, et que cette autre faille est évitable, alors tu corriges ton système pour éviter l’accès à la seconde faille: exemple: le virus NIMDA en 2001/2002 a pu infecter de nombre systèmes car ceux ci étaient infecté par Code RED, pourtant facile à corriger.
Etc…Etc…Etc…

1 J'aime