dans un autre processus, et qu'il communique avec le broker process (ipc ou autre) lorsqu'il faut qu'il interagisse avec tout ou partie du système.
Je suppose a nouveau que le "broker process" est considéré comme sur et qu'il vérifie convenablement les entrées pour éviter tout acte malveillant.
Oui, le truc principal a comprendre c'est que le processus qui s'occupe du rendering ne peut acceder a aucun processus, le seul auquel il peut c'est le broker a travers une interface RPC.
oh, ben c'est juste lancer le process d'affichage en nobody et voila le tour est joué.
Cette partie la oui, mais toute la partie broker process, communication entre les 2 processus, integration des UIs des 2 processus, ... doit etre implementee, sinon ca ne fonctionne pas proprement.
La question est "a quoi peut accéder ce broker process".
Si tu permet a ton broker process de sauver des fichiers dans le répertoires, tu est tout aussi owned que firefox.
Le broker process a acces a tout le compte utilisateur de lui-meme.
Le truc c'est que le processus de rendering ne controle pas le broker process, il n'a pas d'acces direct au processus, tout ce qu'il peut faire c'est envoyer des requetes a travers RPC et esperer que le broker accepte de completer la requete.
Typiquement, si le processus de rendering demande de sauver un fichier dans \windows\system32, le broker recoit la requete et automatiquement affiche une fenetre demandant la permission, c'est imparable. De meme, les requetes disponibles sont limitees, tu peux pas faire tout et n'importe quoi evidemment.
Bref, le processus de rendering n'a pas de controle sur le broker process, il y a toujours la possibilite d'une faille dans le systeme de protection lui-meme evidemment, mais c'est une surface d'attaque bcp plus petite que le browser en lui-meme, ce qui rend la chose bcp plus difficile.
[^] # Re: Sont nul
Posté par pasBill pasGates . En réponse au journal 10 000 dollars à gagner, à condition de désinstaller Firefox. Évalué à 1.
Je suppose a nouveau que le "broker process" est considéré comme sur et qu'il vérifie convenablement les entrées pour éviter tout acte malveillant.
Oui, le truc principal a comprendre c'est que le processus qui s'occupe du rendering ne peut acceder a aucun processus, le seul auquel il peut c'est le broker a travers une interface RPC.
oh, ben c'est juste lancer le process d'affichage en nobody et voila le tour est joué.
Cette partie la oui, mais toute la partie broker process, communication entre les 2 processus, integration des UIs des 2 processus, ... doit etre implementee, sinon ca ne fonctionne pas proprement.
La question est "a quoi peut accéder ce broker process".
Si tu permet a ton broker process de sauver des fichiers dans le répertoires, tu est tout aussi owned que firefox.
Le broker process a acces a tout le compte utilisateur de lui-meme.
Le truc c'est que le processus de rendering ne controle pas le broker process, il n'a pas d'acces direct au processus, tout ce qu'il peut faire c'est envoyer des requetes a travers RPC et esperer que le broker accepte de completer la requete.
Typiquement, si le processus de rendering demande de sauver un fichier dans \windows\system32, le broker recoit la requete et automatiquement affiche une fenetre demandant la permission, c'est imparable. De meme, les requetes disponibles sont limitees, tu peux pas faire tout et n'importe quoi evidemment.
Bref, le processus de rendering n'a pas de controle sur le broker process, il y a toujours la possibilite d'une faille dans le systeme de protection lui-meme evidemment, mais c'est une surface d'attaque bcp plus petite que le browser en lui-meme, ce qui rend la chose bcp plus difficile.