Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par imikado

15PARTAGES

7  1 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de rt15
Membre confirmé https://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.
13  0 
Avatar de Angelsafrania
Membre confirmé https://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.
7  0 
Avatar de miky55
Membre averti https://www.developpez.com
Le 13/11/2014 à 22:02
Des failles vieilles de 20 ans il doit en exister des dizaines sur à peu près toutes les plateformes. Mais une faille commence réellement à exister quant elle a été découverte.
Est-il possible que cette faille n'ai été découverte (un exploit réalisé) que après tant d'année? Oui.

Cette faille exploitant une vulnérabilité vbscript il est plutôt facile de trouver des exploits s'il en existe: un bot qui parcourt le web et analyse tout code vbscript disponible devrait faire l'affaire...
7  1 
Avatar de imikado
Rédacteur https://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
4  1 
Avatar de MilWolf
Membre à l'essai https://www.developpez.com
Le 16/11/2014 à 1:50
PLus d'infos : http://www.exploit-db.com/exploits/35229/
2  0 
Avatar de RyzenOC
Inactif https://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.
0  0 
Avatar de RyzenOC
Inactif https://www.developpez.com
Le 13/11/2014 à 18:16
Ok merci pour ces explication
0  0 
Avatar de Médinoc
Expert éminent sénior https://www.developpez.com
Le 16/11/2014 à 16:15
Si j'ai bien compris, le bug était dans la fonction SafeArrayRedim() elle-même, et non dans VB.
Ce qui constitue un bug pour tout code utilisant la fonction, mais ne constitue une faille de sécurité proprement dite que pour des langages interprétés utilisant SAFEARRAY car il peut autoriser des accès arbitraires à la mémoire que le langage interprété ne permettrait pas normalement.
0  0 
Avatar de Pierre GIRARD
Expert éminent https://www.developpez.com
Le 20/11/2014 à 14:29
Citation Envoyé par Shuty Voir le message
Et uuuuune raison de plus de laissé son bon vieux XP de côté...
Même pas, si j'ai bien compris, c'est une faille liée d'une part à Visualbasic, d'autre part à IE. Comme je n'utilise pas IE, et encore moins Visualbasic, pas sur que mon XP craigne quoi que ce soit.
0  0 
Avatar de Médinoc
Expert éminent sénior https://www.developpez.com
Le 20/11/2014 à 14:45
Beaucoup d'applications sont "hôtes" d'un IE, et une page web peut contenir du code VBScript, dont l'activation pourrait bien reposer sur la même case à cocher que Javascript...
0  0