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

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

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

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

@ rudeboyfred :
Je le crois aussi.

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.

installer Flash c'est rapide...

@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)

"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).

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...

@ 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.

@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.

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

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

"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.

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 :-)

@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.

@relaxx,

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

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

Sincèrement je n'ai pas compris!

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

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

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

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 ?

Daito dit :

"- 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. "

Tandis que relaxx dit donc tout le contraire sur ce même chapître :

"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)."

relaxxx tend à dire que le code Apple non ouvert vers l'extérieur est parfois plus fragile parceque non vérifié régulièrement par une communauté élargie de spécialistes, à l'opposé d'éléments libres intégrés dans OSX qui en sont à leur nième mouture corrigée, et donc fiabilisés.

Je pense que ce second intervenant est plus dans le vrai.

Qu'en pensent d'autres experts des alentours ???

@ Stanley Lubrik :

Tout comme "des gens" pensent que le MD5 est incrakable* parce qu'on ne peut pas lire à haute voie la chaine donnée, "des gens" pensent qu'un code fermé est plus sécurisé.

Cependant, c'est le produit (le code compilé) que l'on va mettre à l'épreuve.
Alors je rejoint totalement relaxx sur la question.

Un développeur change sa boite, personne ne lira son code (Pourquoi réparer ce qui n'est pas cassé ?). Pire, il y a peu de chance que son remplaçant fasse un audit et fasse l'effort de conserver la méthode de développement.
Deux problèmes qui s'accumulent dans les codes propriétaires.

Et comme ce qui compte est le code compilé, les techniques de hacks sont les mêmes...

* Cet exemple est très intéressant. Mathématiquement, on s'en fou que le calcul du hash soit connu ou non, on cherche des collisions pour le craquer... MD5 n'est pas une méthode solide pour crypter des mots de passe (mais très bien pour hasher, c'est son seul but d'ailleurs).