Сообщение Re[2]: Переполнение буфера от 14.05.2019 13:18
Изменено 14.05.2019 13:46 netch80
Re[2]: Переполнение буфера
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Во-первых, это сразу же добавит геморроя по поддержке стеков. Не только уже озвученное переключение, но и то, что каждый стек должен быть непрерывен в виртуальном АП. Его нельзя расширять произвольно, добавлением любых свободных страниц — АП под каждый стек нужно резервировать заранее, и при его исчерпании наступает полный писец.
Это никогда не было так жёстко — и сейчас с работающим split stackp есть штатные обходы. Но это, да, дороже, и требует сборки как минимум заметной части кода под такое. Под Windows, вроде, реализаций нет.
Но в 64 битах и так адресов достаточно.
EM> Сейчас и так каждый поток имеет собственные стеки как режима пользователя, так и режима ядра, а пришлось бы все это удвоить.
Удвоение тут это малая цена.
ЕМ>Во-вторых, такое решение исключит лишь часть возможных атак, но не все. По-прежнему можно будет, организовав переполнение, так поменять данные потока, чтобы он сработал в угоду атакующему. Будет сложнее добиться нужного поведения, но это останется возможным.
ЕМ>Так что игра банально не стоит свеч.
Вот тут — да, но в основном по другим причинам.
ЕМ>Во-первых, это сразу же добавит геморроя по поддержке стеков. Не только уже озвученное переключение, но и то, что каждый стек должен быть непрерывен в виртуальном АП. Его нельзя расширять произвольно, добавлением любых свободных страниц — АП под каждый стек нужно резервировать заранее, и при его исчерпании наступает полный писец.
Это никогда не было так жёстко — и сейчас с работающим split stackp есть штатные обходы. Но это, да, дороже, и требует сборки как минимум заметной части кода под такое. Под Windows, вроде, реализаций нет.
Но в 64 битах и так адресов достаточно.
EM> Сейчас и так каждый поток имеет собственные стеки как режима пользователя, так и режима ядра, а пришлось бы все это удвоить.
Удвоение тут это малая цена.
ЕМ>Во-вторых, такое решение исключит лишь часть возможных атак, но не все. По-прежнему можно будет, организовав переполнение, так поменять данные потока, чтобы он сработал в угоду атакующему. Будет сложнее добиться нужного поведения, но это останется возможным.
ЕМ>Так что игра банально не стоит свеч.
Вот тут — да, но в основном по другим причинам.
Re[2]: Переполнение буфера
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Во-первых, это сразу же добавит геморроя по поддержке стеков. Не только уже озвученное переключение, но и то, что каждый стек должен быть непрерывен в виртуальном АП. Его нельзя расширять произвольно, добавлением любых свободных страниц — АП под каждый стек нужно резервировать заранее, и при его исчерпании наступает полный писец.
Это никогда не было так жёстко — и сейчас с работающим split stack есть штатные обходы. Но это, да, дороже, и требует сборки как минимум заметной части кода под такое. Под Windows, вроде, реализаций нет.
Но в 64 битах и так адресов достаточно.
EM> Сейчас и так каждый поток имеет собственные стеки как режима пользователя, так и режима ядра, а пришлось бы все это удвоить.
Удвоение тут это малая цена.
ЕМ>Во-вторых, такое решение исключит лишь часть возможных атак, но не все. По-прежнему можно будет, организовав переполнение, так поменять данные потока, чтобы он сработал в угоду атакующему. Будет сложнее добиться нужного поведения, но это останется возможным.
ЕМ>Так что игра банально не стоит свеч.
Вот тут — да, но в основном по другим причинам.
ЕМ>Во-первых, это сразу же добавит геморроя по поддержке стеков. Не только уже озвученное переключение, но и то, что каждый стек должен быть непрерывен в виртуальном АП. Его нельзя расширять произвольно, добавлением любых свободных страниц — АП под каждый стек нужно резервировать заранее, и при его исчерпании наступает полный писец.
Это никогда не было так жёстко — и сейчас с работающим split stack есть штатные обходы. Но это, да, дороже, и требует сборки как минимум заметной части кода под такое. Под Windows, вроде, реализаций нет.
Но в 64 битах и так адресов достаточно.
EM> Сейчас и так каждый поток имеет собственные стеки как режима пользователя, так и режима ядра, а пришлось бы все это удвоить.
Удвоение тут это малая цена.
ЕМ>Во-вторых, такое решение исключит лишь часть возможных атак, но не все. По-прежнему можно будет, организовав переполнение, так поменять данные потока, чтобы он сработал в угоду атакующему. Будет сложнее добиться нужного поведения, но это останется возможным.
ЕМ>Так что игра банально не стоит свеч.
Вот тут — да, но в основном по другим причинам.