Обратные вызовы (RPC)

Часто модель программирования требует обратного вызова сервера клиенту с помощью удаленного вызова процедур (RPC) или вызовов клиента на ненадежный сервер. Это представляет множество потенциальных ошибок.

Во-первых, необходимо выполнить обратный вызов клиента с достаточно низким уровнем олицетворения. Если сервер является системной службой с высоким уровнем привилегий, вызов локального клиента с олицетворением или более высоким уровнем олицетворения может предоставить клиенту привилегии, достаточные для того, чтобы захватить систему. Обратный вызов удаленного клиента с более высоким уровнем олицетворения, чем необходимо, также может привести к нежелательным последствиям.

Во-вторых, если злоумышленник побудит службу выполнить обратный вызов, он может запустить так называемую черную дыру — атаку типа "отказ в обслуживании". Такие атаки не относятся к RPC; В таких атаках компьютер побуждает вас отправлять ему трафик, но не отвечает на ваши запросы. Вы погружаете все больше и больше ресурсов в вызов черной дыры, но они никогда не возвращаются. Одним из общих примеров такой атаки является атака на уровне TCP, называемая атакой потока TCP/IP SYN.

На уровне RPC происходит простая атака на черную дыру, когда злоумышленник вызывает интерфейс и запрашивает у сервера обратный вызов интерфейса. Интерфейс соответствует требованиям, но злоумышленник никогда не возвращает вызов: один поток на сервере связан. Злоумышленник делает это 100 раз, связав 100 потоков на сервере. В конечном итоге на сервере заканчивается память. Отладка сервера потенциально может выявить удостоверение вызывающего объекта с черной дырой, но часто сервер будет перезапущен без подозрения в нечестной игре или может не быть достаточного опыта, чтобы определить злоумышленника.

Третья ошибка связана с клиентом. Часто клиент выполняет вызов сервера, информируя его о том, как вызвать его (обычно это строковая привязка), а затем ожидает поступления вызова с сервера, слепо принимая любой вызов в этой конечной точке, который, как утверждается, поступает с сервера. Протокол обратного вызова от сервера к клиенту должен включать некоторый механизм проверки, чтобы убедиться, что, когда обратный вызов приходит к клиенту, он фактически возник на сервере.