Fermer le menu

CanSecWest : Mac et PC vont souffrir

Christophe Laporte | | 11:27 |  27

Comme chaque année se tiendra lors de la conférence CanSecWest à Vancouver les 9, 10 et 11 mars, qui réunit des experts en sécurité venus du monde entier. Comme à l'accoutumée, cet événement accueillera le concours Pwn2Own 2011, durant lequel les participants seront invités à prendre le contrôle d'un Mac et PC en exploitant une faille d'un navigateur web.

Les ordinateurs "mis à disposition" des hackers seront équipés de la dernière version de Mac OS X ou de Windows 7. Ils fonctionneront en 64 bits et comprendront les butineurs suivants : Internet Explorer (sur PC uniquement), Safari, Firefox et Chrome.


Charlie Miller a remporté le concours sur Mac trois années de suite (image : ggee)

Chaque participant aura trente minutes pour mettre en place son attaque. Les gagnants repartiront notamment avec 15 000 $ et l'ordinateur hacké, à savoir soit un MacBook Air 13", soit un Sony Vaio soit un Alienware m11x. Lors des précédentes éditions, Safari a toujours été hacké (lire : Concours CanSecWest : l'iPhone et le Mac ont été piratés).

Un concours similaire sera organisé avec des smartphones. Les téléphones concernés sont un Dell Venue Pro sous Windows Phone 7, un iPhone 4, un Blackberry Torch 9800 sous Blackberry 6 OS et un Nexus sous Android.

De son côté, Google va un peu plus loin. Le géant de l'internet offrira jusqu'à 20 000 $ à quiconque trouvera deux failles dans Chrome dès le premier jour (une pour passer le bac à sable et l'autre pour pirater le navigateur en lui même) ainsi que son fameux netbook le CR-48 (lire : Google sort Chrome 9 et défie les hackers).

Catégorie : 

27 Commentaires

avatar nooty 04/02/2011 - 11:37

Et en mettant son 1er avis, qu'est-ce qu'on gagne?

avatar nooty 04/02/2011 - 11:37

Et en plus je mets les 2 1ers...

avatar daito 04/02/2011 - 11:55

Rappelons quand même que :

- Le hack n'est pas trouvé le jour même mais il est préparé des jours/semaines/mois avant. Sa réalisation le jour du concours ne prenant alors que quelques minutes.

- Comme ça en passant, cette conférence est sponsorisée entre autres par Microsoft, Google.....je prends le parie que c'est encore un produit Apple qui va soit disant tomber le premier cette année. Ils ne vont quand même pas froisser les gens qui financent le concours.

- Il me semble qu'à chaque fois la faille n'était pas dans du code Apple mais du code de composantes tierces OpenSource richement présentes dans Mac OS X. Là encore le concours est en quelque sorte biaisé car il est plus simple et plus rapide de trouver des failles dans du code OpenSource par définition ouvert à tous (donc aussi pour l'analyse de faille) que dans du code propriétaire.

- il est évident que les hackers se concentrent sur le Mac, ils veulent sûrement repartir avec un MacBook Air et pas avec un Sony Vaio...lol

avatar rudeboyfred 04/02/2011 - 12:32

ton 4eme argument est certainement le plus valable...lol

avatar USB09 04/02/2011 - 12:35

@ rudeboyfred :
Je le crois aussi.

avatar Sébastien Moreau 04/02/2011 - 13:53

Ce qui est intéressant c'est que le Mac mis à disposition pour un hack est un MacBook Air donc exit Flash et c'est innombrables failles.
Idem pour Java.

Ca enlève déjà une grosse quantité de faille possible.

Les précédentes cessions n'était pas fairplay sur ce point là Windows n'étant pas distribué avec Flash alors que le Mac de l'époque oui.

avatar enka 04/02/2011 - 14:05

installer Flash c'est rapide...

avatar oomu 04/02/2011 - 14:10

@daito

votre 3eme argument est un classique de microsoft. hors l'obscure code de windows depuis la nuit de temps ne l'a jamais protégé.

Unix, que ça soit dans sa forme fermée ou ouverte, a été régulièrement le plus sécurisé des systèmes, cela vient de sa conception modulaire, du travail sérieux derrière d'entité comme IBM ou (ex)SUN et de l'expérience de nombreux industriels et académiciens sur son amélioration.

-
le 1er argument est vrai.
Le "concours de hack" présenté en grande pompe à la conférence n'est que du spectacle. Bah, moi si on fait rêver les petits geeks avec de l'informatique dans les journaux, ça me va. Faudrait mettre + de sex pour faire rêver les kékés aussi.

-
Le 2eme argument est du Complot Alien franc-maçonnique. ptet ben quoui, ptet ben qunon.

-
Le 4eme argument :

c'est le problème avec le spectacle.

Si on pirate un windows ou un android, borf. Tout le monde continue à dormir, tout au plus des gens déjà convaincu vont se taper sur le dos.

Mais si on pirate un Mac ? hiiiiii, alors là c'est la gloire, le titre, etc !

Bref le Spectacle artificialise.

-
Lisons les failles de sécurité du CERT et autre organismes :

1: c'est aride
2: c'est passionnant (mais si !)
3: faut des heures de lectures de commentaires, de débats, du code de référence, etc pour bien saisir l'importance et l'enjeu de la faille de sécurité
4: pendant tout ce temps on ne pollue pas en voiture, on ne dérange personne, on ne fait pas le zouave dans la rue. Que des avantages donc :)

-
De mémoire, j'ai pas été convaincu par les sessions précédentes. Safari tombe via des pièges (phishing). ce qui est génant oui

mais je n'ai pas eu de "t'y allumes le mac, t'y est sur le net ? moi y en a te pirater, ayé !".

Bref, pas une prise de contrôle à distance en brisant SSH ou AFP ou la pile tcp/ip ou que sais je ? bref du cool !

-
(attention, je ne nie pas l'importance d'être solide contre toute forme de phishing)

avatar oomu 04/02/2011 - 14:17

"Il me semble qu'à chaque fois la faille n'était pas dans du code Apple mais du code de composantes tierces OpenSource richement présentes dans Mac Os X"

-
le code "zopainsource" de os X est le code de Os X est le code d'Apple.

une grande part titanesque de Os X est un noyau original, basé MACH, avec une personnalité bsd basée freebsd. NeXT puis Apple l'a écrit, y a contribué, l'a modifié, etc. C'est Apple.

Bien sur du travail provient de At&t à l'origine, des gens de Freebsd, du MIT, de Berkley et même du monde Linux (un paquet de personnes, parfois les même)

mais vous n'arriverez pas à séparer Apple du tas. Apple est impliqué dans le développement de son unix, point barre.

-
Le code de Apache, GNU , etc. Apple est aux même loges que tout le monde : ils peuvent faire de l'audit, ils peuvent y contribuer (et ils l'ont fait sur gnu cc), ils sont responsables de ce qu'ils fournissent aux acheteurs.

-
CUPS (qui gère les imprimantes et impressions) est du zopainsource sous licence libre (gpl), c'est pourtant bel et bien du code 100% Apple, (l'auteur de cups ayant vendu à Apple le code et embauché par Apple).

Donc, un bug zopainsource dedans est un bug Apple.

-
tout bug dans leur implémentation d'autoconfiguration (zeroconfig/bonjour) est du bug apple, peu importe si c'est zopainsource

idem avec Directorykit qui dérive lourdement de OpenLdap, mais hein,c 'est un projet Apple !

-
bref, Apple écrit du code opensource, hé bé vi.

-
LA où j'admets d'absoudre Apple, c'est quand il s'agit de logiciels externe à Apple soit propriétaire mais communément installé sur Mac (je pense à un truc commençant par F comme un nom de super héros) ou de logiciels opensources populaires rajouté par divers trucs (y en a).

Soit des hacks liés à une tromperie de l'utilisateur (lui faire faire désactiver les sécurités en le trompant).

avatar oomu 04/02/2011 - 14:22

tiens d'ailleurs, sur java on aurait pu débattre. Est ce que apple était responsable de java ?

- non, java était écrit par sun, de manière jalouse, malgré sa licence libre. Apple n'y faisait rien.
- oui, Apple n'a pas fait que jeter java dans osx, mais lui a adjoint une intégration "carbon" et divers trucs.
- non, cela ne concernait qu'un habillage autour de java
- oui, ça a un impact et c'était un frein pour maintenir à jour Java dans os X , au même rythme que sun/oracle.

bref...

avatar curly bear 04/02/2011 - 14:24

@ thibotus01 :
Si le Mac est un vrai gruyère, pas d'inquiétude alors. Il n'y a pas de trous dans le Gruyère.
Les trous, c'est dans l'Emmenthal.

avatar daito 04/02/2011 - 14:45

@oomu,

Non mon propos n'était pas de dire qu'Apple ne participe pas dans différents projets OpenSource, webkit, OPenCl, Bonjour étants les plus connus et d'ailleurs lancés par la pomme.

Mon propos était de dire que d'une part les hakers privilégient justement le code Open Source ouvert pour trouver des failles (ce qui est plus facile en comparaison avec du code propriétaire). Et ça qu'Apple participe ou pas à ce code.

Ensuite oui il y a aussi du code OpenSource où Apple n'y est pas. Par exemple, en 2008 dans ce concours CanSecWest c'était une faille dans la bibliothèque PCRE qui a été utilisée pour hacker le Mac.

avatar lukasmars 04/02/2011 - 15:23

Pour être précis, il faut aussi souligner que Apple étaient les seuls avoir une version aussi obsolète de ladite bibliothèque...

avatar Ben Assur 04/02/2011 - 15:38

Ah, que la vie est belle!
Voilà des échanges courtois et instructifs comme on souhaiterait en voir régulièrement sur d'autres sujets.
Un GRAND MERCI

avatar daito 04/02/2011 - 15:57

"Pour être précis, il faut aussi souligner que Apple étaient les seuls avoir une version aussi obsolète de ladite bibliothèque."

Euuhh je ne sais plus trop quelle version était utilisée par Apple mais le dernière contenait aussi la faille exploitée lors du concours, ce qui donc ne change rien au problème.

avatar vonjos 04/02/2011 - 18:36

Le Charlie Miller, il est malin, il découvre 4 failles, n'en révèle que 2, et l'année suivante, il revient tout frais tout flamme en disant "vous avez vu ce que je viens de trouver".

Bof, pirater un vaio : faut vraiment qu'il pleuve dehors et qu'il repasse Derik à la tv pour ne rien avoir à faire d'autre :-)

avatar relaxx 04/02/2011 - 20:37

@daito
"Mon propos était de dire que d'une part les hakers privilégient justement le code Open Source ouvert pour trouver des failles (ce qui est plus facile en comparaison avec du code propriétaire)."

C'est faux.
Car l'ouverture du code permet précisément de faciliter et donc d'augmenter les découvertes de bugs. Puis l'organisation des projets open source (a fortiori des projets libres) facilite la publication et l'utilisation de ces découvertes de bug pour opérer les corrections de code nécessaire. Une fois sortie du régime béta uncode ouvert est très résistant, très.
Le code fermée n'est pas plus exempte de bug (ni pire en première sortie) mais sa nature fermée (et son organisation interne) limite le volume de découverte de bug puis leur publication et donc leur correction. S'y rajoute des limitations inhérentes aux organisations à code fermé (jusqu'aux cas radicaux où il n'y a pas de possibilité de navigation simple et facile dans l'intégralité du code pour les employés codeurs, le comble de la bêtise pour produire un code de qualité). Il sont perpétuellement au niveau d'un code alpha.

Cette croyance irrationnelle dans la sécurité accrue des codes fermés me rappelle mon chat se sentant à l'abri quand il se cache alors que sa queue dépasse toujours : confusion entre ne pas être vu et ne pas voir (les enfants protégés des monstres parce que sous leur couverture, toussa ...).

Enfin il faut lire le détail des "comptabilisation de failles" : on peut laisser trainer une faille sans exploitation possible quand on sait que ce pan de code est en cours de réécriture. Il faut regarder de près les classification de bug, les exploits effectifs ont quasiment toujours lieux sur code fermé. En gros tout est politique de maj ensuite.

avatar daito 04/02/2011 - 20:55

@relaxx,

euhh c'est que je dis.....

avatar relaxx 04/02/2011 - 21:02

non car nous ne somme pas sur des codes en début de carrière dans des os.

avatar daito 04/02/2011 - 23:14

Sincèrement je n'ai pas compris!

avatar diegue 05/02/2011 - 00:33

Les entreprises, les administrations travaillant peu, voire pas, sur Mac, pourquoi perdre son temps à développer des virus, etc . Ce ne sont pas les infos des bobos qui rapportent, excepté le marché de l'art qui utilise assez le Mac. Et puis quand on a un mac on se donne une bonne raison de ne pas le protéger pour éviter les lenteurs d'ouvertures et de fermetures que l'on connaît sous Windows

avatar Ali Baba 05/02/2011 - 01:52

@ Arnaud de Brescia :
Par définition, un marronnier, c'est de retour chaque année...

avatar Ali Baba 05/02/2011 - 02:05

@ relaxx :
"l'ouverture du code permet de faciliter la découverte de bugs" : c'était bien ce que disait daito, non ?

avatar relaxx 05/02/2011 - 10:10

Oui, j'ai été peu clair dans ma dernière réponse.

Ce n'est pas la nature ouverte du code qui le rend plus facile à violer c'est sa fraicheur. Un code récent, et donc peu corrigé, sera (pour du code ouvert) plus "fragile". Là on est sur du code os/interfaces de base, donc pas ou peu de code récent (non soumis à un bon cycle de correction). Donc il est faux de dire que le code ouvert est plus "facile" à violer : il a déjà subis des cycles de corrections il devient donc robuste et y trouver les bugs restants (il en reste toujours) devient assez complexe, plus complexe que sur du code fermé (qui se comporte comme un code perpétuellement en alpha).

ai_je été plus clair ?

Pages

Connexion utilisateur