Rappels (RPC)

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é, le rappel d’un client local avec un niveau d’emprunt d’identité ou supérieur peut fournir au client des privilèges suffisants pour prendre le contrôle du système. Le rappel d’un client distant avec un niveau d’emprunt d’identité plus élevé que nécessaire peut également entraîner des conséquences indésirables.

Deuxièmement, si un attaquant incite votre service à effectuer un rappel, il peut lancer ce qu’on appelle un trou noir: une attaque par déni de service. Ces attaques ne sont pas spécifiques à RPC ; dans ces attaques, une machine vous incite à lui envoyer du trafic, mais elle ne répond pas à vos demandes. Tu as de plus en plus de ressources pour appeler le trou noir, mais ils ne reviennent jamais. Un exemple générique d’une telle attaque est une attaque de niveau TCP appelée attaque par inondation SYN TCP/IP.

Au niveau RPC, une attaque par trou noir simple 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 le fait 100 fois, 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 du trou noir, mais souvent le serveur est redémarré sans soupçonner de fautes, ou il se peut qu’il n’y ait pas suffisamment d’expertise disponible pour déterminer l’attaquant.

Le troisième piège concerne le client. Souvent, un client effectue un appel au serveur indiquant au serveur comment le rappeler (généralement une liaison de chaîne), puis attend qu’un appel du serveur arrive, acceptant aveuglément tout appel sur ce point de terminaison qui prétend provenir du serveur. Le protocole de rappel du serveur vers le client doit inclure un mécanisme de vérification pour s’assurer que lorsque le rappel arrive au client, il provient effectivement du serveur.