Ce n'est pas plus dur de provoquer des overflows (et d'autres failles) dans un thread que dans un process !
J'ai prétendu le contraire ? Ca n'est pas alors un thread malicieux, mais une faille dans un thread existant. Par contre injecter un thread malicieux dans un processus ets infiniment plus complexe que d'injecter un processus malicieux dans un système.
Tous les programmes utilisant la séparation de privilèges (comme ssh ou X) utilisent évidemment des uid/groups spéciaux pour le process privilégié.
Donc la séparation des droits se fait au niveau logiciel et non au niveau matériel et c'est aussi sensible aux attaques que les threads
T2 ne peut pas empêcher un T1 malicieux d'accéder à une variable privée de T2 avec un signal.
Si cf les trois exemples dans les posts précédents.
En userspace, tu ne peux pas empêcher T1 de modifier les variables privées de T2 pour forcer T2 à utiliser R malicieusement.
Si, cf les trois exemples dans les posts précédents.
[^] # Re: Séparation des privilèges impossible avec threads actuelles !
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
J'ai prétendu le contraire ? Ca n'est pas alors un thread malicieux, mais une faille dans un thread existant. Par contre injecter un thread malicieux dans un processus ets infiniment plus complexe que d'injecter un processus malicieux dans un système.
Tous les programmes utilisant la séparation de privilèges (comme ssh ou X) utilisent évidemment des uid/groups spéciaux pour le process privilégié.
Donc la séparation des droits se fait au niveau logiciel et non au niveau matériel et c'est aussi sensible aux attaques que les threads
T2 ne peut pas empêcher un T1 malicieux d'accéder à une variable privée de T2 avec un signal.
Si cf les trois exemples dans les posts précédents.
En userspace, tu ne peux pas empêcher T1 de modifier les variables privées de T2 pour forcer T2 à utiliser R malicieusement.
Si, cf les trois exemples dans les posts précédents.