FileVault et KeyChain inutile ... encore une faille

Einbert

Membre expert
Club iGen
24 Avril 2001
1 239
20
Bonjour,

Les paranos vont encore être servis :siffle: ... Cette faille n'est possible qu'avec les privilèges root et que localement ... Mais elle permet de voir les mots de passe de tous les utilisateurs de la machine, donc j'entends par là mot de passe lors du login, ainsi que celui utilisé pour FileVault et KeyChain. Le problème vient du fait que les passwd sont momentanément stockés sur la mémoire, puis swappé .

Pour vous en convaincre et si vous n'avez pas envie de clicker sur le lien ci-dessous, ouvrez le terminal, et taper la commande suivante (copie pase fonctionnera aussi :) ) ... et bien entendu, le compte root doit être activé :

sudo strings -8 /var/vm/swapfile0 |grep -A 4 -i longname



Je vous redirige donc à la source : http://www.securityfocus.com/archive/1/367116

Rien de vraiment critique, car ce n'est pas une attaque à distance et il faut être en root ... Mais quand même, ça manque quand même un peu de sérieux tout ça !!! :mouais:

++
 
  • J’aime
Réactions: [MGZ] Black Beru
Einbert a dit:
Rien de vraiment critique, car ce n'est pas une attaque à distance et il faut être en root ... Mais quand même, ça manque quand même un peu de sérieux tout ça !!! :mouais:
Des failles de sécurité, il y en a d'autres. Nécessairement. Elle n'ont pas encore été toutes trouvées. Ce qui va être intéressant, c'est le temps de réaction d'Apple et la manière de communiquer. ;)

À+
 
D'un autre côté, si on craint ce genre de "faille", mieux vaut bousiller son lecteur DVD/CD, parce que avec un CD d'install c'est plus simple de percer tous les pass vu qu'on peut les initialiser sans même avoir à entrer un pass :rolleyes:.
 
JediMac a dit:
D'un autre côté, si on craint ce genre de "faille", mieux vaut bousiller son lecteur DVD/CD, parce que avec un CD d'install c'est plus simple de percer tous les pass vu qu'on peut les initialiser sans même avoir à entrer un pass :rolleyes:.

En effet, ceci est valable pour l'authentification, mais pas pour FileVault, non ?

Et des failles, il y en aura toujours :rateau:

++
 
JediMac a dit:
D'un autre côté, si on craint ce genre de "faille", mieux vaut bousiller son lecteur DVD/CD, parce que avec un CD d'install c'est plus simple de percer tous les pass vu qu'on peut les initialiser sans même avoir à entrer un pass :rolleyes:.
Tu peux bloquer les chargement d'un CD de démarrage en mettant un mot de passe au niveau du Firmware. L'utilitaire est sur le CD/DVD système et tu peux le télécharger ici.

À+
 
  • J’aime
Réactions: TibomonG4
quand on connait la sécurité légendaire du mot de passe firmware, c'est encore du joli tout ça :D

La seule protection valable en cas d'accès physique à la machine semblait être filevault, si ça tombe, ça serait dommage. Allez, un peu de clarté, apple ! :)
 
La seule sécurité sans faille que je connaisse et que j'utilise s'appelle PGP.
Le problème de FileVault, ici, est celui de la localisation du stockage des clés.
Pour le reste, que le possesseur fondamental d'une machine dispose de droits extraordinaires, ne me choque pas tant que ça.
Le reste, ce qu'il fait de ces droits, est une question d'éthique.
:zen:
 
rezba a dit:
La seule sécurité sans faille que je connaisse et que j'utilise s'appelle PGP.
J'utilise aussi PGP, par contre, je ne pense pas qu'il existe acuellement de sécurité sans faille. Tout ce que l'homme peut faire, l'homme peut le défaire. A long terme, faudra voir ce que nous apportera la cryptographie quantique, qui a l'air assez prometteuse, vu que se basant sur les fameuses lois d'incertitude de Heisenberg... Pour le moment, ça reste surtout académique, mais cela risque d'arriver assez rapidement.

rezba a dit:
Le reste, ce qu'il fait de ces droits, est une question d'éthique.
:zen:

En effet :) .

++
 
Einbert a dit:
et bien entendu, le compte root doit être activé :

sudo strings -8 /var/vm/swapfile0 |grep -A 4 -i longname

Rien de vraiment critique, car ce n'est pas une attaque à distance et il faut être en root ... Mais quand même, ça manque quand même un peu de sérieux tout ça !!! :mouais:

++

Je ne vois nulle part ici une commande nécessitant d'activer root, désolé. Sudo permet aux utilisateurs d'exécuter des commandes en tant que d'autres utilisateurs même lorsque ces derniers sont inactifs.

Par défaut sous Mac OS X, seuls les utilisateurs ayant le statut d'administrateur peuvent utiliser la commande sudo, s'ils ne précisent rien, ils demandent à exécuter la commande comme l'utilisateur root, et ça fonctionne même sans activer root.

Je n'ai jamais activé root sur ma machine (jamais eu besoin, entre sudo et Pseudo) et je viens de tester, la commande fonctionne sans problèmes.

Alors, Apple avait promis une réaction rapide et des informations claires pour les futures failles, on va voir ce que ça donne :)

(ok, c'est une faille locale, et accessible seulement à certains utilisateurs)
 
PAS D'ACCORD

Je viens de faire la commande. Sans le mot de passe administrateur, rien n'est possible.
Donc déjà, si vous donnez pas votre mot de passe à 15 personnes, y a pas de faille.

Concernant la vulnérabilité de open firmware, la possibilité de faire ce que l'on veut en single user, etc. il existe des parades.

sécuriser l'accès en Single User par un mot de passe indépendant du compte administrateur ou root : http://users.ez-net.com/~jasonb/secureit.html (ça tourne très bien sur mac os 10.3.4)

Utiliser Open Firmware pour empêcher quiconque de pouvoir démarrer depuis un CD ou un autre disque dur (99,999% des humains ne sauront pas comment contourner cette limitation)

Désactiver l'ouverture automatique de cessions afin que votre mac affiche une demande de mot de passe au démarrage.

Utiliser plusieurs mots de passe (1 pour votre compte admin, 1 pour le compte root (si activé), 1 pour vos trousseaux additionnels, 1 pour vos accès aux forums, etc.)

Utiliser des mots de passe mélangeant lettres et chiffres, minuscules et majuscules.

Activer FileVault

Avec tout cela, le risque de voir une personne se servir de votre machine en local ou à distance à votre insue est quasi nul (mais pas nul et ne le sera jamais).

En plus, retenir tout ces mots de passe exercera votre mémoire (qu'on utilise plus assez à cause de ces ordinateurs qui retiennent tout pour nous).

A tous les grognons, salut ! :zen:
 
Comme cela a été dit, cette manipulation n'est possible que sous root. Je ne vois donc pas l'intérêt de se casser la tête pour récupérer les mots de passe, or on a accès sur tous les comptes même quand on n'a pas les mots de passe. En revanche ça peut être gênant pour le FileVault...
 
labon a dit:
PAS D'ACCORD

Je viens de faire la commande. Sans le mot de passe administrateur, rien n'est possible.
Donc déjà, si vous donnez pas votre mot de passe à 15 personnes, y a pas de faille.

Tss, tss, j'ai bien dit que c'était réservé aux admins, il faut tout lire.

Cependant, un admin va du coup pouvoir connaître les mots de passe des autres utilisateurs de la machine. Oh bien sûr, il peut changer les mots de passe de n'importe qui, mais question discrétion, on a fait mieux.

De plus, il y a faille, je peux très bien faire un sudo sans connître ton mot de passe admin, il suffit que j'ai accès à un shell sur ta machine et que j'exécute un sudo moins de 5 min après toi depuis ton compte et hop, pas de mot de passe (par défaut le délai est de 5 minutes, ça se change, man sudo, man sudoers et man visudo pour les détails).

Donc, faille il y a, même si elle est moins dramatique que celle des protocoles.
 
NightWalker a dit:
Comme cela a été dit, cette manipulation n'est possible que sous root. Je ne vois donc pas l'intérêt de se casser la tête pour récupérer les mots de passe, or on a accès sur tous les comptes même quand on n'a pas les mots de passe. En revanche ça peut être gênant pour le FileVault...

Non cette manip ne nécessite qu'un compte admin et donc pas besoin d'activer root. Même si les admins ont des pouvoirs importants, ils ne sont pas root. La possibilité de récupérer tous les mdp est une faille, même pour un admin.

Dans l'esprit Mac OS X, les admins sont un peu les concierges de l'immeuble, ils assurent l'entretien, ajoutent des éléments etc mais ils ne sont pas supposés aller dans les appartements (même s'ils le peuvent en terminal). Bref, ils ne sont surtout pas supposés connaître les mots de passe des autres.

Mes 0,2 cents d'euros.
 
chez moi le grep ne ramène rien...
Mon mac est protégé ? :cool: :D
 
lolopb a dit:
Non cette manip ne nécessite qu'un compte admin et donc pas besoin d'activer root. Même si les admins ont des pouvoirs importants, ils ne sont pas root. La possibilité de récupérer tous les mdp est une faille, même pour un admin.

Dans l'esprit Mac OS X, les admins sont un peu les concierges de l'immeuble, ils assurent l'entretien, ajoutent des éléments etc mais ils ne sont pas supposés aller dans les appartements (même s'ils le peuvent en terminal). Bref, ils ne sont surtout pas supposés connaître les mots de passe des autres.

Mes 0,2 cents d'euros.

Merdouille, tu as raison, je viens de l'essayer ça marche avec admin sans être root. Pas cool ça. Pas besoin d'être root, mais il faut quand même être, au moins, admin. Sinon, ça ne marche pas, heureusement.
 
Ce n'est pas synonyme: même avec le compte Root désactivé (ce qui est le cas par défaut), tout utilisateur avec des privilèges d'administration peut exécuter des instructions comme si il était Root, si il a les privilèges ad hoc pour lancer le Terminal, en utilisant la commande "sudo". Plusieurs solutions: 1) fixer les droits Unix de l'application Terminal pour que seul un administrateur précis puisse le lancer; 2) ou bien laisser le Terminal accessible mais éditer le fichier "sudoers" pour supprimer le droit d'agir "au nom de quelqu'un d'autre (ex:Root)" (aka: "sudo") aux administrateurs [sauf un].

Info pour "Labon": il y a faille. Un administrateur qcq ne doit pas être tout puissant: il doit pouvoir créer des comptes, organiser la machine, mais pas pomper les documents des autres! Ainsi dans le cas qui me concerne, les profs peuvent être administrateurs (pour créer des comptes élèves ou de projets), ils n'ont pas à aller pomper n'importe quoi n'importe où.

Quoiqu'il en soit, que Root puisse voir les fichiers de tous est une chose (sauf utilisation de FileVault), qu'il connaisse leur mots de passe en est une autre! (ceci pour NightWalker & autres) D'abord parce que cela permet de faire sauter la protection FileVault (gênant?!) mais aussi parce que cela me permet "d'agir au nom de -", de me loguer "comme si j'étais -" & par exemple d'insulter Pierre en prétendant être Paul.
Ces "pouvoirs extra-ordinaires" sont à mon sens "choquants".
 
En résumé, on tombe à nouveau dans un classic que l'on retrouve très souvent : on utilise un algorithme cryptogaphique, mais l'intégration au produit est faite de telle façon, qu'en fin de compte, on se retrouve avec une faille. C'est parti d'une bonne intention, mais réalisé par des non-experts en sécurité, resp. en cryptographie. Ceci s'est aussi vu avec l'intégration de AES pour crypter les fichiers zip (en moins d'une semaine, il y avait déjà une faille trouvée qui rendait la sécurité inutile), ou avec l'élaboration du WEP, et bien d'autres produits. Imaginez que PGP ait le même problème que FileVault :p ... Le problème devrait vite être résolu à mon avis.

++
 
BLM a dit:
Info pour "Labon": il y a faille. Un administrateur qcq ne doit pas être tout puissant: il doit pouvoir créer des comptes, organiser la machine, mais pas pomper les documents des autres! Ainsi dans le cas qui me concerne, les profs peuvent être administrateurs (pour créer des comptes élèves ou de projets), ils n'ont pas à aller pomper n'importe quoi n'importe où.

Quoiqu'il en soit, que Root puisse voir les fichiers de tous est une chose (sauf utilisation de FileVault), qu'il connaisse leur mots de passe en est une autre! (ceci pour NightWalker & autres) D'abord parce que cela permet de faire sauter la protection FileVault (gênant?!) mais aussi parce que cela me permet "d'agir au nom de -", de me loguer "comme si j'étais -" & par exemple d'insulter Pierre en prétendant être Paul.
Ces "pouvoirs extra-ordinaires" sont à mon sens "choquants".
Je ne vous suis pas. Mais alors, pas du tout. L'administrateur root d'une machine a tous les droits sur les technologies système et parentes contenues dans une machine.
Si les utilisateurs veulent se protéger d'un manquement d'éthique et de déontologie du root, ils utilisent une autre technologie de cryptage et de sécurisation des données que celle qui est intégrée à l'OS.
Mais cela fait belle lurette qu'un root peut connaitre les mots de passe liés aux droits de lecture et d'écriture gérés par l'OS (à quoi sert donc nidump, hein ?!) , et c'est tout à fait sain, et acceptable.
Les droits d'un root sont total sur l'OS. Mais un super-administrateur de machine, s'il a techniquement tous ces droits, ne peut les utiliser que dans des cadres légaux précis. En clair, s'il regarde votre courrier, vos documents, etc... c'est du viol de correspondance privée, ou du viol d'archives privées, etc... C'est condamnable aux yeux de la loi.
Si vous voulez protéger vos données d'un super-administrateur indélicat, sans avoir à vous lancez dans un long procès, équipez-vous en sécurité de tierce-parties.
Mais arretez de vous faire des illusions sur le fonctionnement d'un unix. Vous préférez une plate-forme windows, et que redmond puisse accéder à distance à vos machines ? :D

:zen:
 
  • J’aime
Réactions: nato kino
rezba a dit:
Si vous voulez protéger vos données d'un super-administrateur indélicat, sans avoir à vous lancez dans un long procès, équipez-vous en sécurité de tierce-parties.

Je n'utilise pas FileVault, mais une fois FileVault activée, même root ne devrait pouvoir accéder au contenu du dossier Home, non ? Pour rappel, le problème de cette faille, c'est que les passwd sont stockés en mémoire et en clair, mais pas effacés par la suite, donc ils seront tout simplement swappés (toujours en clair...).

++
 
Je n'utilise pas FileVault non plus. Le problème est de stocker les passwords dans KeyChains. Tout ce qui est dans le keychain est accessible en root, ou par malevolence, ou par n'importe quel nidump.
Est-ce que l'on peut utiliser FileVault en se passant du KeyChain ?