Création d'un processus de travail à l'épreuve des bombes (sous Windows)

J'écris une visionneuse pdf qui utilise diverses bibliothèques écrites en C. Ce code C est potentiellement facile à exploiter. Et il y a juste trop de lignes à vérifier. Je vais devoir supposer que ce code peut contenir des bogues exploitables.Création d'un processus de travail à l'épreuve des bombes (sous Windows)

Le fait est que le code C est assez simple. Un flux d'octets entre à une extrémité, et un bitmap (aussi un flux d'octets) sort à l'autre. Inspiré par google chrome, je pense à créer un processus séparé qui fait le décodage et le rendu de la page. Idéalement, cela devrait être exécuté dans un processus qui n'a absolument aucun droit de faire quoi que ce soit, à l'exception de lire le flux d'entrée dont il dispose et de générer un flux d'octets (un bitmap non compressé) à l'autre extrémité.

Ce que je pense que le processus ne devrait pas être en mesure de faire est:

tout accès disque
sockets ouverts
quantité limitée d'utilisation de la mémoire
de mémoire partagée d'accès avec d'autres processus
charger d'autres dll
... autre chose?

Est-ce possible? Est-ce décrit quelque part?

Source

2010-11-19 Anonymous

duplication possible de [Existe-t-il une API Sandbox programmable et légère pour la plate-forme Windows?] (Http://stackoverflow.com/questions/2016731/is-there-a-lightweight-programmable-sandbox-api-for- the-windows-platform) –

Si vous avez le code source - vous pouvez le vérifier ne fait pas les choses décrites. Eh bien, limiter la mémoire disponible est un peu plus difficile. Vous pouvez cependant utiliser SetProcessWorkingSetSize.

De plus, après avoir construit l'exécutable, vous pouvez vérifier sa table d'importation de DLL (par le dépendant des dépendances) pour vous assurer qu'il n'accède à aucune fonction de fichier/socket.

Source

2010-11-19 22:37:45 valdo

Ce dont je parle, ce sont des choses que je ne veux pas que le code d'exploitation puisse faire. Je pense qu'il est toujours possible d'exécuter des fonctions de DLL visibles au processus, en interrogeant leur adresse lors de l'exécution. Je suis à la recherche d'une ligne de défense au niveau OS. –

Mais bon, merci d'avoir rejoint le brainstorm, de toute façon. –

Vous pouvez également vérifier que le code n'ajoute pas 'LoadLibraryX' et' GetProcAddress'. Par conséquent, le code ne pourra probablement pas utiliser d'autres fonctions de socket/fichier. À moins que ce soit un code vraiment ** mal expoli, qui peut à l'exécution analyser le mappé dans la mémoire kernel32.dll et localiser la fonction nécessaire dans sa table d'exportation. – valdo

Ce n'est pas vraiment possible. En fin de compte, tout code d'exploitation potentiel sera exécuté avec tous les privilèges avec lesquels ce processus s'exécute. Si vous l'exécutez en tant qu'utilisateur standard, vous limiterez les dommages qui pourraient être causés, mais votre meilleur pari est de simplement corriger le code autant que possible.

Source

2010-11-20 04:05:45 Luke

Je suis d'accord que l'exploit est seulement limité aux privilèges des processus. Donc, l'idée est de réduire ces privilèges au strict minimum. –

Vous pouvez créer un nouveau groupe/utilisateur et utiliser la politique de sécurité locale pour le restreindre sévèrement, mais cela semble un peu extrême pour un petit lecteur PDF. – Luke

Création d'un processus de travail à l'épreuve des bombes (sous Windows)

Répondre

Questions connexes