Tom's Hardware > Actualités > Logiciels, jeux vidéos > Systèmes d'exploitation > Une faille met en défaut l’UAC de Windows

Une faille met en défaut l’UAC de Windows

14:10 - vendredi 26 novembre 2010 par Yannick Guerrini - source: PrevX

Stack overflow

La pile d’exécution d’un programme est une structure de données qui sert à enregistrer dans un certain espace de mémoire les adresses où chaque fonction active doit retourner à la fin de son exécution, ainsi que les variables locales et les paramètres de la fonction.

On parle de stack overflow (ou dépassement de la pile d’exécution) lorsque l’accumulation des adresses de retour consomme tout l'espace alloué à la pile d'exécution. Une récursivité infinie (deux fonctions qui s’appellent mutuellement, ou une fonction qui s’appelle elle-même indéfiniment) est l’une des causes les plus fréquentes de dépassement de pile.

Si l’on en croit les informations publiées par le blog du site PrevX, une faille de sécurité touchant Windows XP, Vista et 7 (versions 32 et 64 bits) a récemment été découverte au sein du fichier Win32k.sys, c'est-à-dire dans le kernel du système.

Quand la pile déborde

Cette faille 0-day touchant l'API NtGdiEnableEUDC permettrait via un dépassement de pile (ou stack overflow), à un utilisateur avec restrictions d’élever ses privilèges (privilege escalation) et donc de transformer un simple utilisateur en administrateur.

Plus inquiétant, cette faille de sécurité touchant le cœur même du système d’exploitation permettrait d’outrepasser la sécurité de l’User Account Control (UAC), la fonctionnalité apparue avec Windows Vista et qui est justement chargée de vérifier l’identité de l’utilisateur lorsque des applications affichent un comportement susceptible d’altérer la sécurité du système. Un malware tirant parti de cette faille pourrait donc faire de gros dégâts…

Microsoft serait bien entendu déjà en train de travailler sur cette faille afin de la corriger le plus rapidement possible.

Commentaires

Lire plus

Commentaires

Ajouter un commentaire

_octobre 26/11/2010 14:30

Masquer

-1

C'était pas déjà connu ca ?

Yannick G 26/11/2010 14:33

Masquer

_octobre :
C'était pas déjà connu ca ?

C'est une "nouvelle" faille 0-day

darkbul 26/11/2010 15:10

Masquer

-2

Ouhais enfin C'est pas parcequ'elle est publié today qu'elle traine pas déjà sur les forums de hacker depuis quelques temps...

Yannick G 26/11/2010 15:54

Masquer

Citation :

Ouhais enfin C'est pas parcequ'elle est publié today qu'elle traine pas déjà sur les forums de hacker depuis quelques temps...

Donc elle n'était pas encore publiée, donc c'est une nouvelle.

CQFD :jap:

ultrabill 26/11/2010 16:02

Masquer

Citation :

Donc elle n'était pas encore publiée, donc c'est une nouvelle.

CQFD :jap:

si, dans les f0rum w4r3Z h4rdc0r3 undergroundz qu'on te dit

Yannick G 26/11/2010 16:06

Masquer

Citation :

si, dans les f0rum w4r3Z h4rdc0r3 undergroundz qu'on te dit

magellan 26/11/2010 16:20

Masquer

Reste à voir le P.O.F qui exploite la chose, à savoir si c'est si simple que cela d'exploiter la dite faille, ou bien si cela nécessite finalement quelque chose de quasiment impossible dans la pratique. Enfin bon, ce n'est pas la première faille dans l'UAC qui, en plus d'être perméable (comme pour tous les OS de toute façon, aucun n'étant parfait), s'avère bien trop souvent désactivé chez l'utilisateur final, car trop pénible avec ses sempiternelles alertes paranoïaques.

Yannick G 26/11/2010 16:33

Masquer

magellan :
Reste à voir le P.O.F qui exploite la chose, à savoir si c'est si simple que cela d'exploiter la dite faille, ou bien si cela nécessite finalement quelque chose de quasiment impossible dans la pratique. Enfin bon, ce n'est pas la première faille dans l'UAC qui, en plus d'être perméable (comme pour tous les OS de toute façon, aucun n'étant parfait), s'avère bien trop souvent désactivé chez l'utilisateur final, car trop pénible avec ses sempiternelles alertes paranoïaques.

http://www.youtube.com/watch?v=LKCKKYjm1Nw

Vidéo POC mise en ligne par Sophos.

magellan 26/11/2010 17:34

Masquer

-1

Merci, je regarderai ça ce soir (pas de youchose au boulot^^)

Sh4d3rZ_86 26/11/2010 19:06

Masquer

-1

magellan :
Merci, je regarderai ça ce soir (pas de youchose au boulot^^)

C'est chiant les pre-feux hein :whistle:

ultrabill 26/11/2010 19:30

Masquer

Citation :

C'est chiant les pre-feux hein :whistle:

Les proxy

zorro3364 26/11/2010 20:08

Masquer

le débordement (overflow) est sans aucun doute l'attaque la plus commune, parce que potentiellement tous les programmes peuvent être touchés. c'est d'ailleurs pour ça que des instructions comme strcpy ont été remplacées par strcpy_s en c/c++, entre autres.
quand c'est un débordement de pile c'est encore plus grave.
quand c'est un débordement de pile du kernel, là c'est le summum.
bon ici ça n'a quand même pas l'air d'être trop difficile à contrer (cf la fin de la vidéo).

batchy 28/11/2010 15:55

Masquer

Ahahah, Microsoft, quelles bandes d'incompétents ....

Quelqu'un peut m'expliquer le rapport entre un Noyau de système d'exploitation et la gestion des polices TrueType de caractères unicodes correspondant à des caractères réservés ?

Comme si ce genre de code avait besoin de toucher au matériel ...

pluies 29/11/2010 13:51

Masquer

zorro3364 :
le débordement (overflow) est sans aucun doute l'attaque la plus commune, parce que potentiellement tous les programmes peuvent être touchés. c'est d'ailleurs pour ça que des instructions comme strcpy ont été remplacées par strcpy_s en c/c++, entre autres.quand c'est un débordement de pile c'est encore plus grave.quand c'est un débordement de pile du kernel, là c'est le summum.bon ici ça n'a quand même pas l'air d'être trop difficile à contrer (cf la fin de la vidéo).

Mieux vaut utiliser strncpy que strcpy_s, c'est portable et standardisé. strcpy_s est une création MS non supportée par glibc.

[/pedantic]

Sh4d3rZ_86 29/11/2010 16:10

Masquer

strncpy je connaissais en revanche pas strcpy_s :non:

Mictateur 30/11/2010 02:53

Masquer

Depuis Visual Studio 2005 je crois, un bon paquet de fonctions C ont été remplacés par leurs petites soeurs sécurisées (avec "_s" en suffixe). C'est standardisé.

batchy 30/11/2010 15:07

Masquer

Citation :

Depuis Visual Studio 2005 je crois, un bon paquet de fonctions C ont été remplacés par leurs petites soeurs sécurisées (avec "_s" en suffixe). C'est standardisé.

C'est en cours de standardisation, nuance.
Mais tant qu'a faire, si on est en C++, autant utiliser std::string, et si on est en C ... ben y a forcement un framework qui va t'éviter d'implémenter ta gestion de chaîne à la main, ça ainsi que les listes chaînées et tableaux de hachages.

Et franchement, strcpy_s, c'est pas jolijoli. Si on veut remplacer du code qui utilise strncpy par strcpy_s, on doit remplacer ça :

Code :
strncpy(destination, source, taille);
destination[taille-1] = '\0';
// ou si tu code g0re, strncpy renvoie la destination...

par ça :

Code :
if (taille >= RSIZE_MAX) {
// strcpy_s ne marchera pas. faut utiliser autre chose.
strncpy(destination, source, taille)[taille-1] = '\0';
// ou tout autre méthode valable.
} else {
if (strcpy_s(destination, source, taille))
complain();
}

Si c'est pour compliquer la tâche des programmeurs qui vérifient tout les cas, je vois pas vraiment l'intérêt.

zorro3364 30/11/2010 19:33

Masquer

déjà je n'ai pas parlé de strncpy (qu'il suffit finalement de remplacer strncpy_s), mais uniquement de strcpy/strcpy_s, à titre d'exemple.
ensuite batchy, je vois pas bien le rapport avec un quelconque framework, car lui aussi peut comporter des failles type overflow, alors que quand tu code toi même et que ça merde au moins tu sais pourquoi.
de toute façon ce n'était pas le sens de mon propos, qui se bornait juste à montrer que ce type de faille (ou bug, c'est selon) est très répandue et qu'un simple warning généré à la compilation (à partir de 2008 pour vs il me semble) est non seulement utile, mais aussi la moindre des choses, parce que aucun dév n'est infaillible et qu'il ne doit pas être sans arret accusé de programmer avec ses pieds: "chez XXX c'est des nazes" est une phrase (généralement prononcée par des abrutis qui ne savent même pas de quoi on parle) qu'on retrouve trop souvent, en particulier quand XXX=crosoft.

Yannick G 30/11/2010 21:49

Masquer

Strncpy, strncpy, est ce que j'ai une tête de strncpy ?

[:topicalacon]

batchy 01/12/2010 19:39

Masquer

Citation :

Oui il peut en contenir, sauf que généralement il à été plus testé et attaqué que ton code et est donc plus sécurisé. Et certains utilisent des chaînes du style pascal avec la longueur à coté, et pas des chaînes terminées par un \0. et ça c'est pour du C, pour du C++ le problème est réglé depuis longtemps.

Citation :

de toute façon ce n'était pas le sens de mon propos, qui se bornait juste à montrer que ce type de faille (ou bug, c'est selon) est très répandue et qu'un simple warning généré à la compilation (à partir de 2008 pour vs il me semble) est non seulement utile, mais aussi la moindre des choses, parce que aucun dév n'est infaillible et qu'il ne doit pas être sans arret accusé de programmer avec ses pieds

Le simple fait d'utiliser strcpy_s ne garanti pas que le code n'a pas d'overflow, surtout comparé à strncpy ou strlcpy. et c'est pas en proposant une solution miracle qui n'empêche pas de réflechir que l'on va faire en sorte que la sécurité soit prise en compte dans le développement.

Citation :

: "chez XXX c'est des nazes" est une phrase (généralement prononcée par des abrutis qui ne savent même pas de quoi on parle) qu'on retrouve trop souvent, en particulier quand XXX=crosoft.

Sauf qu'en 2010 je rencontre encore des développeurs qui n'ont rien à foutre de la sécurité. "pas grave c'est seulement sur le réseau local", "y a rien de sensible la dedans" quand je montre une XSS béante.