Исходное сообщение
"Grsecurity прекращает бесплатное распространение своих патче..." Отправлено добрый, 13-Май-17 02:34
> На первый взгляд обе уязвимости относятся к race condition. Чтобы > такое выловить надо найти код, выполнение которого зависит от данных, которые > можно изменить кодом в другом потоке. То есть надо построить некую > карту покрытия кода и данных разными потоками и найти, где они > пересекаются, когда работают параллельно. Я (также будучи дилетантом) мыслю в том же направлении: построить модель, определить "проблемные места" и попытаться с ними "что-то сделать", применяя различные формы обратной связи в поиске вариантов решений, оценке результатов и для уточнения модели. Беда в том, что, в частности, проблема взаимодействия через семафоры (блокировки по коду и данным) более чем трёх процессов является математически неразрешимой. Поэтому результаты любого моделирования ситуаций гонки с количеством процессов больше двух в принципе будут неполны и не дадут никаких строгих гарантий для защищающейся стороны, но при этом в принципе способны полностью удовлетворять нужды атакующей стороны: выявлять некоторое количество подходящих уязвимостей, поддающихся эксплуатации. > Grsecurity уже пытается строить карту допустимых > вызовов в рамках RAP-а, может её можно расширить и на race > conditions? Положительный ответ на этот вопрос был бы слишком большим обобщением, практически лишённым содержания. Но саму парадигму моделирования - да, можно и нужно применить.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> На первый взгляд обе уязвимости относятся к race condition. Чтобы >> такое выловить надо найти код, выполнение которого зависит от данных, которые >> можно изменить кодом в другом потоке. То есть надо построить некую >> карту покрытия кода и данных разными потоками и найти, где они >> пересекаются, когда работают параллельно. > Я (также будучи дилетантом) мыслю в том же направлении: построить модель, определить > "проблемные места" и попытаться с ними "что-то сделать", применяя различные формы > обратной связи в поиске вариантов решений, оценке результатов и для уточнения > модели. Беда в том, что, в частности, проблема взаимодействия через семафоры > (блокировки по коду и данным) более чем трёх процессов является математически > неразрешимой. Поэтому результаты любого моделирования ситуаций гонки с количеством процессов > больше двух в принципе будут неполны и не дадут никаких строгих > гарантий для защищающейся стороны, но при этом в принципе способны полностью > удовлетворять нужды атакующей стороны: выявлять некоторое количество подходящих уязвимостей, > поддающихся эксплуатации. >> Grsecurity уже пытается строить карту допустимых >> вызовов в рамках RAP-а, может её можно расширить и на race >> conditions? > Положительный ответ на этот вопрос был бы слишком большим обобщением, практически лишённым > содержания. Но саму парадигму моделирования - да, можно и нужно применить.
	Введите код, изображенный на картинке: