Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Souvent, le modèle de programmation nécessite un rappel de serveur à un client par le biais d’un appel de procédure distante (RPC) ou d’appels clients vers un serveur non approuvé. Cela introduit de nombreux pièges potentiels.
Tout d’abord, le rappel au client doit être effectué avec un niveau d’emprunt d’identité suffisamment faible. Si le serveur est un service système hautement privilégié, l’appel d’un client local avec un niveau d’emprunt d’identité ou supérieur peut fournir au client des privilèges suffisants pour reprendre le système. L’appel d’un client distant avec un niveau d’emprunt d’identité supérieur à celui nécessaire peut également entraîner des conséquences indésirables.
Deuxièmement, si un attaquant amène votre service à effectuer un rappel, il peut lancer ce qu’on appelle un trou noir— attaque par déni de service. Ces attaques ne sont pas spécifiques au RPC ; dans ces attaques, une machine vous amène à envoyer le trafic à celui-ci, mais elle ne répond pas à vos demandes. Vous coulez de plus en plus de ressources pour appeler le trou noir, mais ils ne reviennent jamais. Un exemple générique de cette attaque est une attaque au niveau TCP appelée attaque d’inondation TCP/IP SYN.
Au niveau RPC, une attaque simple au trou noir se produit lorsqu’un attaquant appelle une interface et demande au serveur de rappeler l’interface. L’interface est conforme, mais l’attaquant ne retourne jamais l’appel : un thread sur le serveur est lié. L’attaquant effectue cette opération 100 fois, en liant 100 threads sur le serveur. Finalement, le serveur manque de mémoire. Le débogage du serveur peut potentiellement révéler l’identité de l’appelant au trou noir, mais souvent le serveur sera redémarré sans soupçonner une faute de jeu, ou il se peut qu’il n’y ait pas suffisamment d’expertise disponible pour déterminer l’attaquant.
Le troisième piège est sur le client. Souvent, un client effectue un appel au serveur en informant le serveur comment le rappeler (généralement une liaison de chaîne), puis attend qu’un appel du serveur arrive, acceptant aveuglement tout appel sur ce point de terminaison qui prétend provenir du serveur. Le protocole de rappel du serveur au client doit inclure un mécanisme de vérification pour s’assurer que lorsque le rappel vient au client, il provient réellement du serveur.