Pull to refresh

Comments 7

Для Linux (и Android в частности) нужно ещё указывать -Wa,--noexecstack чтобы запретить выполнение кода на стэке.
В домене EMET легко конфигурируется через групповые политики. Давно развернул у себя всем юзерам. Остаётся, впрочем, открытым вопрос, насколько оттестировано и безопасно его широкое применение на серверном виндовом софте, особенно опубликованном наружу — TMG, IIS, Exchange, Lync, терминал.
EMET на сервер сайд — ребят, вам заняться нечем? Он для клиентского софта хоть как-то полезен бывает даже, несмотря на то, что и EMET обходится иногда ;) Но на сервер сайд — не стоит тратить время.
А, собственно, расскажите — почему нет? На сервер-сайд атаки такого типа, который прикрывается EMET'ом, тоже весьма актуальны.
Сугубо потому, что сервер-сайд атак такого типа (именно на Апачи, IIS, Exchange, Terminal, ССШ и серверный софт) уже лет как 5-6 нету. Последняя актуальная атака была на службу ОС — конфликер был, а на сервер-сайд аппы — Lotus сплойты, которые работали и так тяжко, без всяких ЕМЕТ. Учитывая сложность эксплуатации таких уязвимостей в удаленных сервисах и слабый контроль над кучей (для проведения атак на ASLR или банального HeapSpray), большинство уязвимостей остаются DoS или очень трудно-эксплуатируемыми (в новом софте). В итоге мы имеем, что таких атак в дикой природе нет фактически, а значится нет смысла мучать софт и усложнять себе и админам жизнь.

EMET имеет смысл ставить под софт, который старый и с известными уязвимостями, но который пропатчить незя. А просто так вешать на все ЕМЕТ — зачастую просто лишняя работа, которая снижает и без того низкие риски.
NDK'шный дефолтный компилятор, если мне не изменяет память, по умолчанию проставляется -fstack-protector
Sign up to leave a comment.