La peinture de la dépêche sur la faille Lazy FPU save restore n'étais pas encore sèche
que je tombais sur de curieux messages conseillant de désactiver l'Hyper-threading.
Suivis de conversations plus ou moins inquiétantes sur Twitter et dans les mailings list.
Accroche toi au pinceau
Un commit sur OpenBSD désactive l' Hyper-treading par défaut.
Le message associé est explicite:
« Since many modern machines no longer provide the ability to disable Hyper-threading in
the BIOS setup, provide a way to disable the use of additional
processor threads in our scheduler. And since we suspect there are
serious risks, we disable them by default »
Puisque les machines récentes ne donnent plus la possibilité de désactiver l' Hyper-threading depuis le BIOS, trouvez un moyen de désactiver l'utilisation des threads d'un processeur dans notre ordonnanceur.
Et comme on suspecte que le risque est sérieux, désactivons le par défaut.
Pour faire plus court, j'avais lu auparavant un laconique:
ps deactivate Hyper-threading on your server
Désactivez l'Hyper-threading sur vos serveurs !
Venant des équipes OpenBSD, il y a de quoi s'interroger.
J'enlève l'échelle
La conférence Black Hat qui se déroulera en août prochain, propose au menu:
« This therefore bypasses several proposed CPU cache side-channel protections. Our TLBleed exploit successfully leaks a 256-bit EdDSA key from libgcrypt (used in e.g. GPG) with a
98% success rate after just a single observation of signing operation on a co-resident hyperthread and just 17 seconds of analysis time »
En outre, ceci court-circuite plusieurs protections sur le cache. Notre exploit TLBeed a réussi à voler une clef 256-bit EdDSA depuis ligcrypt (utilisée par GPG ) dans 98% des tentatives, après une simple observation des opérations de signature depuis un thread tournant sur le même CPU en seulement 17 secondes d'analyse.
- sans oublier le petit message de remerciement du sieur de Raadt.
Colin Percival, auteur en 2005 de:
- un papier sur les attaques via les caches, Cache Missing for Fun and Profit
- un article qui cible plus particulièrement les risques liés à l'Hyper-threading
en remet une couche:
« I think it's worth mentioning that one of the big lessons from 2005 is that side channel attacks become much easier if you're executing on the same core as your victim »
Je pense qu'il est bon de rappeler cette grande leçon de 2005: une attaque enside channelest tellement plus facile si vous l'exécutez sur le même cœur que votre victime.
Cuisine
Intel n'est jamais clairement impliqué; mais je précise, comme ça, en passant, que l'Hyper-Threading est une implémentation Intel du Simultaneous Multi Threading.
Il s'agit de faire exécuter en parallèle, sur un même cœur, plusieurs unités fonctionnelles ou de calcul.
Et pour rendre cette technique efficace et moins gourmande en ressource, cette implémentation partage aussi les caches mémoires.
Keep systems protected, efficient, and manageable while minimizing impact on productivity
Conclusion
Toutes les solutions de sécurité aujourd’hui ne sont que des châteaux forts construit sur du sable.
Si encore une fois, la désactivation de l'Hyper-threading pourrait même avoir des effets positifs sur les performances, autant en finir une fois pour toute.
Retour aux origines:
- un partage complet sans protection des ressources
- plus de mode protégé
- pas même de segmentation mémoire
Vos machines iront encore plus vite. Enfin, j'espère.
# HT et performances...
Posté par Pinaraf . Évalué à 10.
Comme souvent, les performances dépendent du cas envisagé pour la comparaison. L'hyper threading est positif pour les performances sur de nombreux cas, c'est pour cela qu'il est activé par défaut, ils sont pas idiots à ce point.
Vivement les détails sur cette faille en tout cas. Impacte-t-elle uniquement Intel ? Est-ce corrigeable par le microcode ? Le même principe serait-il exploitable contre du SPARC ou du POWER ?
[^] # Re: HT et performances...
Posté par claudex . Évalué à 9.
Phoronix à justement fait un benchmark suite à ces révélations,, et effectivement, c'est meilleur avec l'hyperthreading https://www.phoronix.com/scan.php?page=article&item=intel-ht-2018&num=1
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HT et performances...
Posté par Colin Pitrat (site web personnel) . Évalué à 1.
On dirait que le message est pas bien passé …
[^] # Re: HT et performances...
Posté par claudex . Évalué à 3.
Je ne comprends pas ta remarque.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HT et performances...
Posté par totof2000 . Évalué à 2. Dernière modification le 24 juin 2018 à 13:35.
Pour ma part, j'ai constaté une amélioration de perfs de 20 à 35% sur des traitements effectués sur des serveurs Itanium à une époque ou j'administrais encore ce genre de machines.
[^] # Re: HT et performances...
Posté par Pinaraf . Évalué à 5.
Chanceux, des itanium…
Plus sérieusement, étant donné l'architecture complètement différente des itanium par rapport aux x86, je ne suis pas certain que l'on puisse transposer le gain en performances entre les architectures… De plus, selon les logiciels utilisés et le niveau d'optimisation atteint (utiliser complètement le CPU d'un itanium semble être un art obscur) tu pourrais avoir un terrain bien plus favorable à l'HT.
[^] # Re: HT et performances...
Posté par totof2000 . Évalué à 5.
Soit, mais l'idée est surtout d'illustrer le fait que dire "l'hyperthreading ne sert à rien donc désactivez-le" est un peu radical. Il faut voir au cas par cas, selon la façon dont les applis utilisent les CPUs. Dans ce cas précis, les projets nous soutenaient que l'HT n'apportait aucun gain de perfs, et ils ont freiné jusqu'au bout pour l'activer. Ils ont passé leur temps à demander l'achat d'1 module CPU supplémentaire. Au final, on a testé et on s'est rendu compte des gains de perfs, et l'hyperthreading a été activé. La raison pour laquelle ils ont freiné? C'est tout simplemment parce qu'ajouter une carte leur coutait moins cher à eux (le cout ne leur était que faiblement refacturé), alors que l'actiation du HT faisait monter leur cout de licence.
C'est pour ça que j'ai précisé que j'ai constaté ce gain de perfs dans un contexte donné. D'ailleurs, j'avais d'autres applis qui tournaient sur des machines sur lesquelles on avait délibérément désactivé l'HT parce que ces applis ne bénéficiaient que d'un léger gain de perfs (moins de 10%). On aurait pu le laisser parce que finalement 10% c'est toujours ça de pris, mais l'activation de l'HT aurait entrainé des surcoûts de licence.
[^] # Re: HT et performances...
Posté par David Marec . Évalué à 3.
Oui, mais lesquels sont à envisager ?
Je l'ai désactivé sur la présente machine.
Un iquelquechose avec 2*2 cœurs qui fait tourner un FreeBSD
Je n'ai pas grand chose pour faire des mesures, mais, dans son usage classique (bureautique, web et Battle for wesnoth), je ne vois aucune différence, si ce n'est un temps de démarrage plus lent.
Dans son autre usage, compilation et construction de paquets et de systèmes, j'ai pu mesurer les écarts sur un build complet:
Rien de spectaculaire.
Il reste à le voir lorsque que joue avec la virtualisation; mais ce n'est pas la machine idéale pour ça de toute façon.
En ce qui concerne un usage serveur, je n'ai pas les moyens de faire ces tests.
J'ai quand même l'impression que son bénéfice est surestimé.
Le beau discours marketing a eu son rôle à jouer dans l'activation par défaut plus que les benchmarks, AMA.
Ensuite, si le défaut sécurité et d'isolation entre processus est le prix à payer pour ces gains de performances, on peut aller encore plus loin.C'est le message de conclusion.
Oui, mais on en saura pas plus avant août et la conférence Black Hat, AMA.
Bonne question.Seul Intel emploie ce terme.
Pourquoi pas après tout ? Ils sont sensibles à Spectre et proposent du SMT …
Et la technique utilisée semble être celle de Spectre si j'en crois les indices laissé par Colin Percival.
[^] # Re: HT et performances...
Posté par claudex . Évalué à 7.
Tu le dis toi-même, pour ton usage desktop et la compilation, c'est plus lent. Et surtout, l'hyperthreading n'a plus, comme au début, un impact négatif sur les performances, donc à activer par défaut, ça donnera plus de perfs pour les applications qui peuvent en tirer profit et rien pour les autres. Ça ne me semble pas trop venir du discours marketing.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HT et performances...
Posté par David Marec . Évalué à -2.
Euh non, en usage Desktop, je n'ai pas de différence.
Pour la compilation, il s'agit d'un gain de … 12%. Et encore, sur un seul essais, ce n'est pas pertinent.
Il faudrait que je fasse plus de test pour être sûr.
Oui, enfin, au début ça provoquait surtout de beau crashes.
[^] # Re: HT et performances...
Posté par claudex . Évalué à 4.
C'est toi qui l'écrit que le temps de boot est plus important.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HT et performances...
Posté par David Marec . Évalué à 0.
Oui, et ? Moi, pendant ce temps là, Hyper-threading ou pas, je n'utilise pas la machine. Je ne suis pas en "usage desktop", mais plutôt "café" ou "bière" selon l'heure.
Si le temps de boot est important, je ne joue pas dans la même cour, je configure un noyau et un rootfs au millimètre.
Et mes plus beaux scores (~1s) sont sur des architectures qui n'ont pas d'Hyper-Threading.
[^] # Re: HT et performances...
Posté par barmic . Évalué à 3.
Par important il voulait dire long pas "qui as une importance".
[^] # Re: HT et performances...
Posté par Albert_ . Évalué à 1.
Sur un HPC il y a des logiciels pour lesquel l'acceleration est vraiment impressionante et utile mais bon pas au point de la securite donc je soupconne que pas mal de serveurs vont redemarrer bientot et foutre ne l'air de beau uptime ;)
[^] # Re: HT et performances...
Posté par Renault (site web personnel) . Évalué à 8.
Si la sécurité comptait vraiment, l'uptime ne devrait pas être élevé pour justement appliquer les MaJ de sécurité qui le nécessitent (et il y en a régulièrement).
Aujourd'hui un gros uptime est mauvais signe pour la sécurité de l'infrastructure.
[^] # Re: HT et performances...
Posté par Firwen (site web personnel) . Évalué à 1.
Dans le monde HPC, tout logiciel qui a un gain significatif avec l'hyper-threading est un logiciel sous optimum, autrement dit mal codé. Un logiciel hautement optimisé à même tendance à avoir un gain négatif quand il est executé avec l'hyperthreading.
[^] # Re: HT et performances...
Posté par totof2000 . Évalué à 4.
Bof, aujourd'hui on préfère mal coder et compenser par de l'ajout de matériel, ça coute moins cher.
[^] # Re: HT et performances...
Posté par barmic . Évalué à 3.
Pourquoi ?
[^] # Re: HT et performances...
Posté par Firwen (site web personnel) . Évalué à 3.
Si tu prends un processeur Intel moderne haut de gamme (e.g Intel Skylake / Platinium Gold ), tu as généralement deux FPU par coeur avec des tailles de registre allant de jusqu'a 512bits par FPU (AVX-512, chez Intel, AMD c'est différent ).
https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(client)#Front-end
Donc ton processeur peut au maximum exécuter deux instructions AVX-512 par coeur à un moment donné.
Les processeurs Intel étant super-scalaire depuis les années 90, ils peuvent tous exécuter bien plus (a shit-more) que deux instructions par cycle par thread…. Donc un seul et unique thread est largement suffisant pour saturer les deux unité SIMD de ton coeur ( si ton code est vectorisé correctement ) et obtenir la performance de crête de ton processeur avec nombre de coeur == nombre de thread ( sans hyperthreading ).
Si tu "forces" l'hyperthreading, quand tu as déja atteint ce peak, la seule chose que tu vas gagner est une petite pénalité au runtime lié au coût du scheduling associé à l'hyperthreading.
Tu peux reproduire ça assez facilement chez toi en utilisant un petit bench floating-point intensif (e.g mt-dgemm) and un backend BLAS proprement optimisé du genre OpenBLAS, BLIS ou l'Intel MKL.
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Je me demande si c'est toujours vrai avec du code du monde réel. Car le cas que tu décris est celui ou le cache est toujours utilisé. Le moindre cache miss, c'est des centaines de cycle de perdu, qui peuvent être un peu récupéré par de l'hyperthreading (ex: un code d'IO qui n'utilise pas la FPU).
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Firwen (site web personnel) . Évalué à 3. Dernière modification le 26 juin 2018 à 09:58.
Dépend ce que tu appelles monde réel.
Sur un code serveur en Java bourré d'I/O, de branching et de context switch, c'est trés différent de ce que j'ai expliqué plus haut.
Sur un code HPC, on a actuellement un simulateur de réseau neuronaux biologique qui fonctionne de l'ordre de 5% plus lentement avec l'hyperthreading activé sur Skylake & Xeon Phi là où je travaille actuellement, dù à ce que j'ai expliqué plus haut.
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3. Dernière modification le 26 juin 2018 à 19:38.
Il n'utilise pas beaucoup de mémoire ?
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Firwen (site web personnel) . Évalué à 1.
Il utilise énormément de mémoire ( aisément0 75/80% de la capacité des noeuds ). Mais les calculs effectués ont une trés grosse localité.
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Peu d'IO alors ?
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Firwen (site web personnel) . Évalué à 1.
Comme quasiment tous les simulateurs, Zero I/O sauf dans une phase de reporting finale où l'intégralité des noeuds font du écrivent tous en parallèle (Burst I/O ).
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il y a aussi beaucoup de simulateur qui crache beaucoup de log, ou qui font des checkpoints pour reprendre leur travaux en cas de crash.
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
En tout cas, vous êtes dans le cas idéal pour utiliser les CPU à fond : localité d'accès + pas d'IO + vectorisation.
Et coté chaleur, vous avez fait quelques choses ? Les derniers cpu d'intel parte du principe qu'ils doivent ralentir au delà d'une certaine température, ce qui est forcément le cas avec un cas d'usage aussi intense.
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Firwen (site web personnel) . Évalué à 2.
C'est le cas sur les séries KNL en effet.
[^] # Re: HT et performances...
Posté par Zenitram (site web personnel) . Évalué à 3.
Et si le code n'est pas vectorisable (plein de "if" qui se baladent, par exemple)?
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je ne sais pas pour l'AVX, mais sur un cpu x86 64 bits, le code FPU x87 est remplacé par les instructions "scalaire" SSE. De mémoire, c'est AMD qui avait rendu obligatoire le support SSE 2.1 pour son 64 bits, repris par intel. Je ne pense pas que l'unité SIMD peut être utilisé par morceau.
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Firwen (site web personnel) . Évalué à 2. Dernière modification le 26 juin 2018 à 10:02.
Avec les masques SIMD et les instructions gather / scatter, même si ton code branche (pas trop excessivement), il peut se vectoriser correctement de nos jours.
C'est d'ailleurs l'astuce utilisé par CUDA / les backend OpenCL pour gérer correctement le branching sur des architectures SIMT.
[^] # Re: HT et performances...
Posté par Albert_ . Évalué à 3. Dernière modification le 25 juin 2018 à 22:51.
Dans le monde reel il y a aussi des logiciels proprios dispos sur HPC dont tu n'as pas le code qui fonctionne beaucoup plus vite si tu utilises l'hyperthreading.
Que cela soit mal code, je n'en doute pas vu la dette technos qu'ils se tapent mais bon quand tu n'as pas le choix tu fais avec…
[^] # Re: HT et performances...
Posté par Firwen (site web personnel) . Évalué à 1.
Tu as un nom particulier en tête ?
[^] # Re: HT et performances...
Posté par Albert_ . Évalué à 7. Dernière modification le 26 juin 2018 à 13:25.
Abaqus et Ansys pour t'en citer deux enfin surtout le deuxieme qui est un collection de plein de logiciels qui ont ete agrege en fonction des achats d'autre entreprise. C'est un melting pot fait de bric et de broc avec une sorte de colle en mono/C#. C'est assez deguelasse comme truc mais tres utilise dans certains domaines.
[^] # Re: HT et performances...
Posté par Pinaraf . Évalué à 7.
Heu… 12,5% de pertes quand on désactive HT ça te suffit pas (Ou 11,11% de gain, on va pas chipoter) ? L'HT va pas faire un x2 en perfs, mais si l'HT était bien implémenté il serait idiot de ne pas l'activer.
[^] # Re: HT et performances...
Posté par Benoît Sibaud (site web personnel) . Évalué à 10. Dernière modification le 24 juin 2018 à 10:40.
Vu la quantité d'octets pour disserter sur un passage de 90km/h à 80km/h sur route nationale sans hyperthreading, il semble tout à fait possible de débattre longtemps sécurité vs vitesse ici aussi, sur 80min vs 90min.
[^] # Re: HT et performances...
Posté par windu.2b . Évalué à 4.
Quid de la consommation électrique ? Donc de l'autonomie (pour des laptops) ?
[^] # Re: HT et performances...
Posté par barmic . Évalué à 6.
Je suis resté sur l'idée que plus ça va vite mieux c'est pour l'autonomie car les CPU savent bien gérer leur consommation (à comparer aux autres composants d'un ordinateur) donc il vaut mieux faire un traitement aussi rapide que possible et repasser toute la machine en état de veille. Pour cet exemple, il faut comparer la hausse de consommation de l'HT aux 10 minutes d'utilisation plus ou moins intensives du disque dur.
C'est donc pas au niveau du CPU lui-même mais de toute la machine qu'il faut observer la comparaison pour qu'elle soit pertinente.
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Le principe même du SMT, c'est de partager des ressources processeurs entre 2 processus. Car avec d'énormes pipelines (~ 30 étages) et 5 unités en parallèle, il y a souvent des "bulles", des bouts de pipelines "vides". En moyenne, il y a un ipc de 3, cela veut dire 3 instructions exécutés, cela laisse ~40% d'inactivités.
Le SMT permet d'utiliser ces cycles inutilisés. Cela n'est pas idiot. Le gain est bien plus faible à cause de la pression sur les caches. En jouant 2 processus, on tue la localité des données. D'où le fait que les premier SMT utilisant 4 threads puis Intel est passé à 2.
AMD dans ses bulldozers, a fait un truc intermédiaire : dédier des ALU et pas seulement des bancs de registres. L'erreur a été de faire croire que c'était des vrai cpu complet.
D'un point de vue sécurité, c'est toujours du partage de ressource. Donc, si on peut mesurer les performances, on peut savoir l'usage des ressource de l'autre thread, ce qui est clairement une attaque side-channel.
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 25 juin 2018 à 13:41.
Bah malheureusement, Intel est le plus étudié (et peut-être le moins bien protégé), néanmoins, AMD est aussi touché a priori. Le problème viens du concept de base de ce que j'en ai compris. En fait il s'agit d'une toute une nouvelle classe de faille (inauguré/popularisé par Spectre et Meltdown) sur lesquels on savait qu'il y avait probablement des failles mais ou l'on était jamais descendu aussi bas car les pirates avaient plus simple (Buffer overflow…). C'est l'amélioration de la sécurité des OS / logiciels / BIOS et des chercheur qui a permis de découvrir ce genre de problème.
Tout n'est donc pas corrigeable par du micro-code, pire, c'est en partie l'architecture du processeur qui est à repenser et donc il faudra des années avant que ne sorte des processeurs fiable…
Néanmoins, rappelons que ce n'est pas si simple à exploiter et que cela demande auparavant d'avoir accès a l'ordinateur (une console). Mais cela permet potentiellement de sortir de la VM et d'avoir les droits root.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Pas vraiment, il est tout à fait possible pour Intel de fournir un petit peu de contrôle sur le truc, un peu comme le verrouillage de mémoire pour éviter de swapper des clefs sur le disque dure. Après je ne connais pas les détails de l'attaque mais en général, le principe de la défense est que le timing ne dépend plus des données.
"La première sécurité est la liberté"
# Rien de nouveau...
Posté par HacKurx . Évalué à 6. Dernière modification le 23 juin 2018 à 08:50.
Bonjour,
Les problèmes de conception de Hyper-threading sont connus depuis longtemps.
L'ANSSI recommande sa désactivation (pour cause de canaux cachés difficilement maîtrisables) voir le document :
https://www.ssi.gouv.fr/uploads/2015/03/NP_ConfigMateriel.pdf
OpenBSD à juste un train de retard… C'est surtout un coup de pub gratuite !
Normal c'est plus simple à faire que de résoudre des gros problèmes de conception… Voir par exemple :
https://news.ycombinator.com/item?id=17252154
Voyons voir ce que va faire HardenedBSD ;)
[^] # Re: Rien de nouveau...
Posté par David Marec . Évalué à 1.
Oui, 2005. C'est écrit dans le journal.
Non.
Ils vous attendent pour ça. Non ?
Attendre que FreeBSD fasse un truc ?
[^] # Re: Rien de nouveau...
Posté par David Marec . Évalué à 5.
En fait, c'est déjà fait:
[^] # Re: Rien de nouveau...
Posté par HacKurx . Évalué à -1.
Ah bon, alors pourquoi ils n'ont pas corrigé en 2005 ? La sécurité est le but d'OpenBSD. Non ?
D'ailleurs OpenBSD a accès à tous les embargos (même de manière non publique par leurs sponsors) pour se préparer en avance. Non ?
Ce n'est pas le cas ? Mais alors pourquoi ?
Non car beaucoup sont trop orgueilleux pour accepter les critiques et déjà prendre en compte le commentaire de pipacs alias PaX Team.
Ou pas… N'oubliez pas que le but d'HardenedBSD c'est de remonter en amont (donc FreeBSD…) des technologies d'atténuation d'exploit.
https://hardenedbsd.org/content/projects
https://hardenedbsd.org/content/easy-feature-comparison
La désactivation n'étant pas une technologie de protection mais juste une parade.
# Et pourtant
Posté par Misc (site web personnel) . Évalué à 7.
Et pourtant, ça suffit quand même très largement. Y une industrie entière dédié à trouver des failles, et pourtant, je suis sur que la majorité des failles ayant un CVE assignés sont non exploités, et que sur celles qui le sont, y en a qu'une infime minorité qui impacte vraiment du monde.
Franchement, faut à un moment juste prendre du recul, parce que sur le long terme, c'est impossible de faire autrement, et je plaint vraiment les gens qui n'arrivent pas à la même conclusion et qui font des burn outs pour ça.
Et c'est sans doute pas pour rien que le programme de blackhat 2018 parle quand même pas mal de ça:
https://www.blackhat.com/us-18/briefings.html#stress-and-hacking-understanding-cognitive-stress-in-tactical-cyber-ops
https://www.blackhat.com/us-18/briefings.html#mental-health-hacks-fighting-burnout-depression-and-suicide-in-the-hacker-community
https://www.blackhat.com/us-18/briefings.html#holding-on-for-tonight-addiction-in-infosec
https://www.blackhat.com/us-18/briefings.html#demystifying-ptsd-in-the-cybersecurity-environment
[^] # Re: Et pourtant
Posté par reno . Évalué à 4.
Quand on pense au nombre de téléphone Android non sécurisé c'est vraiment surprenant qu'il n'y ai pas encore eu un malware qui ai affecté des millions de téléphones..
[^] # Re: Et pourtant
Posté par Renault (site web personnel) . Évalué à 7.
Ce n'est pas parce qu'il existe une faille qu'elle est exploitable à distance, qu'elle permet de tout faire ni qu'elle est simple à diffuser.
Beaucoup d'utilisateurs d'Android installent des applications provenant de sources pas trop dégueulasses (ce qui limite le risque de diffusion d'un virus par ce biais). L’hétérogénéité du parc joue aussi comme une force (à défaut d'être tous à jour) car les versions des composants du système diffèrent fortement d'un Android à l'autre (pas le même noyau, pas la même surcouche, pas les mêmes composants de base d'Android, etc.) ce qui rend une attaque générique plus délicate.
Puis le système Android a de nombreuses protections à l'aide de seccomp, l'isolation des applications, SELinux, etc. Une faille fait donc moins de dégâts et peut difficilement rebondir ailleurs.
Bref, la situation d'Android en terme de mise à jour du parc est une catastrophe, c'est certain. Mais le fait que les attaques d'envergure soient rares voire absentes montre que la situation n'est pas si catastrophique non plus car le système a de nombreuses protections préventives. Et que de toute façon exploiter une faille c'est loin d'être si simple.
[^] # Re: Et pourtant
Posté par Misc (site web personnel) . Évalué à 4.
Ni que ça soit rentable. Parce que bon, les gens capables d'exploiter des failles, y en a assez mais assez peu qui bossent gratos au final.
Pourquoi se faire chier avec des terminaux poussifs sans bande passante et ram alors qu'il y a des pcs de bureaux. La seule raison de faire des choses sur un tel portable, c'est le modem GSM et ce qu'il permet comme appel surtaxé, et je suis sur que personne ne veut vraiment laisser de trace de ce genre. Je serais pas surpris du fait que les différents opérateurs payent au moins et/ou avec du retard (genre, à 45j), ce qui laisse le temps à la victime de voir un souci, puis à l'opérateur de chercher plus en détails.
[^] # Re: Et pourtant
Posté par LaBienPensanceMaTuer . Évalué à 6.
Ou de faire dans le ramsomware: chiffrer le contenu du téléphone, et demander des bitcoins pour que l'utilisateur retrouve ses données.
Ou récupérer des informations bancaires.
Ou récupérer des comptes email pour le spam.
Ou récupérer ….
Y a toujours une raison "pécuniaire" de compromettre un device…
[^] # Re: Et pourtant
Posté par FantastIX . Évalué à 1.
Que dis-tu de cette démonstration? Si ça ne parle pas d'exploiter ladite faille, cette démonstration indique clairement que des attaques à distance sont loin d'être difficiles, pour peu qu'on ait le kit adéquat.
[^] # Re: Et pourtant
Posté par Renault (site web personnel) . Évalué à 6. Dernière modification le 27 juin 2018 à 13:54.
Tu me fais dire ce que je n'ai pas dit.
Ce que j'ai dit est comme tu l'as cité :
Je n'ai pas dit qu'une faille ne pouvait pas être exploitée facilement à distance. Je dis uniquement que découvrir une faille ne signifie pas :
Mais tu as des failles qui répondent à ces trois cas (ce que tu montres a au moins deux caractéristiques), mais c'est plutôt rare en fait (beaucoup nécessitent beaucoup de temps pour en tirer profit ce qui limite son utilisation).
Et on en a la preuve tous les jours, malgré des failles à foison due en partie à des mises à jour non appliquées (Android, Windows, Flash Player, vieilles distro qui trainent, etc.) on est loin d'avoir une exploitation de failles si globale. Car ce n'est pas si simple et que découvrir une faille ne signifie pas qu'elle sera effectivement exploitée.
[^] # Re: Et pourtant
Posté par pasBill pasGates . Évalué à 4.
Principalement car il est plus facile de laisser l'utilisateur installer le malware…
https://www.zdnet.com/article/android-malware-millions-fall-victim-to-drive-by-cryptocurrency-miner/
# Hyper threading => plus rapide au crash
Posté par tao popus . Évalué à 1.
Sur différents serveurs sur lesquels il était activé, avec quelques vm qui tournent dessus. On a constaté des crash dans les 2~3 mois. Suite à un article je ne sais plus où (ici ?) il y a un peu plus d'un an on a désactiver quand rencontre crash, et après plus d'un an, plus de crash.
Donc, oui, c'est plus rapide au crash, ce qui ne vaut pas le peu de gain de performance gagné dans certains cas…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.