Reuse exploit или молчание брандмаузера II
Допустим, разработчики операционных систем исправят свой грубый ляп с дескрипторами сокетов, равномерно рассеяв их по всему 32-битному пространству, что сделает лобовой перебор довольно неэффективным, особенно если в функции getpeername будет встроен детектор такого перебора, реагирующий в случае подозрения на атаку все возрастающим замедлением. И что тогда? А ничего! Опытные хакеры (и грамотно спроектированные черви) перейдут к плану "Б", насильно делая re-bind уже открытому порту.
Возможность повторного использования адресов– это вполне легальная возможность и предусмотрена она не случайно. В противном случае проектирование разветвленных сетевых приложений с сильно развитой иерархической структурой оказалось бы чрезвычайно затруднено (кто программировал собственные сервера, тот поймет, ну а кто не программировал, просто не в состоянии представить чего он избежал).
Если говорить коротко: делать bind на уже открытый порт может только владелец этого порта (т. е. процесс, открывший данный порт или один из его потомков, унаследовавших дескриптор соответствующего сокета), да и то лишь при том условии, что сокет не имеет флага эксклюзивности (SO_EXCLUSIVEADDRUSE). Тогда, создав новый сокет, и, вызовов функцию setsockopt, присваивающую ему атрибут SO_REUSEADDR, shell-код сможет сделать bind и listen, после чего все последующие
подключения к атакованному серверу будут обрабатываться уже не самим сервером, а зловредным shell-кодом!
