Pwn2Own 2015 : les hackers en démonstration de force

Version imprimable

Voir 40 message(s) de cette discussion en une page

21/03/2015, 09h30
Michael Guilloux

Pwn2Own 2015 : les hackers en démonstration de force

Pwn2Own 2015 : les hackers en démonstration de force
Comment Firefox, Chrome, IE, Safari, Windows, Adobe Flash et Reader sont-ils tombés?

L'édition 2015 de Pwn2Own, le concours annuel des hackers sponsorisé par le Zero Day Initiative(ZDI) de HP et le Project Zero de Google a connu son déroulement les 18 et 19 mars 2015. Comme à l'accoutumée, des pirates de bonne éthique se sont rendus à Vancover, au Canada lors de la conférence CanSecWest sur la sécurité informatique, pour défier les navigateurs et logiciels inclus basés sur les systèmes Windows et Mac OS X.

Pour cette huitième édition, 7 équipes ont eu 30 minutes pour exploiter leurs cibles et expliquer leurs méthodes dans une série de 12 compétitions en tout. Les cibles visées étaient Chrome, IE 11, Firefox, Adobe Reader et Flash pour Windows et Safari pour Mac OS X.

Le premier jour s'est soldé par des réussites pour 4 participants alors que du côté des éditeurs de logiciels, ils étaient à la fois émerveillés par le spectacle, mais surpris de constater comment sont vulnérables leurs produits.

Les premiers à entrer en lice n'ont pas manqué d'empocher 60 000 $ pour commencer. Les hackers ont exploité un bug de débordement de mémoire dans Flash pour l'exécution de code à distance. Ils ont aussi exécuté une attaque par élévation de privilège au niveau SYSTEM de Windows. Pour y parvenir, les pirates ont exploité une faille TrueType Font (TTF) dans le noyau de l'OS. Ce qui leur a valu une récompense supplémentaire de 25 000$.

L'homme du jour 1, c'est probablement lui, Nicolas Joly. Chercheur en sécurité, il a combiné une vulnérabilité d'exécution de code à distance use-after-free (UAF) et une vulnérabilité d'évasion de sandbox dans Flash d'Adobe pour exécuter du code arbitraire. Une vulnérabilité UAF est un type de faille de corruption de la mémoire qui peut être exploitée par des pirates pour exécuter du code arbitraire. Cela se réfère spécifiquement à la tentative d'accéder à la mémoire après qu'elle ait été libérée.

Dans sa deuxième tentative, Nicolas a pris contrôle de la mémoire dans Adobe Reader via un débordement de mémoire tampon, d'abord pour une fuite d'information et ensuite pour l'exécution de code à distance. Il affirme avoir écrit la dernière partie de son exploit dans l'avion en se rendant à la conférence. Pour ses deux tentatives, il a obtenu une recette journalière de 90 000 $.

Les équipes Tencent PCMgr et KeenTeam ont suivi pour une belle démonstration. Elles sont parvenues à prendre contrôle de la mémoire dans Adobe Reader avec un débordement d'entier pour exécuter du code au niveau SYSTEM dans Windows via un autre bug TTF dans le noyau. Après avoir ouvert le concours, les équipes Tencent PCMgr et KeenTeam complètent leur gain à 140 000$ avec leur deuxième passage. Elles ont obtenu 30 000$ pour l'exploit et 25 000$ pour l'exécution de code.

Sa vitesse d'exécution restera à jamais gravée dans la mémoire de Mozilla. Mariusz Mlynski, un autre hacker ciblant Firefox, a fait tomber le navigateur dans un temps record de 0,542 secondes. Il a exploité une vulnérabilité cross-origin dans Firefox pour attaquer une faille dans Windows. La faille lui a ensuite permis d'augmenter ses privilèges et exécuter du code à distance. Il s'est vu attribuer une prime de 55 000 $ pour sa prouesse.

360Vulcan Team, les nouveaux de cette année, n'ont pas non plus été moins convaincants. Ils ont pu casser IE 11 64 bits de Microsoft avec une vulnérabilité de mémoire non initialisée. La faille a permis l'exécution de code « medium integrity » pour une prime de 32 500$.

À la fin du jour 1, ce sont au total 317 500 $ qui ont été distribués. Flash, Adobe Reader et Windows ont enregistré le plus de bugs - soit 3 chacun - tandis que Firefox et IE11 suivent avec 2 bugs chacun.

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

Le jour 2, les hostilités se sont poursuivies avec le même enthousiasme. Deux participants ont réussi avec succès leurs tentatives visant IE, Chrome, Firefox et Safari.

Le dernier jour de la compétition a débuté avec l'entrée en scène d'un hacker de pseudo ilxu1a. Il a fait tomber Firefox en exploitant une vulnérabilité de lecture/écriture. La faille lui a permis de lancer l'exécution de code et obtenir en retour une prime de 15 000$ pour le bug. Dans une seconde tentative, il n'a malheureusement pas eu assez de temps avant que son code visant Google Chrome soit fonctionnel.

Celui qui a été le plus impressionnant durant toute la compétition reste Junghoon Lee (lokihardt), hacker en cavalier seul. Il a explosé le record de prime de toute l'histoire de Pwn20wn avec un total de 225 000$ pour trois cibles différentes.

Sa première tentative a fait tomber Internet Explorer 11 (64 bits) avec une vulnérabilité time-of-check to time-of-use (TOCTOU) lui donnant des privilèges de lecture/écriture. Il a contourné tous les mécanismes de défense en utilisant une évasion sandbox par injection de JavaScript. Cela a abouti à l'exécution de code « medium integrity ».

Dans une seconde tentative, les versions stables et bêta de Google Chrome se sont également soumises à l'attaque de lokihardt. Il a utilisé une race condition de dépassement de tampon dans Chrome, puis une fuite d'informations et une race condition dans deux pilotes du noyau de Windows pour obtenir l'accès à SYSTEM.

Après IE 11 et Chrome, lokihardt attaque le navigateur d'Apple. Il a en effet fait tomber Safari en utilisant d'abord une vulnérabilité UAF dans un pointeur de pile non initialisé dans le navigateur avant de contourner le sandbox pour l'exécution de code.

À la fin de la compétition, Windows a enregistré 5 bugs devant IE 11 qui en totalise 4. Firefox, Adobe Reader et Flash étaient au coude-à-coude avec 3 bugs chacun, tandis que Safari suivait avec un total de 2. Du côté de Google Chrome, on n'enregistre qu'une seule vulnérabilité.

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

Sources: Pwn2Own 2015 Day 1 Results, Pwn2Own 2015 Day 2 Results

Et vous ?

:fleche: Quelles sont vos impressions ?
21/03/2015, 10h29
Paul TOTH

ça dure deux jours le Pwn2Own ? Vue les sommes en jeu, si j'étais hacker je garderais sous le coude des failles pour les sortir en 0,542 secondes et empocher le pactole...on peut donc supposer qu'il en existe encore un certain nombre déjà connues, ou tout au moins que celles-ci l'étaient depuis un moment. L'autre hypothèse serait qu'il ne faut que 2 jours pour trouver un bug critique...j'ai des doutes.
21/03/2015, 10h57
Michael Guilloux

Citation:

Envoyé par Paul TOTH

si j'étais hacker je garderais sous le coude des failles pour les sortir en 0,542 secondes et empocher le pactole...L'autre hypothèse serait qu'il ne faut que 2 jours pour trouver un bug critique...j'ai des doutes.

Exactement! Avant le concours, les hackers recherchent des failles de sécurité en secret pour sortir le grand jeu pendant la compétition.
22/03/2015, 07h13
Deuzz

Citation:

Envoyé par Michael Guilloux

Exactement! Avant le concours, les hackers recherchent des failles de sécurité en secret pour sortir le grand jeu pendant la compétition.

Je vais peut- être dire une grosse ânerie mais si quelqu'un peut éclairer ma lanterne.
Si je comprends bien tous les programmes peuvent potentiellement bugger dans des circonstances particulières. Le hacker cherche à reproduire ces circonstances dans l'espoir de prendre le contrôle du programme. Certains programmes résistent à tel ou tel problème,alors que d'autres cèdent,et inversement.
J'ai bon ? :bug:
Toutefois je serais bien curieux de savoir si quelqu'un est en mesure de m'expliquer ce genre de phrase :

Citation:

Envoyé par Michael Guilloux

Sa première tentative a fait tomber Internet Explorer 11 (64 bits) avec une vulnérabilité time-of-check to time-of-use (TOCTOU) lui donnant des privilèges de lecture/écriture. Il a contourné tous les mécanismes de défense en utilisant une évasion sandbox par injection de JavaScript. Cela a abouti à l'exécution de code « medium integrity ».

Citation:

Envoyé par Escapetiger

Tout ceci est pathétique :aie:

Euh... moi aussi j'ai envie de jouer.:roll:
C'est pas thétique mais presque... :aie:

Citation:

Thétique :
Étymologie: Du latin theticus (« propre à former, à créer »).
thétique /te.tik/ masculin et féminin identiques
(Philosophie) Qui se rapporte à une thèse.
Chez Fichte, le terme thétique qualifie le jugement par lequel une chose est seulement posée comme identique à elle-même.
(Par extension) Existentiel.8O
Conscience thétique; celle qui pose son être comme existant.
22/03/2015, 15h25
psychadelic

Citation:

Envoyé par Deuzz

Je vais peut- être dire une grosse ânerie mais si quelqu'un peut éclairer ma lanterne.
Si je comprends bien tous les programmes peuvent potentiellement bugger dans des circonstances particulières. Le hacker cherche à reproduire ces circonstances dans l'espoir de prendre le contrôle du programme. Certains programmes résistent à tel ou tel problème,alors que d'autres cèdent,et inversement.
J'ai bon ? :bug:

On va reformuler :

Primo, évite d'utiliser le terme de "programme" c'est flou.
Et secondo, une faille de sécurité dans un logiciel : ce n'est pas un Bugg.

Dans un environnement partagé, il n'existe pas de sécurité absolue et un programme malveillant spécialement conçu finira toujours par prendre le contrôle sur n'importe quel système, et les logiciels offrent pour eux de multiples opportunités.

FlashPlayer étant largement en tête devant Java. mais l'ensemble des navigateurs Internet sont aussi des proies de choix.

Ce que le Hacker recherche, ce n'est pas la prise de contrôle du Logiciel (IE11 par exemple) dans d'utiliser les failles de celui-ci pour prendre la main du système tout entier (Windows ici dans l'exemple).

Après, ce qu'il en fait peut être n'importe quoi: récupérer des informations privées (ce que fait la NSA), utiliser la machine hôte pour faire du Spam, etc... il n'y a pas de limites, sinon celle de son imagination.

Expliquer l'info technique de Michael Guilloux, c'est entrer dans des connaissances techniques sur l'architecture des systèmes.
Les sandbox sont, à l'image des bacs à sable, des aires de jeux limitées, et les programmes qui évoluent y sont sous la surveillance de l'OS, avec des permissions restreintes sur leur pouvoirs.

Réussir l'évasion d'un bac à sable est un véritable exploit, et une fois en dehors, le programme du Hacker peut quasiment faire ce qu'il veut.

"meduim intégrity" signifie tout simplement que l'intégrité du système est menacé; il peut par exemple reprogrammer certaines fonctions du système en les détournant définitivement.
23/03/2015, 10h51
xurei

Les exploits sont-ils disponibles publiquement ou sont-ils conservés farouchement sous clef ? (ce qui serait logique, mais on ne sait jamais...)
23/03/2015, 22h08
Stéphane le calme

Mozilla déploie un second correctif pour colmater une faille découverte sur Firefox lors du concours Pwn2Own

Mozilla déploie un second correctif pour colmater une faille découverte sur Firefox
lors du concours Pwn2Own

Durant l’édition 2015 du concours de hacking Pwn2Own, les défenses de sécurité du navigateur web de Mozilla ont été défaites à deux reprises. La première faille a permis au chercheur en sécurité Mariusz Mlynski d’obtenir une élévation de privilèges exploitant une vulnérabilité dans le traitement du format de fichier SVG (image vectorielle) lors d'une navigation. Un exploit qui permet d’exécuter des scripts arbitraires. Il a reçu 55 000 dollars (environ 50 350 euros) pour sa découverte.

Dans l’avis de sécurité, cette faille critique qui a désormais été identifié par CVE-2015-0818 a reçu un correctif dans la version précédente de Firefox (la version 36.0.4 ainsi que dans ESR – Extended Support Release – 31.5.2 et SeaMonkey 2.33.1). Mozilla a avancé qu’un correctif incomplet a été livré pour Firefox 36.0.3 et Firefox ESR 31.5.2.

La seconde, qui a été exploitée par le chercheur en sécurité ilxua1, est relative à l'implémentation de la vérification des limites d'un tableau typé et sa gestion dans la compilation JavaScript à la volée. Elle a permis au chercheur de lire et d’écrire dans la mémoire et d’exécuter un code arbitraire en local. Il a reçu 15 000 dollars (environ 14 000 euros) pour sa découverte. La faille critique a été répertoriée comme étant CVE-2015-0817 et a déjà été corrigée dans Firefox 36.0.3, Firefox ESR 31.5.2 ainsi que SeaMonkey 2.33.1. Le chercheur s’est également essayé à la compromission de Google Chrome, Internet Explorer et Safari sans succès.

Google pour sa part a diffusé une mise à jour Chrome 41.0.2272.101 pour Windows, OS X et Linux. Les notes de version ne sont que partielles et, bien que le lien n’ait pas été fait entre cette miise à jour et le concours Pwn2Own, nous notons que cette diffusion a été faite en marge de l’évènement. Il faut dire que durant l’évènement, Google Chrome n’a enregistré qu’une seule vulnérabilité, contre deux pour Safari, trois pour Mozilla Firefox, Adobe Reader et Flash, 4 pour Internet Explorer et 5 pour Windows.

En parlant des produits Microsoft, ils devraient selon toute vraisemblance, obtenir des correctifs durant le traditionnel Patch Tuesday de Redmond.

Source : blog Mozilla, blog Mozilla, blog Chrome
23/03/2015, 22h56
Matthieu Vergne

Donc si j'ai bien compris, Firefox et Google, on patch dès qu'on sait, alors que Microsoft, on patch quand on a un trou dans le planning ?

Après on s'étonne que MS a besoin de plus de 90j pour faire ses corrections. {'^_^}
23/03/2015, 23h08
marsupial

Citation:

Envoyé par xurei

Les exploits sont-ils disponibles publiquement ou sont-ils conservés farouchement sous clef ? (ce qui serait logique, mais on ne sait jamais...)

Jamais de la vie : "La première règle du Fight Club est qu'un ne parle pas du Fight Club"

Même et surtout les hackers non éthiques gardent jalousement leurs secrets. C'est pour cette raison que le Russe dont la tête est mise à prix 3 millions de dollars, ce n'est pas pour la couper mais bien pour extraire tout ce qu'il peut savoir faire afin de s'en servir par les services, dixit Snowden au CeBit.

L'ancienne Black Hat qui a conçu et réalise Qubes OS est partie du principe de base qu'un jour ou l'autre n'importe quel système sera hacké. C'est la raison pour laquelle on emploie le terme de sureté et non de sécurité.

Une précision en passant, les "meilleurs" exploits ne sont pas connus, justement. le hack de Sony n'est par exemple pas de l'art, mais du cochon. La NSA et son accés aux DD serait plus dans la catégorie artistique car très peu le savait avant que ce soit révélé par la Presse, même dans notre milieu. Seuls ceux qui font de la veille, s'en sont rendu compte. Et encore, pas tous.

A la lecture de l'article, 20+ ans de négligence laissent un chantier immense et un travail de romains à effectuer qui commencent par changer les mentalités, autant côté utilisateur que donneur d'ordres et concepteurs.
24/03/2015, 05h58
TiranusKBX

Citation:

Envoyé par Matthieu Vergne

Donc si j'ai bien compris, Firefox et Google, on patch dès qu'on sait, alors que Microsoft, on patch quand on a un trou dans le planning ?

Après on s'étonne que MS a besoin de plus de 90j pour faire ses corrections. {'^_^}

Pour IE et Windows µsoft sort les correctifs dans sont programme patch tuesday et vus le nombre de MAJ
tu pense bien qu'ils ne vont pas communiquer en permanence dessus
24/03/2015, 08h04
Uther

Citation:

Envoyé par psychadelic

Et secondo, une faille de sécurité dans un logiciel : ce n'est pas un Bugg.

J'aimerai bien une explication là, Parce que si tous les bug n'entraînement pas des failles. Les failles de sécurité découlent normalement soit d'une erreur de programmation, soit de conception.

Citation:

Envoyé par psychadelic

Ce que le Hacker recherche, ce n'est pas la prise de contrôle du Logiciel (IE11 par exemple) dans d'utiliser les failles de celui-ci pour prendre la main du système tout entier (Windows ici dans l'exemple).

Prendre le controle du système complet est l'exploit idéal, mais prendre le contrôle seulement du navigateur est déjà une faille très grave qui permet notamment de faire du fishing ou du vol de données, et ça donne droit a une partie de la récompense.
25/03/2015, 01h08
psychadelic

Citation:

Envoyé par Uther

J'aimerai bien une explication là, Parce que si tous les bug n'entraînement pas des failles. Les failles de sécurité découlent normalement soit d'une erreur de programmation, soit de conception.

8O .. faudrait savoir, soit tu parles de Bug, soit tu parles d'erreur de conception.
Ou alors pour toi c'est la même chose ???

En tous cas, cette confusion ferait de la peine à Grace Hopper. Bien sur, le Harvard Mark II avait été conçu sans moustiquaires –directes- parce que les bâtiments abritant cet ordinateur en étaient -en principe- pourvus.

Aujourd'hui, on dit que le problème se situe entre la chaise et le clavier, mais à cette époque il s’agissait plutôt de tout ce qui se trouvait entre les portes, les fenêtres, et une machine de plusieurs mètres cube.

Sinon, et pour en revenir sur l’autre confusion (celle de confondre une faille de sécurité avec un bug): on va prendre un exemple classique, celle de l’injection SQL sur les sites internet.

Grosso modo, elle consiste à utiliser le passage des arguments d'un simple lien [qui déterminera les infos à afficher par la suite].
La page calculée en retour utilisant directement ces arguments pour établir une requête SQL.

Comme cette opération en passe forcément par l’envoi d’une URL sur le serveur, les hackers « Noirs » utilisent cette voie pour envoyer leurs requêtes SQL qui soutirent toutes les infos possibles des bases disponibles sur les serveurs, etc…

Je ne vais pas rentrer dans les détails, car le Hacking par injection SQL est largement expliqué sur la toile.

De base, ce type de site fonctionne parfaitement, et prévoir d’avance qu’un hacker puisse détourner l’utilisation des liens-url pour piller une base de donnée, ce n’est ni un problème de programmation, ni de conception, c'est une problèmatique à part, qui s'appelle la sécurité.

Dans ce cas la, autant reprocher aux fabricants de parapluies de n’avoir toujours rien corrigé à leur produits, surtout après la fameuse histoire du parapluie Bulgare !!!
Il y a d'autres exemples, pour les fabricants de portes et de serrures, sans oublier le vase de Soisson qui aurait du être incassable ! (en évitant ainsi de traumatiser des générations d'écoliers)

Et puis, comme je l’ai souligné dans un autre post, dans le développement logiciel, la part de budget alloué aux problèmes de sécurité sont plutôt rare ; et c’est déjà suffisamment compliqué en soi de réaliser un soft de A à Z en temps et heure. On trouvera toujours un petit malin capable de détourner une fonctionnalité au détriment de son usage initial.

La sécurité, c’est un jeu du chat et de la souris, ça prends beaucoup de temps [et d'argent], pour un résultat impalpable, sinon devenir des pertes, parfois considérables.
25/03/2015, 03h24
Uther

Bah on a juste pas la même définition du "bug". Pour moi un bug est une erreur que son origine soit la réalisation, ou la conception du code. D'ailleurs avec tout le respect que je doit à Grace Hopper, ce n'est pas elle qui a inventé le mot bug qui servait déjà à désigner des erreurs de conception de systèmes mécaniques avant l'avènement de l'informatique. Elle s'est juste contenté de relever dans ses notes l'ironie du fait qu'elle avait eu à faire un "bug" qui c'était avéré être un véritable insecte.

Après le problème de sécurité ne se limite pas en effet aux une erreurs de programmations. Par exemple un mauvais paramétrage d'un réseau, d'un système, ou d'application sensibles peut ouvrir une brèche de sécurité. Mais ce n'est pas du tout ce qui était recherché dans ce concours. Dans ce concours on cherchait bien à exploiter des bugs de l'application, la plupart étant des erreurs de programmation des plus courantes (overflow, use after free, race condition, ...)

Pour moi l'injection SQL est justement un bon exemple d'une faille de sécurité qui est un bug. En fait, ce n'est qu'un cas particulièrement dangereux de la sécurisation des données en entrées, au même titre que l'on t'apprends dès que tu débute à refuser les lettres quand tu attends une valeur numérique. Dès qu'on réalise un programme dont l'usage n'est pas interne, il faut s'assurer que son programme ne fait pas n'importe quoi s'il il reçoit une valeur imprévue. Pour moi c'est clairement un bug car même s'il n'y avait pas risque de vol, ou d'altération des données, ça peut provoquer un plantage.
25/03/2015, 09h42
ZenZiTone

Citation:

Envoyé par Uther

Bah on a juste pas la même définition du "bug". Pour moi un bug est une erreur que son origine soit la réalisation, ou la conception du code. D'ailleurs avec tout le respect que je doit à Grace Hopper, ce n'est pas elle qui a inventé le mot bug qui servait déjà à désigner des erreurs de conception de systèmes mécaniques avant l'avènement de l'informatique. Elle s'est juste contenté de relever dans ses notes l'ironie du fait qu'elle avait eu à faire un "bug" qui c'était avéré être un véritable insecte.

Après le problème de sécurité ne se limite pas en effet aux une erreurs de programmations. Par exemple un mauvais paramétrage d'un réseau, d'un système, ou d'application sensibles peut ouvrir une brèche de sécurité. Mais ce n'est pas du tout ce qui était recherché dans ce concours. Dans ce concours on cherchait bien à exploiter des bugs de l'application, la plupart étant des erreurs de programmation des plus courantes (overflow, use after free, race condition, ...)

Pour moi l'injection SQL est justement un bon exemple d'une faille de sécurité qui est un bug. En fait, ce n'est qu'un cas particulièrement dangereux de la sécurisation des données en entrées, au même titre que l'on t'apprends dès que tu débute à refuser les lettres quand tu attends une valeur numérique. Dès qu'on réalise un programme dont l'usage n'est pas interne, il faut s'assurer que son programme ne fait pas n'importe quoi s'il il reçoit une valeur imprévue. Pour moi c'est clairement un bug car même s'il n'y avait pas risque de vol, ou d'altération des données, ça peut provoquer un plantage.

Donc pour résumé, un bug serait un évènement non désiré (que se soit sur un application ou sur un système)?

Alors que la version de psychadelic pourrait se résumer à un événement qui ne permet pas de répondre au besoin métier du système?
25/03/2015, 09h53
Paul TOTH

j'ai un exemple à vous soumettre, est-ce un "bug" ou pas ?

sur un site web d'une SSII spécialiste du développement Web, il y avait un produit (c'est un cas réel) permettant de partager des documents entre utilisateurs...une fois authentifié, on pouvait voir son profile et son mot de passe qui apparaissait en clair (ça c'est un bug ou pas déjà ?)

la page du profile s'appelait profile.php avec un paramètre id=XXX où XXX était l'id unique de la base....http://ssii.pro/profile.php?id=456

et donc je me suis amusé à taper http://ssii.pro/profile.php?id=455...ce qui m'a permis de consulter la fiche d'un autre utilisateur, connaître ses coordonnées et ... son mot de passe :D

alors bug ou problème de sécurité ? :D

Selon toi, psychadelic, venir taper un 5 à la place d'un 6 dans l'URL c'est de l'ordre du moustique et de la fenêtre ou de la responsabilité du programmeur ? ;)
25/03/2015, 10h50
Uther

Citation:

Envoyé par Paul TOTH

sur un site web d'une SSII spécialiste du développement Web, il y avait un produit (c'est un cas réel) permettant de partager des documents entre utilisateurs...une fois authentifié, on pouvait voir son profile et son mot de passe qui apparaissait en clair (ça c'est un bug ou pas déjà ?)

Le mot bug n'a pas de définition très précise mais pour moi, ce n'est pas un bug, ni même une faille en soi car ce n'est exploitable qu'en conjonction avec une autre vulnérabilité, mais c'est clairement un problème de sécurité qui devrait être évitée.

Citation:

Envoyé par Paul TOTH

et donc je me suis amusé à taper http://ssii.pro/profile.php?id=455...ce qui m'a permis de consulter la fiche d'un autre utilisateur, connaître ses coordonnées et ... son mot de passe :D

alors bug ou problème de sécurité ? :D

C'est un bug qui entraine une faille de sécurité selon moi.
De ce que je comprend du point de vue de psychadelic, pour lui ça ne rentrerait pas dans le domaine du bug.
25/03/2015, 11h27
ZenZiTone

Citation:

Envoyé par Uther

C'est un bug qui entraine une faille de sécurité selon moi.
De ce que je comprend du point de vue de psychadelic, pour lui ça ne rentrerait pas dans le domaine du bug.

Sur ce point, je rejoindrais psychadelic. Car même si cela déclenche une grosse faille de sécurité, la logique métier est respectée. En revanche, si, par exemple, on reçoit une chaine de caractère au lieu d'un entier, le traitement ne peut pas se faire. La logique métier étant "perturbée" le terme bug serait, à mon avis, plus approprié. Dans les deux cas un problème de conception peut être la cause, mais les impactes sont différents. A mon sens, un bu est donc une événement empêchant la logique métier de fonctionner correctement (indépendamment de la sécurité).
25/03/2015, 11h53
marsupial

Conseil de base pour la conception :

- encadrez vos déclarations de variables
- encadrez vos entrées de boucles sur la condition de sortie de ladite boucle

Votre donneur d'ordre râle car cela prend du temps et remet en cause le fonctionnement ?
Demandez lui de signer pour un chiffre compris entre NULL et l'infini en cas de pertes de données allant de sensibles à la mort du client.

"Un client mort n'a jamais été un bon business."
25/03/2015, 12h53
psychadelic

L’histoire de l’insecte scotché par Grace Hooper sur le rapport d’incident de la marine Américaine est bien à l’origine du mot Bug.

Tout cela se passe dans un cadre discipliné et rigide, comme dans toutes les armées du monde, et l’arrivée de ce petit « grain de sel » réussissant la prouesse de foutre le bordel dans une machinerie coutant plusieurs millions et utilisée uniquement par des « gradés ».

Bref cette histoire à amusé tout le monde, et à rapidement passé les frontières de sa caserne.

En langage populaire, le mot Bug peut s’employer de bien des façons, l’une des plus courante est de dire que tel individu à buggé , etc…
On retrouve aussi ce mot (bugger) dans l’argot anglais.

Pour ce qui est de la programmation, le concept de bug est principalement lié au disfonctionnement d’un programme.
Par exemple on tape sur le bouton « suivant » et le programme affiche la page précédente, qui résulterait d’un « if » mal écrit, et qu’on fit par débusquer grâce à un debugger symbolique (Inspecteur de code sous les navigateurs).

Au final, un programme, un logiciel, est considéré comme « sans bug » à partir du moment ou il répond exactement à son cahier des charges.

En TMA, la limite est la, et tout ce qui est hors cahiers des charges ne peut pas être considéré comme un bug.

La sécurité absolue n’existe pas, et il est impossible de la formaliser concrètement dans un cahier des charges.

Par exemple avoir un cahier des charges qui stipule que le programme doit résister à une attaque de type injection SQL n’est pas acceptable pour un cahier des charges.

En revanche, il peut indiquer que toutes les requêtes entrantes doivent utiliser un système de validation et de contrôle avant d’être exécutées est souhaitable [et doit être décris en détail], mais ne constitue en rien une sécurité absolue,

Le cas du http://ssii.pro/profile.php?id=455 est un grand classique, dans un niveau de sécurité simple le programme se contente de vérifier que l’ID est bien de type numérique.

Augmenter la sécurité pour ce type de détournement peut signifier de gros changements dans l’écriture du programme, voir de son l’architecture logique et s’avérer couteux en temps de développements, etc…
25/03/2015, 13h15
psychadelic

Citation:

Envoyé par ZenZiTone

Donc pour résumer, un bug serait un évènement non désiré (que se soit sur un application ou sur un système)?

Alors que la version de psychadelic pourrait se résumer à un événement qui ne permet pas de répondre au besoin métier du système?

Ce n'est pas du tout ce que j'ai écrit, et utiliser concept d'évenement n'apporte rien sinon à semer la confusion, mais c'est sans doute l'objectif de ton post ?

Voir 40 message(s) de cette discussion en une page