Dans la lignée des attaques de type Spectre ou Meltdown, les chercheurs en sécurité s’en donnent à cœur joie et n’en finissent plus de trouver de nouvelles failles. Un site Web a été mis en place pour décrire la toute nouvelle attaque CacheOut (avec un beau logo, comme c’est devenu l’habitude) : https://cacheoutattack.com/.
En résumé, voici comment ça marche : suite aux précédentes attaques, il avait été constaté que différents tampons internes des processeurs Intel pouvaient laisser fuir leurs données. Ces attaques, nommées « Microarchitectural Data Sampling » (MDS), avaient été jugées très graves car elles permettaient de siphonner des données indépendamment de toutes les barrières de sécurité inter‑processus.
Pour corriger cette faille, les ingénieurs Intel avaient poussé un correctif du microcode du processeur. Ce correctif réutilisait l’instruction VERW afin de vider les tampons lors de chaque changement de domaine de sécurité.
Tampons vides, donc attaque impossible, donc problème des attaques MDS résolu… Du moins, c’est ce qu’on croyait !
Avec la nouvelle attaque CacheOut, les chercheurs mettent en évidence la possibilité de retrouver les données qui ont été effacées des tampons. En effet, ces données sont toujours dans le cache L1 et il est possible d’obliger le processeur à recopier ces données dans les tampons même après le passage de l’instruction VERW.
Citation du PDF :
For CacheOut, we build on the observation that on Intel CPUs, dirty lines from the L1 cache are evicted to the L2 cache via the line fill buffers, where their content remains until overwritten. Thus we can use a faulting or assisting load to recover it.
This behavior has two implications. First, using VERW to flush the CPU buffers on security domain changes does not mitigate CacheOut, because L1 eviction of victim’s dirty lines into the fill buffer can occur well after the context switch and the associated verw instruction.
Non seulement le correctif basé sur VERW ne corrige pas la faille, mais en plus la nouvelle attaque permet de choisir ce qu’on veut extraire, alors qu’avant on récupérait plein de données au hasard.
C’est donc une faille de sécurité très grave et Intel (qui a été mis au courant en octobre 2019 par les chercheurs) va proposer rapidement un nouveau correctif du microcode. Mais il y aura sans doute un impact sur les performances s’il faut vider le cache L1 régulièrement…
En ce qui concerne les autres fabricants de processeurs, voici ce qu’écrivent les chercheurs dans leur FAQ :
AMD is not affected by CacheOut, as AMD does not offer any feature akin to Intel TSX on their current offering of CPUs.
ARM and IBM do have a feature similar to Intel TSX, but we are currently unaware of whether any of their products are affected. We are also unaware of any other attack vectors to exploit CacheOut.
# Trou ouvert?
Posté par ʭ ☯ . Évalué à 5.
J'ai du mal à comprendre : il n'y a pas de correctif au niveau Linux implémenté en attendant un hypothétique correctif microcode?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par benoar . Évalué à 2.
Encore une fois, il faut voir dans quel contexte c'est exploitable : pour des gens qui font tourner du code malveillant utilisant les instructions TSX. Qui fait ça ? Ceux qui installent du code venu de n'importe où, sans vérifier. Vous étonnez-vous qu'après il y ait des problèmes ?
Ça affecte aussi ceux qui sont collocalisés sur des hyperviseurs avec des VMs adjacentes malveillantes : déjà, les chercheurs qui ont trouvé la faille indiquent avoir déjà prévenu les fournisseurs de cloud (ils ne précisent pas lesquels, comme si c'était évident qu'il n'y en ait que quelques gros…), et puis quand vous faites tourner votre code sur la machine de quelqu'un d'autre, vous étonnez-vous que vos données puissent éventuellement fuiter ?
Pour une fois, je ne vais pas râler sur l'utilisation à outrance de codes inconnus dans un browser par Javascript puisque cette faille-ci nécessite l'utilisation d'instructions TSX, qui ne sont pas accessibles en JS.
Bref, cette attaque est encore une fois très spécifique, et n'affecteront jamais des personnes qui utilisent uniquement du logiciel libre et maîtrisent leur informatique. Si vous utilisez du logiciel privateur ou faites tourner votre code sur la machine de quelqu'un d'autre, il y a bien d'autres « problèmes de sécurité » à vous soucier avant ce genre de faille ! Cf. ce que j'avais déjà dit ici.
Alors après c'est techniquement très intéressant à lire, merci patrick_g ! Et je ne suis pas un pro-Intel du tout, bien au contraire, je trouve que c'est « bien fait » pour eux qui ont toujours utilisé des méthodes très limite pour imposer leur mainmise sur l'industrie. Mais franchement, l'impact réel du truc… Ah si, ça permettra d'avoir des CPU Intel puissants pas cher d'occasion pour ceux qui n'utilisent que du libre !
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Kerro . Évalué à 10.
Tu as l'air de dire que tout le monde doit maîtriser à mort son infra. N'empêche qu'un gros avantage de la virtualisation et du partage de machines est justement qu'on délègue cette maîtrise. Et on réduit les coûts.
C'est tout de même dommage de se passer de ça.
Imaginons tout de même que tu as une infra dédiée, tu as tout cadenassé dans ta cave, tu es super tranquille.
Le jour où un attaquant arrive a se connecter sur une de tes machines via un compte non privilégié, il peut utiliser cette faille --> ta super maîtrise est par terre.
C'est certes plus difficile qu'une attaque via une machine virtuelle voisine, mais c'est une vraie grosse faille de sécurité qui s'ajoute à la foulitude d'autres faiblesses permettant de s'introduire dans un système étape par étape.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par kowalsky . Évalué à 7.
Ce jour la, la faille Intel sera le dernier de tes soucis, non ?
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Anonyme . Évalué à 10.
La sécurité ça se fait à tous les niveaux.
Avoir un portail devant son jardin, ça n’empêche pas de mettre une porte à sa maison.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par oau . Évalué à 6.
j'aimerais bien qu'on me démontre cette réduction des coûts. Vu les tarifs pratiqués par les grands fournisseurs de cloud je suis pas du tout sûr que ça coûte moins cher d'avoir son infra chez eux. À moins bien sûr de n'avoir que des vps et encore.
Et je ne parle que des coûts bruts. Sans parler de la dépendance technologique à des services cloud dont on ne sait pas grand-chose.
Pour ma part ma plateforme chez ovh me coûte 500€ HT par mois. Ce qui me donne 5 machines pour un total de 160Go de ram, 40cpu et 12to de ssd et une interco réseau de 2Gbps. J'y fais tourner 400 container docker, un kubernetes et un ceph.
Honnêtement je trouve le prix très raisonnable.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Guillaume Rossignol . Évalué à 6.
Comparer du self-hosting avec du cloud, c'est un peu comme comparer l'acquisition d'une voiture par rapport à la louer/utiliser un taxi en cas de besoin. Il y a des cas où un des deux est évident, mais la pertinence du choix est rarement sur le coût seul.
Pour 500€ par mois, tu as déjà beaucoup de choses en cloud, est surtout, tu as ~0 temps d'administration/surveillance/gestion. Je ne me suis jamais posé la question de si j'ai encore assez de place sur S3, alors que sur mes serveur OVH, ca m'arrive de vérifier leur état de santé.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Kerro . Évalué à 7.
Tu vois cela en tant qu'entreprise qui utilise massivement l'informatique.
L'immense majorité des entreprises sont petites. 500 € mensuel pour l'infra est énorme pour 90 % de celles qui ont besoin d'un serveur ou d'un bureau à distance.
Pour ma part je loue des VPS pour certains petits besoins, ça me coûte moins de 35 € mensuel pour 10 VPS avec chacun 200 Mb/s de débit (le débit est important pour le besoin).
Si tu sais faire moins cher, faisons affaire ensemble.
J'ai des clients qui ont des serveurs Windows virtualisés chez des prestataires. Ça leur coûte moins cher que d'avoir la même chose en local, et ça leur coûte moins cher que d'avoir un serveur dédié pour leur pomme. La plupart sont sur des hyperviseurs partagés.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par claudex . Évalué à 4.
Globalement, le gros avantage du cloud, c'est la flexibilité. Si tu fais tourner tes machines H24, ce sera sans doute pas très utile (Après, 5 VM c4.4large chez AWS c'est 345$/mois pour 1an payé d'avance, après, le stockage, il faut voir ce qu'il y a besoin (genre, si on peut utiliser du stockage objet)). Par contre, si tu commence à en avoir que tu n'as pas besoin d'avoir allumé en permanence, là ça devient beaucoup plus intéressant (genre, les mêmes VM sont à 290$/mois si tu les as allumé 50% du temps. Si tu utilise des machines préemptible, tu as des coûts très faible (1.2$/heure pour une machine avec 96 cores et 640GB de RAM).
Après, ce n'est pas vraiment sur des infras à 5VM que tu optimise ces coûts. Plutôt sur des infras à 500VM (ou 50000) où tu auras plus facilement des VM que tu peux éteindre à certains moments.
Et puis surtout, ce sont tous les services autour. Les fonctions qui sont très peu cher si tu n'as pas de charge. Par exemple, les cloud function chez GCP sont à 0.4$/million d'appel. Si tu n'as pas des services très chargé, c'est pas cher de les héberger là dessus. Tu peux spawner une base de donnée SQL rapidement, tu as le stockage S3, tu as une redondance assez élévée et une présence dans le monde entier.
Bien sûr, tout es faisable sans le cloud (quoique, BigQuery, c'est plus compliqué). L'intérêt, c'est que tout est là, tu n'as qu'à faire quelques appels à l'API est c'est disponible (quand tu créer des dizaines de machines par jour, c'est pratique), tu peux doubler ta capacité temporairement.
Alors, le cloud, ce n'est pas magique. Tu ne vas pas simplement démarrer ton infra existante dans le cloud et économiser. Globalement, il faut regarder ce qui tourne et voir sur quoi il peut être migrer. Regarder vers quoi les développements futurs de la boîte s'orientent. Et pour 500€/mois, tu n'économiseras sans doute pas assez pour que ça vaille la peine.
« 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: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Anonyme . Évalué à 2.
On dépense plusieurs centaines de milliers de dollars chez GCP/AWS, je peux t’assurer qu’à tarif égal, OVH serait incapable de nous fournir la même qualité de service.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par benoar . Évalué à 3.
J'aimerais, mais je sais bien que ça n'est pas possible. Et à ce moment-là, comme le dit kowalsky, tu as bien d'autres problèmes plus prioritaires à te soucier que ces failles.
Je suis d'accord qu'il faut avoir plusieurs niveaux de protection, mais franchement il y aura à mon avis plus simple que cette faille pour arriver à tes fins dans ce cas-là. On fait tout un foin sur cette histoire, alors que plein de gens font tourner des tas de containers pas à jours avec aucun suivi de CVE. Tu veux essayer de « mitiger » après avec ta super protection anti-Cacheout ? Ton ordre des priorités est vraiment étrange, selon moi.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Anonyme . Évalué à 4.
Encore une fois, non !
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par claudex . Évalué à 5.
Si je comprends bien, tu fais tourner tous tes processus en root. Vu que tu as confiance dans le code qui tourne, il n'y a aucun risque. Les failles RCE, ce n'est pas avec exim ou opensmtpd que ça arriverait.
Globalement, avec ce genre de faille, ça veut dire qu'à la moindre RCE, tu bypass les protections du système. Tu peux donc avoir une RCE qui exploite Cacheout et qui installe un malware dans le bios/uefi (je ne dis pas ce que c'est facile à faire). Ça concerne quand même tout le monde qui est connecté avec d'autres personnes.
Et encore, je ne parle pas des entreprises qui ont plusieurs personnes et qui n'ont pas forcément envie que n'importe qui ait accès à n'importe quoi.
« 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: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par benoar . Évalué à 6.
Pas ceux des utilisateurs déjà, puisque l'utilisation des droits est déjà une barrière pour les problèmes humains, qui par définition ne sont pas contrôlable par un admin comme les programmes qui tournent sur sa machine.
Pour les démons, effectivement on met une protection en plus à priori « pas nécessaire » que je trouve déloyal de comparer à cette faille-ci : je pense qu'il y a beaucoup plus de probabilité qu'arrive une RCE qui ne sera pas exploitable pour éscalader les droits que quelqu'un vienne te faire un cacheout sur des secrets spécifiques pour arriver à ses fins. Faire tourner des démons avec des droits distincts, c'est relativement simple, n'a pas d'impact de perf, et te protège de beaucoup de choses. Ici, c'est chiant à mettre en place, pour un gain vraiment très faible. C'est la différence que je fait.
La probabilité que ça arrive est à mon avis assez faible. Mais bon, c'est juste mon avis.
En fait, on ne fait aucune pub pour toutes les bonnes pratiques autres qui sont beaucoup plus logiques et simples à appliquer, et on passe son temps à parler des ces trucs hyper techniques qui ont des probabilité de fonctionner tellement faible que ça en est ridicule. Ça fait parler de Intel, et du bad buzz c'est quand même du buzz, et on donne une attention complètement disproportionnée à ce genre de problème. Ça entraînera forcément une négligence sur d'autres aspects qui auraient pu être beaucoup plus constructifs.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Anonyme . Évalué à 3.
Les gens de GRSec sont globalement pas d’accord avec toi.
Il y a un exploit Meltdown/Spectre qui permet de récupérer l’intégralité de la RAM, en quelques minutes, sans aucun log. C’est pas « des secrets spécifiques ».
Bah vas-y, donne nous tes astuces et bonnes pratiques, on attend que ça.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par benoar . Évalué à 1.
Ça a été montré pour un cas spécifique, mais perso je n'ai pas pu le reproduire, et d'autres personnes me l'ont également confirmé. C'était au début, ça s'est peut-être amélioré depuis, mais on reste sur des méthodes probabilistes qui dépendent d'un alignement de bonnes étoiles (même si oui, ça peut arriver).
Ça se fait pas en un commentaire, et je ne suis pas un méga-spécialiste qui pourrait se permettre de lister ça sereinement. Ce que je veux dire, c'est que la publicité faite sur ces failles occulte un tas d'autres choses qui sont plus importantes, c'est tout.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Kaane . Évalué à 5.
Ne pas confondre la méthode d'exploitation de la faille qui a été trouvée et la faille elle-même. Outre l'exploitation de la faille, il reste la problématique de fond : le cache L1 permet à un processus B d'accéder à des informations mémoire d'un processus A. Même si là les chercheurs précise bien qu'ils n'ont pas de pistes pour un autre type d'attaque qui permettrait d'exploiter cette faille, ça ne veut pas dire qu'une autre attaque n'existe pas et n'existera jamais.
En effet, mais ça veut dire quoi "maitriser son informatique". Tout compiler soit-même à la mimine en s'assurant que l'instruction TSX (et d'autres instructions interagissant avec les échanges de données inter-coeurs, on est jamais trop prudent) ne sont jamais utilisées ? On parle d'une faille hardware là. Le moindre pilote client de base de données ou wrapper Vagrant (et on va pas parler de Docker, KVM, XEN et co.) peuvent potentiellement permettre un nouveau vecteur d'attaque. Il doit pas y avoir grand monde avec le temps, les compétences et la volonté de "maitriser son informatique" à ce point.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par benoar . Évalué à 7.
À une époque, on ne filait pas un gros blob binaire construit spécifiquement pour une utilisation aux gens : on précisait des dépendances « standard », qui pouvaient même être intégrées à un système de gestion de paquet, on avait des soft qui s'adaptaient à des environnement un peu hétérogènes histoire de pouvoir tourner sur les environnements différents existant chez chacun, et on utilisait des formats et protocoles standards.
Aujourd'hui, on fait des images toutes prêtes qui incluent toutes les dépendances figées et inauditables, intégrées dans des systèmes ni signés et peu reproductibles, avec des softs qui ne tolèrent aucune souplesse et sont dans la monoculture, en utilisant des API propres à chaque appli et sans format standard définit.
L'industrie a bien changé en dix ans, oui. Je ne dis pas que le premier modèle n'a pas de désavantages (déploiement plus complexe, moindre rapidité d'évolution radicale, scalabilité plus manuelle), mais au moins niveau maîtrise, fiabilité et insensibilité à ce genre de bug on était beaucoup mieux lotis. Alors déplorer aujourd'hui que « ça n'est pas possible, ma bonne dame », c'est oublier qu'on a troqué des choses qui existaient et qui marchaient très bien contre des petits avantages de praticité qui — en rétrospective — ne valent peut-être pas tant que ça le coup. Même si chacun aura un avis différent sur le côté duquel penche le compromis pour lui.
Perso j'ai choisi Debian, ça n'est pas un choix irréaliste : c'est reproductible, signé, auditable, standard, etc. Je ne vois pas comment on peut écarter un tel bon système en disant qu'il n'existe pas d'alternative au tout « j'exécute n'importe quel binaire » d'aujourd'hui.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Kaane . Évalué à 4.
Je ne suis pas vraiment d'accord. Certes on peut (et c'est toujours vrai aujourd'hui) se préparer un système aux petits oignons en compilant tout manuellement. Mais très peu de gens ont les compétences pour créer et maintenir un tel système.
Désactiver un jeu d'instruction à la compilation, voire dans certains cas dès la phase de configuration, c'est déjà loin d'être évident sur des processeurs modernes. En plus on se retrouve avec un système unique, sur lequel si des bugs spécifiques apparaissent, il faut les gérer seul ou quasiment.
Là il s'agit (si on veut être prudent) de désactiver complètement les fonctionnalités RTM et HLE (et tout ce qui touche à l'hyperthreading, mais ça ça se fait bien). Non seulement il va y avoir un impact vraiment fort sur les perfs qui n'est pas forcément acceptable professionnellement, mais en plus il faut adapter tes fichiers de config et de compilation pour ainsi dire type de machine par type de machine.
A titre d'exemple mon ingesteur de données custom 0MQ+ScyllaDB se prenait 70% de pertes de perfs jusqu'à l'arrivée de retpoline au moment de SPECTRE/MELTDOWN. Pas évident de devoir choisir entre tourner à 30% de perfs ou tripler la facture d'hébergement.
Ça n'est absolument pas la question, certes Debian a des paquets binaires que l'on peut auditer, mais si tu dois compiler quoi que ce soit à la mimine, si tu veux un kernel optimisé ou si tu as besoin du moindre pilote (même libre) qui effectue une étape de compilation au déploiement du package - tu rentres dans le rouge immédiatement.
En fait même si tu ne prends que des packages standards libres Debian, tu vas probablement te retrouver dans le rouge quand même. Déjà pas mal de packages, modules et pilotes sont compilés avec la capacité de détecter et d'activer au runtime des optimisations CPU (crypto, NUMA, HLE etc.), ensuite tu fais quoi si tu as un environnement qui utilise ces instructions ? Tu recompile et tu redéploies tout ? (Dans le cas de retpoline, c'est ce qui s'est passé…)
Généralement si tu bosses dans tout un tas de domaines tu vas chercher à exploiter au maximum ton infrastructure, donc laisser le compilateur optimiser pour toi en mettant un -march qui correspond à ton architecture. Aller choisir les flags à la main un par un est complexe, surtout que les gars chez GCC ne s'attendent absolument pas à avoir un processeur qui possède le flag X mais pas le flag Y - vu qu'il existe exactement 0 processeur réel dans cette situation.
Donc tu te retrouves à essuyer les plâtres sur des configs de compilation qui n'ont aucun sens. Ou tu désactives les fonctions au niveau kernel (ou microcode) et tu regardes ce qui casse. Et clairement c'est pas un job que n'importe qui peut faire, et comme la majorité des boites n'a pas d'Ulrich Drepper sous la main…
Bref utiliser Debian avec des packages traçables n'évite absolument pas le problème. Ça mitige un peu dans le sens ou effectivement tu n’exécutes pas un code tiers qui a une intention malicieuse à la base - mais pour autant ça ne bloque pas une attaque via des logiciels établis.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par benoar . Évalué à 3.
Je ne suis pas sûr qu'on se soit bien compris, mais :
Si tu parles bien d'utiliser sa propre infrastructure qu'on maîtrise pour le triplage de la facture, oui effectivement ça n'est pas un choix facile. On ne peut malheureusement pas tout avoir.
Alors tout ton post parle de recompilation alors que ça n'est pas du tout ce que je promeus ! Au contraire, utiliser des programmes libres utilisant toutes les instructions que tu veux, déjà compilés par ta distro, puisque (dans mon hypothèse) tu n'as pas à te soucier de problèmes de programmes qui ne seraient pas de confiance puisque tu n'utilises que des programmes libres de confiance (ceux de Debian).
Après, une attaque « via des logiciels établis » est toujours possible, mais on commence encore une fois selon moi à entrer dans des probabilités tellement basses que la question du compromis tiens toujours : je préfère me concentrer sur d'autres facteurs (avoir des machines bien à jour, bien configurées) que de psychoter sur un problème avec une probabilité d'arriver minimale.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Kaane . Évalué à 4.
Là le soucis n'est pas tant là confiance dans les logiciels installés que la confiance dans l'ensemble de l'environnement. On est dans un cas ou n'importe quel utilisateur qui arrive à faire s’exécuter n'importe quel programme, même dans un environnement ultra protégé (c'est à dire des droits limités, du SELinux, des cgroups et autre posix capabilities) peut aller lire le contenu du processus d'à coté, voire de la vm d'à coté si elle tourne sur le même processeur physique.
Pour Spectre 2 il y avait trois solutions : soit interdire à tes utilisateurs d’exécuter le moindre processus qui n'est pas certifié. (Donc pas de virtulisation, mais aussi pas de developpement Java, Erlang, Javascript, .Net et j'en passe). Pas évident en environnement professionnel.
Deuxièmement désactiver les options processeurs impactées au niveau du bios (quand c'était possible) ou recompiler l'ensemble des process tournants sur le système sans utiliser les optimisations à risque. Mais là forcément les perfs peuvent prendre cher dans certains cas.
Dernière solution : recompiler le noyau et tous les modules et processus privilégiés (anti-virus, firewall, pilote, tout ce qui utilise des DMA etc.) avec retpoline. Impact de perfs limité dans la majorité des cas, mais il faut bootstrapper tout le système coeur… Du fun quoi…
C'est pas une attaque via un logiciel existant dans lequel tu vas réussir à provoquer un comportement à risque, du moins pas dans le sens ou tu utilises PHP ou Bind pour executer du code avec les droits root. Tu peux forcer le CPU à dumper le contenu d'un bloc du L1 dans le L2 et le récupérer depuis un compte lambda.
Si un jour un crétin trouve un autre exploit de la faille et le met en ligne "pour rire", la probabilité que ça arrive deviendra maximale en quelques heures. On est littéralement à un script près d'avoir un utilisateur non privilégié qui peut dumper le cache L1 du processeur dans un fichier. Après on peut considérer que la probabilité qu'un tel script voit le jour est très faible, c'est un choix. Mais dans tout un tas d’environnements, notamment quand on offre des capacités à ses clients pour exécuter du code custom, c'est quand même un vrai gros risque.
# CacheOut --> CashOut
Posté par Alex G. . Évalué à 3.
Excellent le logo :-)
Make security fun again !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.