Переполнение буфера считается "решенной проблемой"? (по крайней мере, для будущих систем)

Question

Я рассматриваю различные технологии защиты буфера / кучи / стека, такие как PAX, DEP, NX, CANARIES и т. Д.

И новый SMEP - http://vulnfactory.org/blog/2011/06/05/smep-what-is-it-and-how-to-beat-it-on-linux/

Предполагается, что я использую последнее ядро ​​на последнем основном процессоре Предполагая, что я перекомпилирую все свои приложения с различными защитами компилятора Предполагая, что у меня хороший DEP, ASLR NX немного защищен

Разумно ли говорить, что большинство атак с переполнением буфера потерпит неудачу? И это было решено для будущих систем?

Как следствие, верно ли сказать, что в настоящее время реализованы текущие системы Win7 безнадежно уязвимы для ROT и других методов, особенно в 32-битных приложениях?

p.s. Я намеренно не собираюсь приводить здесь аргумент «управляемый код безопасен»

[отказ от ответственности] Я не сторонник небрежного кодирования. Я понимаю, что есть много других атак. Я знаю, что существующие системы намного превосходят «идеализированную» конфигурацию безопасности

Answer 1

Нет, переполнение буфера не является решенной проблемой, по крайней мере, в неуправляемом коде.

Основная проблема со всеми перечисленными технологиями (DEP / NX, ASLR, Canaries, SMEP) заключается в том, что они происходят после факта : они не могут решить проблему переполнения буфера, поскольку они не предотвращают основную причину - переполнение буфера и повреждение памяти уже произошло .

Все схемы являются просто «хорошими», но ненадежными эвристическими способами, позволяющими либо обнаружить неисправность после того, как коррупция произошла, но до того, как она станет работающей, либо просто усложнить создание надежной рабочей уязвимости.

Например, DEP, ASLR и канареек в Windows Vista и 7 можно обойти с помощью ROT плюс другие методы, и, следовательно, просто поднять планку сложности создания рабочего эксплойта.Но увеличение сложности довольно значительно.В этом суть техники.

Если вы заинтересованы в решении проблемы в корне путем предотвращения первоначального повреждения буфера, я думаю, что это будет наиболее продуктивным, но, вероятно, вернет нас к обсуждению.управляемого кода ...

Answer 2

Если все эти технологии включены и установлены строгие проверки компилятора, большинство методов, которые обходят текущие защиты, отключены, но, как отмечается в статье о взломе, это только повышает планку атак, а новые требуют дополнительных проверок и сложности. , Лучшая ставка для вашего требуемого состояния «большинство» в конечном итоге заключается в том, что сложность, необходимая для эксплойтов, не сможет вписаться в доступное пространство, так как все больше областей и пространств становятся защищенными, но мы еще не там.