À part les petits noyaux embarqués qui n'ont pas vocation à assurer une politique de sécurité multi-utilisateurs, aucun OS sérieux ne va transmettre les données d'un processus à un autre. Au pire, selon l'implémentation de malloc() et la taille demandée, un processus pourra retomber sur ses propres données.
Parmi les risques plus sérieux, il y a le swap et la fonction d'hibernation sur disque des ordinateurs portables.
Et toutes les parades paraissent un peu futiles quand on sait qu'on peut débrancher des barrettes de RAM et relire leur contenu pendant 10 minutes, simplement en les refroidissant:
Au moins Windows XP. Je pense qu'il en etait de meme sous Windows 2000 et Windows 98. Je n'ai pas fait de test sous Windows NT. Pour Vista je ne sais pas ce qu'il en est.
Il ne s'agit pas de transmettre des donnees entre processus, mais du fait que si on efface pas explicitement la memoire avant de la liberer, les donnees contenues dans celles-ci *pourraient* etre accessibles des que la meme zone sera allouee. D'ailleurs ce n'est pas le boulot du systeme de gerer cela, c'est en principe au programmeur de savoir ce qu'il fait.
Pas forcement le meme processus ni le meme programme.
Oui.
Dans le cas que je propose le PC n'est pas accessible materiellement pour ce genre d'attaque.
oui, la libération de la mémoire n'écrit rien dedans.
oui, elle est même en plusieur endroits : presse papier, mémoire utilisée pour créer le message encodé, etc...
si le programme n'efface rien, oui.
mais je pense qu'il ne faut pas te tourmenter, que les données restent en memoire dans l'ordinateur ne présente guère de danger si aucun logiciel espion ne vient fouiller dedans.
de plus, pour trouver les 16 caractères de ton numéro de CB au milieu de ton giga-octet de mémoire, la probabilité de le repérer est très faible.
bien sur, si un logiciel espion est présent cela représente un risque supplémentaire, mais le problème de base est la présence de ce logiciel espion.
en cas d'arrêt, la mémoire retombe à 0, sauf si on utilise la mise en veille qui copie tout le contenu de la mémoire dans le disque dur...
Ca d=E9pend de l'OS, et de la configuration de sa s=E9curit=E9.
(r=E9ponse toute aussi =E9vasive que la question).
(oh punaise, que d'anneries que je vois dans les r=E9ponses: NON =E7a ne d=E9pend pas de l'archi; et OUI certains OS effacent syst=E9matiquement toute zone lib=E9r=E9e !!! )
Par contre, la r=E9tention quand la machine est =E9teinte d=E9pend de la technologie de RAM utilis=E9e dans la machine concern=E9e. Dans une SDRAM, presque tout est intacte 1s apr=E8s extinction, et les bits les plus vivaces tiennent 10s. Dans une DDR, c'est beaucoup moins; dans une EDO, ou les m=E9canismes encore plus vieux, on a sans aucun probl=E8me
10mn, 1h, voire 1 ou 2j. Les OS v=E9ritablement s=E9curis=E9s effacent la RAM durant le processus d'extinction de la machine (certes, c'est inutile sur un PC vu que le BIOS de toute fa=E7on va tout exploser ... dois-je vous dire tout le mal que je pense des PC et du BIOS ?)
La norme ANSI ne statue rien cot=E9 s=E9curit=E9, mais, les OS s=E9curis=E9= s ajoutent =E0 la fonction free() une routine d'effacement (=E9criture de la zone).
Non, =E7a ne sert absolument =E0 rien. Si la page a =E9t=E9 copi=E9e en SWA= P, ou d=E9plac=E9e (merci les TLB - dois-je vous dire tout le mal que je pense des TLB et du co-processeur des x86 ? ), les donn=E9es seront pr=E9sentes en plusieurs exemplaires un peu partout dans la machine.
Pour pallier =E0 =E7a, certains systems offrent des m=E9canismes offrant la garantie que la page allou=E9e ne sera pas d=E9plac=E9e, ni mise en swap. C= e sont des fonctions assez r=E9centes (10 =E0 15 ans je pense). C'est dans cette direction que vous devez vous renseigner sur ce qui est propos=E9 par le noyeau que vous pensez utiliser.
oui, et pendant un bout de temps. Sur ma station de travail, en faible activit=E9, j'ai retrouv=E9 dans ma RAM des r=E9sidus de donn=E9es utilisat= eur plus de 1h apr=E8s fermeture de l'application qui les g=E9rait.
Tout d=E9pend du programme. Si c'est un logiciel s=E9rieux, genre GnuPG, tournant sur un OS s=E9rieux, genre greLinux, alors, toutes les pr=E9cautions ont =E9t=E9 prises pour garantir au maximum votre s=E9curit= =E9. Dans une majorit=E9 d'autres cas, craignez le pire :) .
Si je me souviens bien ce sont des mécanismes imaginés/mis en place au début des années 90 dans le cadre de l'ITSEC et aussi des critères de développement des OS sécurisés pour le compte de la NSA aux US. La société US pour laquelle je bossais avait implémenté deux Unix sécurisés, l'un de niveau C2, l'autre de niveau B1 et B2 qui implémentaient ce genre de mécanismes. Windaube est très loin de tout cela... Sachant qu'en plus dans le cadre de l'évaluation il est impératif d'avoir les sources A JOUR et que la validation de l'OS en question inclu la recompilation au bit près du noyau évalué. Pour la petite histoire nous avions fait évaluer ces versions d'Unix en France par les services officiels, à l'époque le CELAR, et l'obtention des autorisations US n'avaient pas été sans mal... Mais nous y sommes arrivés... Ce qui voulait certainement dire à l'époque que la NSA avait encore bien mieux en terme de sécurité... ;-))
Ceci n'a aucun interet puisqu'on efface la memoire avant de la liberer.
Bien sur que si.
J'ai precise que la memoire est allouee avec les options 'non-moveable' et 'locked'. Pour eviter le swap je vais monter temporairement la priorite de la thread a 'realtime' pour qu'elle ne soit pas interrompue. Aucun probleme.
=E9.
Je ne vais pas changer d'OS alors qu'une bonne programmation permettra de diminuer fortement, voire de resoudre le probleme. Quand on se retourne un ongle, on ne se coupe pas le bras.
On dirait une malediction a la Harry Potter !!! J'ai eu toutes les reponses et confirmations que j'attendais. Je sais comment je vais m'y prendre pour minimiser le probleme. Vade Retro : je n'ai rien a craindre.
Tu as tout a fait raison, tres bonne remarque ! J'ai deja fait quelques essais en jouant sur le niveau de priorite d'une thread avec un programme de test : la priorite 'realtime'
*ressemble* a un masquage d'interruption, aucune autre thread utilisateur ne prend la main tant que la priorite n'est pas redescendue a un niveau plus bas. (j'ai meme pu bloquer mon PC dans une boucle de mon soft)
Donc puisque aucun programme ne prendra la main pendant le tres court instant ou j'utilise la memoire pour ensuite l'effacer, en principe aucune demande de memoire ne pourra venir impliquer un swap disque du systeme. Et meme si ce n'est pas un masquage d' IT du point de vue du systeme, comme la partie critique de mon soft ne dure que quelques millisecondes, ca devrait etre suffisant.
Pour XP, franchement, j'ai du mal à y croire. Vous devriez peut-être publier vos programmes de test.
Si un processus écrit des données en RAM, et si l'OS peut donner accès à ces données à un autre processus un peu plus tard par le jeu des mécanismes d'allocation, j'appelle ça une transmission.
Pas d'accord ! Un OS moderne comme XP qui gère des permissions multi-utilisateurs et assure l'isolation logique entre processus doit absolument interdire ce genre de fuite d'information.
Sans forc=E9ment parler de certification, ces m=E9canismes peuvent =EAtre pr=E9sents dans des OS distribu=E9s ... c'est pas parce que le distributeur ne vend pas la certification, que les m=E9canismes sont absents. Il est facile de trouver un Linux les poss=E9dant (d=E8s qu'on fricote avec les Linux s=E9curis=E9s); chercher aussi evidement du cot=E9 des BSD. Les Windows modernes n'ont toujours pas =E7a ? je pense entre autre =E0 XP, ou les versions Server ... ? la garantie de non d=E9placement d'une page n'est quand m=EAme pas si compliqu=E9e =E0 faire .= ..
Je n'ai pas pris le temps de lire les digressions en 24 volumes. Comme constat=E9, je suis reparti du post originale. Et ce post ne pr=E9cise ni archi, ni OS.
D=E9sol=E9, en lisant =E7a, j'ai r=E9ellement, lit=E9rallement explos=E9 de rire :) Vraiment :)
Je vais citer un cas connu, pratiqu=E9 par certains pirates, quand c'est possible: on se rend dans une salle server, on ouvre un server, on retire =E0 chaud une barette de RAM, et on l'ins=E8re imm=E9diatement dans une carte m=E8re modifi=E9e qui, pour le moins, apporte le courant n=E9cessaire =E0 la r=E9tention des donn=E9es. Cette dite carte m=E8re est ensuite reboot=E9e; si l'archi est n'importe quoi d'autre qu'un PC (je vous ai dit tout le mal que je pense des PC ? ah non, tj pas), il n'y a pas de BIOS (je vous ai dit tout le mal que je pense des BIOS ? ah non, tj pas) ... ou avec un BIOS modifi=E9, alors il redient facile de d=E9marrer la dite CM sur un system maison. Typiquement, la machine va charger un OS sur la m=E9moire basse, et la barette d=E9plac=E9e sera positionn=E9e dans un slot haut. Ainsi, le chargement de l'OS n'=E9crasera pas la barette =E0 lire. Alternative, on change =E0 chaud dans le server l'unit=E9 de stockage et la ROM de POST directement dans le server, et on appui sur le bouton reset; mis a part l'espace pris par l'OS charg=E9, on acc=E8de a presque toute la RAM.
NB1: si la barette sortie est ins=E9r=E9e dans une plaque d'essai avec un controlleur du genre uC ou FPGA, =E7a ouvre =E9norm=E9ment de portes.
NB2: l'histoire du bouton reset, a une =E9poque, =E7a faisait fureure.
NB3: c'est en jouant =E0 ce genre de choses qu'on a d=E9couvert (par hasard, comme pour toutes les bonnes inventions) que les m=E9moires CMOS =E9taient sensibles =E0 la lumi=E8re (on a constat=E9 que la dur=E9e de r=E9tention des donn=E9es d=E9pendait de si la machine =E9tait ouverte ou pas ... de fil en aiguille, on a pos=E9 des masques sur les m=E9moires, constat=E9 que les zones m=E9moires effac=E9es avaient une corr=E9lation av= ec la position du masque, puis on a gratt=E9 le plastique des RAM, puis les premi=E8res cellules photo-sensibles CMOS sont n=E9es).
NB3: quand on sait qu'une barette EDO a une r=E9tention de 1 =E0 10s, on peux jouer =E0 =E7a avec une esp=E9rance de r=E9cup=E9ration des donn=E9es = qui avoisine les 100%, si on manipule vite.
Autre note: quand on est le noyeau, ou l'admin, on peux tuer une application sans lib=E9rer ses ressources. Ni le bouton reset, ni la panne de courant ne sont soumis =E0 la moindre proc=E9dure de s=E9curit=E9. Votre application finale sera sur onduleur, et d=E9nu=E9e de bouton reset ?
On parle s=E9curit=E9 de donn=E9es, TOUS les cas sont envisageables. Y compris les cas de piratages et d'acc=E8s physiques.
Et, pour vous rappeler que quand on parle s=E9curit=E9, y a pas de place pour les naifs, ne faites m=EAme pas confiance =E0 votre processeur:
formatting link
(y a vraiment qu'Intel pour nous faire ce genre de blague. Je vous ai dit tout le mal que je pense d'Intel ? )
Alors, le plus important a =E9t=E9 fait. Mais, il reste des bricoles =E0 v=E9rifier:
- qu'on est pas sur un P4 HT qui bogue
- que les appels ont tous =E9t=E9 r=E9ussis
- que l'archi n'a pas d'autres failles connues (j'ai toujours =E9t=E9 tr=E8= s inquiet de voire la m=E9moire g=E9r=E9e par un controlleur externe sur Intel)
- qu'on ne rayonne pas trop (archi blind=E9e)
- qu'on a un co-processeur (et autres bricoles genre le gestionnaire TLB) s=E9rieux, ou que le bus a pas une m=E9moire double port qui traine (c'est fou ce qu'on trouve dans certaines machines quand on sort la loupe).
Jusqu'=E0 ce que le client rapporte qu'une donn=E9e lui a =E9t=E9 vol=E9e := )
Lisez les documentations et ML qui concernent GNUPG, c'est passionnant :)
Une petite conffusion entre RT et pagination fixe ?
Ok, admettont qu'un thread RT est non interruptible. Imaginons que l'application est multi-thread, que deux threads sont r=E9partis entre deux processeurs; la page doit donc =EAtre allou=E9e dans une zone partageable.
- si les processeurs ne sont pas juxtapos=E9s physiquement, certains =E9changes de donn=E9es devront transiter par d'autres processeurs (jetez un oeil =E0 la topologie octo CPU d'AMD, vous comprendrez de quoi je parle); on se retrouve avec des r=E9sidus de donn=E9es un peu partout :)
- qu'est-ce qui vous garanti que le gestionnaire TLB va tout restreindre comme il faut ?
- le RT ne doit pas =EAtre confondu avec l'atomique. Dans un OS pr=E9- emptif, quand le noyeau dit "c'est =E0 moi", il prend la main; alors, ce sont les drivers qui font la loi.
Votre station de d=E9veloppement est quelle archi ? combien de CPU ? quel type de RAM ? quel chipset ?
Vous savez que rien que dans la s=E9rie P4, il y a 3 approches diff=E9rentes possibles pour un acc=E8s m=E9moire selon la cat=E9gorie ? Qu= and =E0 AMD, ils sont en constante =E9volution (j'essaye m=EAme plus de les suivre).
Vous avez v=E9rouill=E9 la machine parce qu'une application gourmande a pris le dessus sur le noyeau; probabilit=E9 de 100% dans un mono CPU,
50% dans un bi, 33% dans un tri ...
Totallement faux. M=EAme quand une tache est RT, certaines versions de Windows peuvent quand m=EAme demander au noyeau de reprendre la main, si le noyeau a =E9t=E9 configur=E9 pour =E7a (regardez les advanced server). C= a va aussi varier selon la structure du noyeau. Bref, lisez la documentation du scheduler. Et de la VM (Virtual Machine, c'est elle qui g=E8re les allocations).
Sur un bi CPU, tout change encore.
Certains windows sont tr=E8s param=E9trables, surtout les Windows temps r=E9el (comme certaines versions server, ou CE). Sous linux, le noyeau a enfin une fr=E9quence de scheduling variable, qui peut =EAtre mont=E9e =E0
10kHz; je serais =E9tonn=E9 que Windows CE n'ait pas une option similaire.
Qu'est-ce qui vous garanti que le nombre de cycles requis pour votre op=E9ration sera toujours inf=E9rieure au nombre de cycles permis pour une op=E9ration atomique ?
Pour =E9viter ces probl=E8mes, l'id=E9al est qu'une partie de l'application soit un driver, charg=E9 en espace noyeau; on dispose alors d'outils beaucoup plus pointus pour se munir des protections voulues. C'est plus la mode, mais =E7a facilite le travail.
De toute fa=E7on, parler s=E9curit=E9 dans une station de travail Intel sou= s Windows ... c'est franchement une perte de temps. Parce que vous ne savez pas ce qu'Intel ou Microsoft inventeront d'idiot pour leurs prochains produits. L'id=E9al est donc malheureusement, =E0 l'ancienne, d'interdit que votre produit soit =E9x=E9cut=E9 sur une machine diff=E9rent= e de ce pour quoi =E7a a =E9t=E9 con=E7u. Certes, je vous sugg=E8re de bloque= r toute compatibilit=E9 amont; mais la s=E9curit=E9 est =E0 ce prix.
Une fois de plus : ce n'est pas la question. Il s'agit du comportement des fonctions de gestion memoire, et non du fait que quelqu'un s'introduise dans une societe ou un domicile pour y acceder au materiel, car ceci n'est pas de ma responsabilite.
Je suis bien d'accord, mais a nouveau je le repete : Il s'agit du comportement des fonctions de gestion memoire, non de hacking via acces physique au materiel, ok ?
Tu est manifestement tres fier de savoir des choses, c'est bien, mais dans ce cas precis, ce n'est pas la question.
Voici de la lecture pour Mr "A.Caspis" :-)
Apparament tu penses du mal de beaucoup de choses.
Ouf !
C'est ok pour moi.
:)
Si c'est suite a un acces physique sur le materiel ce n'est pas mon domaine : je ne suis pas un vigile. Je pourrais meme laisser les choses en l'etat puisque mon programme fonctionne correctement, et s'il y a fuite de donnees via allocation memoire, ce n'est plus de mon ressort mais de celui du systeme. Je fais cela uniquement parce-que je suis un mec bien ;-)
Sans doute, mais ma question n'allait pas jusque la ! Toutefois je te remercie pour toutes ces precisions.
Nenni : une transmission c'est l'envoi *volontaire* de donnees precises entre deux points. Ici il s'agit de memoire qui a ete ecrite par un processus, puis liberee sans avoir ete effacee. Une fois liberee cette memoire redevient disponible pour une nouvelle allocation, quel que soit le processus demandeur. Le systeme n'a pas a gerer le contenu de la memoire, mais juste a fournir un pointeur/handle sur la zone memoire allouee.
Oui je suis bien d'accord sur le principe, mais dans le cas qui nous concerne c'est au programmeur d'effacer la memoire avant de la liberer. Le systeme n'est pas concerne par le *contenu* de la memoire, mais seulement par la mise a disponibilite et la liberation de celle-ci.
Stop : entre les deux instants qui separent l'allocation memoire et sa liberation, il n'y a qu'UNE et UNE SEULE thread qui tourne.
Un seul CPU.
| > Donc puisque aucun programme ne prendra la main | > pendant le tres court instant ou j'utilise la memoire pour | > ensuite l'effacer, en principe aucune demande de memoire | > ne pourra venir impliquer un swap disque du systeme. | > Et meme si ce n'est pas un masquage d' IT du point de vue | > du systeme, comme la partie critique de mon soft ne | > dure que quelques millisecondes, ca devrait etre suffisant. | Totallement faux. M=EAme quand une tache est RT, certaines versions de | Windows peuvent quand m=EAme demander au noyeau de reprendre la main,
Certes, mais tant que le scheduler ne donne pas la main a une autre programme *utilisateur* tout est ok.
À mon goût l'attaque par canal caché la plus bluffante, c'est l'extraction à distance de clés crypto par chronométrage des temps de réponse d'un serveur SSL:
Le source me semble OK (pour le peu que je connais de l'API Windows). Est-ce que quelqu'un peut tester et confirmer que ça ressuscite des données potentiellement confidentielles ? Moi je n'ai pas de compilo et je n'exécute pas le premier EXE venu :-)
OK pour la nuance sémantique.
Non, nous ne sommes pas d'accord. Sur un PC Windows, le programmeur n'a pas les moyens de garantir que son programme effacera ses données sensibles en toutes circonstances (le programme peut être interrompu brutalement pour tout un tas de raisons).
Un OS qui se prétend multi-utilisateur ne doit pas allouer de la mémoire qui contient encore des données d'un autre processus. Si c'est un bug de XP, j'ai du mal à croire qu'il n'a pas déjà été découvert et exploité à des fins malhonnêtes. Mais bon, seule l'expérimentation aura le dernier mot.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.