La dernière mise à jour Chrome de Google est sortie, et cette fois la société n'a pas mâché ses mots sur l'un des deux correctifs de sécurité inclus :
Google est au courant qu'un exploit pour CVE-2023-3079 existe à l'état sauvage.
Il n'y a pas de verbiage à deux degrés de séparation, comme nous l'avons souvent vu de Google auparavant, pour dire que l'entreprise "est au courant des rapports" d'un exploit.
Cette fois, c'est "nous en sommes conscients par nous-mêmes", ce qui se traduit encore plus brutalement par "nous savons que des escrocs en abusent au moment où nous parlons", étant donné que le rapport de bogue provient directement du propre groupe de recherche sur les menaces de Google.
Comme d'habitude, cela implique que Google enquêtait sur une attaque active (que ce soit contre Google lui-même ou contre une organisation externe, nous ne le savons pas) dans laquelle Chrome avait été piraté par une faille de sécurité jusque-là inconnue.
Le bogue est décrit simplement comme suit : Tapez Confusion dans V8. (Naturellement, Google n'en dit pas plus à ce stade.)
Comme nous l'avons déjà expliqué, un confusion de type un bogue se produit lorsque vous fournissez à un programme un bloc de données qu'il est censé analyser, valider, traiter et agir d'une manière…
… mais vous parvenez plus tard à tromper le programme pour qu'il interprète les données d'une manière différente, non autorisée, non validée et potentiellement dangereuse.
Les dangers de la confusion des types expliqués
Imaginez que vous écrivez un programme en C. (Peu importe que vous connaissiez le C ou non, vous pouvez tout de même suivre.)
En C, vous déclarez généralement des variables individuellement, non seulement en réservant de la mémoire où elles peuvent être stockées, mais en signalant également au programme comment ces variables sont censées être utilisées.
Par exemple :
long long entier JulianDayNumber ; caractère signé* CustomerName ;
La première déclaration de variable réserve 64 bits pour stocker une ancienne valeur entière représentant le numéro de jour astronomique. (Au cas où vous vous poseriez la question, cet après-midi est JDN 23157 - Les jours juliens commencent à midi, pas à minuit, car les astronomes travaillent souvent la nuit, minuit étant le milieu de leur journée de travail.)
Le second réserve 64 bits pour stocker une adresse mémoire où la chaîne de texte du nom d'un client peut être trouvée.
Comme vous pouvez l'imaginer, vous feriez mieux de ne pas confondre ces deux valeurs, car un nombre logique et sûr à utiliser comme numéro de jour, tel que 23157, serait presque certainement dangereux à utiliser comme adresse mémoire.
Comme vous pouvez le voir sur ce vidage de mémoire d'un programme Windows en cours d'exécution, l'adresse mémoire la plus basse allouée pour l'utilisation commence à 0x00370000, qui est 3,604,480 XNUMX XNUMX en décimal, bien plus grand que n'importe quel nombre de jours raisonnable.
Les adresses mémoire réelles utilisées par Windows varient de manière aléatoire au fil du temps, pour rendre votre disposition de mémoire plus difficile à deviner pour les escrocs, donc si vous deviez exécuter le même programme, vous obtiendriez des valeurs, mais elles seront néanmoins similaires :
Et (bien que ce soit au bas de l'image ci-dessus) les adresses mémoire de la section des données utilisateur d'exécution lorsque ce programme a été exécuté à partir de 0x01130000 à 0x01134FFF, représentant la plage de dates improbable du 22 juillet 44631 au 16 août 44687.
En effet, si vous essayez de mélanger ces deux variables, le compilateur devrait essayer de vous avertir, par exemple comme ceci :
JulianDayNumber = CustomerName ; CustomerName = JulianDayNumber ; avertissement : l'affectation crée un entier à partir d'un pointeur sans transtypage avertissement : l'affectation crée un pointeur à partir d'un entier sans transtypage
Maintenant, si vous avez déjà programmé en C, vous saurez que pour plus de commodité, vous pouvez déclarer des variables avec plusieurs interprétations différentes en utilisant le union mot-clé, comme ceci :
union { long long entier JulianDayNumer ; caractère signé* CustomerName ; } données;
Vous pouvez maintenant référencer exactement la même variable en mémoire de deux manières différentes.
Si vous écrivez data.JulianDayNumber, vous interprétez comme par magie les données stockées comme un entier, mais en écrivant data.CustomerName indique au compilateur que vous faites référence à une adresse mémoire, même si vous accédez aux mêmes données stockées.
Ce que vous faites, plus ou moins, c'est admettre au compilateur que vous traiterez parfois les données que vous avez comme une date, et à d'autres moments comme une adresse mémoire, et que vous prenez la responsabilité de vous rappeler quelle interprétation s'applique à quel moment dans le code.
Vous pourriez décider d'avoir une deuxième variable, connue sous le nom de tag (généralement un nombre entier) pour accompagner votre union pour garder une trace du type de données avec lesquelles vous travaillez actuellement, par exemple :
struct { balise int ; union { long long entier JulianDayNumer ; caractère signé* CustomerName ; } données; } valeur;
Vous pourriez décider que lorsque value.tag est fixé à 0, les données ne sont pas encore initialisées pour être utilisées, 1 signifie que vous stockez une date, 2 signifie qu'il s'agit d'une adresse mémoire et que tout le reste indique une erreur.
Eh bien, tu ferais mieux de ne laisser personne d'autre jouer avec ça value.tag réglage, ou votre programme pourrait finir par mal se comporter de façon spectaculaire.
Un exemple plus inquiétant pourrait être quelque chose comme ceci :
struct { balise int ; // 1 = hachage, 2 = union de pointeurs de fonction { unsigned char hash[16] ; // soit stocker une structure de hachage aléatoire { void* openfunc; // ou deux void* closefunc soigneusement validés ; // pointeurs de code à exécuter plus tard } valider ; } } valeur;
Maintenant, nous surchargeons le même bloc de mémoire afin que nous puissions parfois l'utiliser pour stocker un hachage de 16 octets, et parfois pour stocker deux pointeurs de 8 octets vers des fonctions que notre programme appellera plus tard.
Clairement, quand value.tag == 1, nous serions heureux de laisser notre logiciel stocker n'importe quelle chaîne de 16 octets dans la mémoire allouée à l'union, car les hachages sont pseudo-aléatoires, de sorte que toute collection d'octets est également probable.
Mais quand value.tag == 2, notre code devrait être extrêmement prudent pour ne pas permettre à l'utilisateur de fournir des adresses de fonction inconnues, non validées et non approuvées à exécuter ultérieurement.
Imaginez maintenant que vous puissiez soumettre une valeur à ce code alors que la balise était définie sur 1, afin qu'elle ne soit pas vérifiée et validée…
… mais plus tard, juste avant que le programme n'utilise réellement la valeur stockée, vous avez réussi à tromper le code pour qu'il passe la balise à 2.
Le code accepterait alors vos adresses de fonction non validées comme "sûres connues et déjà vérifiées" (même si elles ne l'étaient pas), et enverrait en toute confiance l'exécution du programme à un emplacement voyou en mémoire que vous auriez choisi sournoisement à l'avance.
Et c'est ce qui se passe dans un bogue de confusion de type, bien qu'en utilisant un exemple artificiel et simplifié,
La mémoire qui serait consommée en toute sécurité si elle était gérée d'une manière est transmise de manière malveillante au programme pour qu'il soit traité d'une manière alternative et non sécurisée.
Que faire?
Assurez-vous de disposer de la dernière version de Chrome ou Chromium.
Vous voulez Chrome 114.0.5735.106 ou version ultérieure sur Mac et Linux, et 114.0.5735.110 ou plus tard sur Windows.
Microsoft Edge, qui est basé sur Chromium, est également concerné par ce bogue.
Microsoft a jusqu'à présent [2023-06-06T16:25:00Z] noté que
Microsoft est au courant des récents exploits existant dans la nature. Nous travaillons activement à la publication d'un correctif de sécurité.
Edge est actuellement à la version 114.0.1823.37, donc tout numéroté plus tard que ça doit inclure les correctifs CVE-2023-3079 de Microsoft.
Pour vérifier votre version et forcer une mise à jour si vous n'en avez pas encore reçue :
- Google Chrome Menu à trois points (⋮) > d’aide > À propos de Chrome.
- Microsoft Edge. Paramètres et plus (…) > Aide et commentaires > À propos de MicrosoftEdge.
Vous êtes les bienvenus.
- Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
- PlatoAiStream. Intelligence des données Web3. Connaissance Amplifiée. Accéder ici.
- Frapper l'avenir avec Adryenn Ashley. Accéder ici.
- Achetez et vendez des actions de sociétés PRE-IPO avec PREIPO®. Accéder ici.
- La source: https://nakedsecurity.sophos.com/2023/06/06/chrome-zero-day-this-exploit-is-in-the-wild-so-check-your-version-now/