Windows : Microsoft corrige une faille vieille de 19 ans
Touchant toutes les versions de l'OS depuis Windows 95

Le , par imikado, Rédacteur
Microsoft corrigeait hier, via son traditionnel Pacth Tuesday, une faille permettait de prendre le contrôle de l'ordinateur en navigant avec Internet Explorer.

Le patch de sécurité corrige la faille pour les versions :
  • Windows server : 2003, 2008 et 2012
  • Grand public : Windows Vista, 7, 8 et 8.1
  • Tablette : Windows RT


Windows XP, n’étant plus supporté par Microsoft depuis avril dernier, n’a pas droit à un correctif, tout comme les autres versions non supportées de l’OS de Microsoft.

L'équipe de chercheurs d'IBM à l'origine de la découverte ont estimé que celle-ci était exploitable depuis Windows 95, soit 19 ans.

La faille repose sur un bogue dans VBScript, un sous-ensemble de Visual Basic utilisé en tant que langage de script d'usage général, qui avait été introduit dans Internet Explorer 3.0.

Aucune preuve de son exploitation par des pirates n’a été relevée. Selon les chercheurs d’IBM l’utilisation de la faille par un pirate serait assez difficile.

Selon Microsoft, le patch de sécurité a déjà été appliqué si vous utilisez les mises à jour automatiques (Windows Update).

Source: IBM

Que pensez-vous de ces failles très anciennes découvertes seulement aujourd'hui ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Angelsafrania Angelsafrania - Membre averti http://www.developpez.com
le 13/11/2014 à 11:30
Comme quoi les veilles failles sont possible dans n'importe quel type de développement (ouvert ou fermé) (cf la faille shell bash présente depuis 22 ans).
C'est bien qu'on les voit, c'est mieux qu'on arrive à les détecter plus tôt avant la publication du produit.

Le problème avec les veilles faille c'est que beaucoup de plateforme doivent être patcher et ca prend beaucoup de temps, donc ca laisse pas mal de possibilité pour les pirates de se faire plaisir.
Avatar de Guikingone Guikingone - Membre éprouvé http://www.developpez.com
le 13/11/2014 à 11:37
Mieux vaut tard que jamais, enfin, entre tard et 19 ans ...
Avatar de jmebula jmebula - Nouveau Candidat au Club http://www.developpez.com
le 13/11/2014 à 11:44
Une pareille faille découverte après toutes ces années! ça risquerait de remettre en cause la confiance en MS! mais d'autre part il est dit "vaut mieux tard que jamais"
Avatar de imikado imikado - Rédacteur http://www.developpez.com
le 13/11/2014 à 12:24
Citation Envoyé par jmebula  Voir le message
Une pareille faille découverte après toutes ces années! ça risquerait de remettre en cause la confiance en MS! mais d'autre part il est dit "vaut mieux tard que jamais"

J'en suis pas sur, pour rappel, il y a quatre ans on avait trouvé une faille vieille de 17 ans...
Une faille de sécurité présente dans les codes de Windows depuis 1993 rend vulnérables toutes les versions 32 bits du système d’exploitation depuis Windows NT 3.1 jusqu’à Windows 7.

http://www.tomshardware.fr/articles/...ws,1-4270.html
Avatar de Shuty Shuty - Membre éprouvé http://www.developpez.com
le 13/11/2014 à 13:31
Et uuuuune raison de plus de laissé son bon vieux XP de côté...
Avatar de koyosama koyosama - Membre actif http://www.developpez.com
le 13/11/2014 à 13:46
Citation Envoyé par Shuty  Voir le message
Et uuuuune raison de plus de laissé son bon vieux XP de côté...

Qui te dit qu'ils ont vraiment corriger une faille
Avatar de sazearte sazearte - Membre expert http://www.developpez.com
le 13/11/2014 à 15:46
Se sujet m’intéresse
"La faille repose sur un bogue dans VBScript, un sous-ensemble de Visual Basic utilisé en tant que langage de script d'usage général, qui avait été introduit dans Internet Explorer 3.0."

Quelqu'un a un site pour en apprendre plus ?

Développant encore des activeX pour IE6, j'utilise pas mal en VBScript et j'aurais aimée en connaitre d'avantage sur ce bogue.
Avatar de herve4 herve4 - Membre habitué http://www.developpez.com
le 13/11/2014 à 16:19
et c'est ainsi que la NSA a pu introduire un backdoor pour contrôler tout les OS de Windows ...

Tant pis je vais passer au DOS 3.1
Avatar de rt15 rt15 - Membre confirmé http://www.developpez.com
le 13/11/2014 à 17:23
Citation Envoyé par sazearte  Voir le message
Développant encore des activeX pour IE6, j'utilise pas mal en VBScript et j'aurais aimée en connaitre d'avantage sur ce bogue.

Des explications sont données dans la source de l'article.

En deux mots le souci a lieu lors de l'appel de "redim preserve" qui permet de redimenssionner un tableau dynamique en VB. Ce redimenssionement est géré par la fonction SafeArrayRedim de OleAut32.dll.

Lors de l'appel à cette fonction, la taille demandée est settée dans le tableau rapidement.
Mais dans le cas d'une erreur bien précise (Un échec d'allocation visiblement), la taille du tableau n'est pas settée à la taille initiale.

Donc si "on error resume next" est utilisé (Cela permet de continuer l'exécution du VB même si une erreur se produit), on se retrouve avec un tableau dynamique qui pense avoir une taille différente de sa taille réelle.
Et donc on peut taper en mémoire un peu n'importe où.

Par exemple on créé un tableau de 5 éléments.
On fait un redim preserve à 2000 éléments qui foire avec la bonne erreur.
Et on se retrouve avec un tableau de 2000 éléments, avec les 5 permiers qui sont des vrais éléments et les 1995 qui correspondent à la mémoire qui se trouve après le tableau de 5. On peut donc lire et écrire hors du tableau physique : "array(1900) = 2" sans que VB ne remarque de problème, car il demande la taille au tableau qui lui répond 2000.

Un problème dans l'exploitation de cette faille est que les éléments font 16 octets : 4 octets pour le type de variant, un padding de 4 octets, 8 octetd de données (Par exemple un double ou un currency). Et logiquement, en VB, on ne peut vraiment modifier directement que les 8 octets de données, donc on a un peu accès à la mémoire par petit morceau.
Mais bon il semble qu'il y ait des solutions pour avoir plus de contrôle notamment si on arrive à avoir deux tableaux décalés de 8 octets ce qui donne plus ou moins accès à tout.

Quand on a un accès arbitraire à la mémoire, on fait un peu ce qu'on veut en théorie. L'exécution de code à distance devient enviseagable. Dans le cas du VB, il y a proposition de remplacer VT_DISPATCH ou VT_UKNOWN par une autre implémentation.
Avatar de sazearte sazearte - Membre expert http://www.developpez.com
le 13/11/2014 à 18:16
Ok merci pour ces explication
Offres d'emploi IT
Webmaster
Shiva Communication - Ile de France - Clichy
Ingénieur d'Etudes et développement JAVA J2EE (H/F)
Atos Technology Services - Ile de France - Bezons
Ingénieur informatique h/f
Atos - Rhône Alpes - Grenoble (38000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil