Discussion :

[Freem]

Pour commencer:
JeitEmgie et Gorgol: Bien vu, je n'avais pas abordé le problème de ces angles la.
Je ne connaît pas grand chose au hacking&cracking (j'ai juste assez pratiqué pour savoir que ce n'est pas à la portée de tout le monde, y compris la mienne) mais il est vrai qu'un accès libre à la mémoire est très dangereux.
Et pour ce qui est d'aborder le problème de manière plus générale que le simple vol d'un mot de passe, qui est simplement spectaculaire, je tenterai de garder ça en mémoire en lisant les articles prochainement.
Merci à vous deux donc.

Pour continuer:

Sais pas. Mais voici ce qu'ils disent :

http://www.theregister.co.uk/2011/07...lion_security/

Quand on cite un article, il faut le lire avec attention, sous peine de se tirer une balle dans le pied. Je m'explique...
Sur ton article, il y a quelques trucs très intéressants, juste avant:

D'abord le titre:

Major overhaul makes OS X Lion king of security
Windows 7, Ubuntu meet their match

Bon, c'est accrocheur, et c'est fait pour. Mais pas de trace de Linux ici, juste Ubuntu.

Le second truc:

It also prompted many to wonder why Apple engineers bothered to put it into the OS in the first place, or didn't properly implement it with the introduction of Snow Leopard. Windows Vista and Ubuntu, by contrast, added much more robust implementations of ASLR years earlier.

Encore une fois, ils parlent d'Ubuntu, pas de Linux.

Je fais cette nuance, parce que toutes les distributions ont des objectifs différents en terme de sécurité.
Je ne suis pas persuadé que Ubuntu soit la référence du genre dans les distros linux?
(bon, il semblerait qu'ils compilent les paquets avec des options de sécurité supplémentaires, après une rapide lecture de wikipedia. Seulement ils ne peuvent pas compiler la quantité non négligeable de logiciels propriétaires. Toujours selon wikipedia, la différence de sécurité est de 1% sur les systèmes 32b et 0.01% pour les 64b. Et l'usage du sudo est très controversé. Perso, je dirai qu'il implique que l'utilisateur a accès au compte root avec son propre mdp, ce qui me paraît dangereux... Un seul mdp pour les actions communes et les tâches sensible... Vu que la plupart des utilisateurs utilisent le même mdp pour pleins de trucs )

Pour la suite, je vais faire comme si "Ubuntu=Linux; Linux=Ubuntu;". Ne me fustigez pas, je n'apprécie pas non plus cette idée.

De toute manière, ils ne font que dire que Ubuntu était en avance sur Mac en terme de sécurité (même windows d'ailleurs) sur le seul point ou ils font la comparaison.
Jamais ils n'expliquent pourquoi ils ne le seraient plus!
Et après, ils disent que "Linux devrait prendre exemple dessus". Alors Ubuntu devrait régresser, logique!

Bon, j'ai conscience que ce post peut être pris pour troll, mais ce n'est pas le but, simplement mettre en exergue ce pour quoi cet article ne signifie pas grand chose, a part que mac OS s'est moqué de ses utilisateurs avec snow leopard (à bas niveau c'est la même en terme de sécu comme le montre cet article) et qu'ils ont corrigé la chose avec cette mouture.
Au passage, j'aurai pu remplacer chaque occurrence de Linux&Ubuntu par Windows. Puisque les 2 noms de systèmes apparaissent aux même moments, avec les mêmes explications.
Et on trolle rarement, je crois, pour dire que windows et linux sont dans le même panier

Je ne dis pas non plus que Mac est une passoire, juste que ces auteurs se tirent une balle dans le pied avec cet article. Les articles de gens qui prennent parti sans expliquer pourquoi, j'ai jamais apprécié.

[JeitEmgie]

De plus, l'info du jour est biaisée en se focalisant sur le vol de mot de passe de session ouverte, en sous-entendant que c'est le seul risque. Il faut comprendre que ce n'est qu'un simple POC des attaques via le FireWire, en démontrant la faisabilité d'une récupération de mots de passe, ce qui est toujours un bon moyen de marquer les esprits.
Je fais cependant remarquer qu'il s'agit plus largement d'une attaque qui permet un accès direct à la mémoire. Et donc tout est possible, comme une compromission quelconque du système ou l'installation d'un maliciel, d'une backdoor, etc.

Sauf que le communiqué de presse ne parle pas d'accès DMA en écriture de la machine cible seulement d'accès en lecture,
à ce stade, on manque d'informations pour pouvoir affirmer que l'on peut injecter quelque chose à partir du port Firewire.

Par contre leur produit permet de récupérer tous les mots de passe des disques Windows et Mac (Keychain) dans un cadre "forensic", et décrypte les partitions/fichiers encryptés par BitLocker et TrueCrypt, mais ils ne parlent pas de FileVault.

[Gorgol]

Sauf que le communiqué de presse ne parle pas d'accès DMA en écriture de la machine cible seulement d'accès en lecture,
à ce stade, on manque d'informations pour pouvoir affirmer que l'on peut injecter quelque chose à partir du port Firewire..

Bin non :

Le système d’interconnexion permettant de faire circuler des données à haute vitesse en temps réel FireWire autorise n’importe quel appareil à lire et à écrire sur tous les autres appareils connectés. Pour cela, il utilise un accès direct à la mémoire système.

J'suis pas spécialiste du DMA, mais je peux légitimement supposer qu'un accès direct sur le DMA permet les accès en écriture. Le propre du DMA est bien de s'abstreindre du CPU et donc de ses mécanismes de contrôle. A voir si un DMA est configurable sur ce point et quels OS vont à ce niveau de configuration, s'il existe.

mais ils ne parlent pas de FileVault.

Certes mais je serais agréablement surpris qu'Apple ait mis en place un mécanisme de protection sur le FileVault lors du verrouillage d'une session.
De plus on peut supposer des attaques indirectes pour récupérer les mots de passe Filevault (sans doute selon robustesse des mots de passe).

[JeitEmgie]

Bin non :



J'suis pas spécialiste du DMA, mais je peux légitimement supposer qu'un accès direct sur le DMA permet les accès en écriture. Le propre du DMA est bien de s'abstreindre du CPU et donc de ses mécanismes de contrôle. A voir si un DMA est configurable sur ce point et quels OS vont à ce niveau de configuration, s'il existe.

Je parle du communiqué de presse officiel de la société : le texte original en anglais ne fait pas allusion à la possibilité d'écriture à partir du périphérique.

Certes, techniquement le DMA permet l'écriture, la question est de savoir si elle peut être initiée par le périphérique/ le demandeur ou si c'est celui qui donne l'accès à sa propre mémoire qui doit faire la demande à l'autre : le périphérique peut demander à l'ordinateur de transférer le contenu de sa mémoire vers la mémoire du "périphérique" en DMA : çà c'est ce qui est utilisé pour découvrir le contenu de l'ordinateur visé, mais est-ce que le périphérique peut dire à l'ordinateur : je veux écrire dans ta mémoire à tel zone et que l'autre accepte ? J'ai comme un doute que cette séquence d'opérations ait été prévue dans la norme Firewire… mais cela reste à vérifier, tout comme la possibilité d'un hack qui permettrait de passer outre.

Certes mais je serais agréablement surpris qu'Apple ait mis en place un mécanisme de protection sur le FileVault lors du verrouillage d'une session.
De plus on peut supposer des attaques indirectes pour récupérer les mots de passe Filevault (sans doute selon robustesse des mots de passe).

Ils ont dans leur logiciel la récupération du Keychain donc récupérer le mot de passe s'il s'y trouve, ils peuvent le faire, mais ils ne parlent pas dans la description de leur produit de la décryption d'un fichier protégé par FileVault sans avoir le mot de passe.
Et ici on parle bien des autres fonctions de leur produit : les aspects "forensic", c'est-à-dire la récupération de données d'un disque auquel on a accès en laboratoire : pas de l'intrusion par Firewire sur une machine qui tourne. Ces fonctionnalités "forensic" nécessite du temps de calcul et leur logiciel utilise aussi le GPU pour y arriver dans des temps raisonnables… et pour le moment, ils n'annoncent pas qu'ils aient déjà implémenté le décryptage de FileVault.
(mais çà arrivera sûrement…)

[Gorgol]

Certes, techniquement le DMA permet l'écriture, la question est de savoir si elle peut être initiée par le périphérique/ le demandeur ou si c'est celui qui donne l'accès à sa propre mémoire qui doit faire la demande à l'autre : le périphérique peut demander à l'ordinateur de transférer le contenu de sa mémoire vers la mémoire du "périphérique" en DMA : çà c'est ce qui est utilisé pour découvrir le contenu de l'ordinateur visé, mais est-ce que le périphérique peut dire à l'ordinateur : je veux écrire dans ta mémoire à tel zone et que l'autre accepte ? J'ai comme un doute que cette séquence d'opérations ait été prévue dans la norme Firewire… mais cela reste à vérifier, tout comme la possibilité d'un hack qui permettrait de passer outre.

Certes il faut regarder les détails techniques concernant OHCI 1394. Mais à la base la norme permet les accès mémoire via le DMA en lecture et écriture. En théorie, je crois cependant qu'il existe des filtres pour ces accès sur les noeuds firewire.

Je vais être basique : s'il est possible de faire un dump complet de la mémoire (donc sans contrôle d'accès), pourquoi il ne serait pas possible de faire une écriture arbitraire quelconque ?

Bon, il est sans doute plus facile d'extraire des infos caractéristiques (exemple, authentifiants) que de corrompre une mémoire.

Ici :
http://www.google.fr/url?sa=t&source...6dpAzNTMEQGXLw

Je n'ai pas lu en détail, mais on parle d'altérer les routines de validation des mots de passe pour déverrouiller automatiquement une session (par contre le test ne semble pas très concluant sur une difficulté à localiser la routine MsvpPasswordValidate sur un Windows 7 SP1). Il faut bien pour cela faire une écriture en mémoire....
Ce n'est pas les études et outils qui manquent sur ce sujet, mais il se focalise sur des lectures mémoire. Pour l'instant...

[JeitEmgie]

Je vais être basique : s'il est possible de faire un dump complet de la mémoire (donc sans contrôle d'accès), pourquoi il ne serait pas possible de faire une écriture arbitraire quelconque ?

parce que l'écriture pourrait dépendre de qui demande à qui de faire quoi ou pour le dire autrement : de qui initie la conversation et si la conversation en écriture doit être initiée par le destinataire des données çà ne fonctionnerait pas.
(dans le cas de la lecture de la cible, c'est le cas : les données lues sont écrites dans la mémoire de celui qui initie la conversation…) - donc la possibilité dans un sens n'implique pas dans l'autre sens : il faut aller voir plus loin pour confirmer…

et ce faisant, j'ai trouvé la confirmation dans le cas du Firewire c'est possible : l'écriture quelconque en DMA peut se faire sans problème

Mais le problème est décrit depuis 2004 et affecte tous les OS qui supportent le Firewire,
donc l'impression première qu'on avait affaire à des gens avides de pub facile se confirme…

Il y a même des exemples de code sur Internet pour permettre de hacker Linux à partir d'un iPod…
(du Chaos Computer Club entre autres…)