Я не первый год занимаюсь поиском уязвимостей, и, казалось бы, многое видел, но есть такая часть работы, к которой не удается привыкнуть и которую не могу понять. Это абсолютное нежелание вендоров принимать информацию об уязвимостях и проблемах. Я понимаю, что очень неприятно, когда тебе прямо показывают, что ты допустил ошибку и, скорее всего, не одну. Неприятно подтверждать в открытых источниках публично, что проблемы были, что сотрудники что-то недоработали. Но я не понимаю почему информацию об уязвимости нужно отвергать.


Итак, герой нашей истории — ПО Steam от компании Valve. И уязвимость повышения привилегий в нем, которая позволяет любому пользователю выполнить команды от имени NT AUTHORITY\SYSTEM.

Доброй вам пятницы, хабралюди. У меня с друзьями есть такая традиция — мы собираемся и вместе программируем. Раньше у нас такая работа была, а сейчас уже просто традиция — кодобредогенерация. Мы выбрали несложную задачку и нарисовали решений кто во что горазд. Код будет ближе к концу статьи, но не спешите листать вниз, надо же сначала объяснить, что это за код и как мы пришли к нему.

Сама задача — получить число 0x17 самым внезапным образом.


Внимание! Данный пост оскорбляет чувство прекрасного и практики программирования на C. Читайте, воспринимайте и комментируйте на свой страх и риск.

Исследования — это неотъемлемая часть моего рабочего процесса. Я исследую ПО, исходные коды, ОС, железки — все, до чего дотянутся руки (ну или руки начальства, тут как повезет). Но не все исследования проводятся по заказу, иногда что-то просто делаешь для души (что, наша компания в общем-то поощряет). Это исследование началось с разговора о шифровании, а закончилось обходом DLP и выносом данных за контролируемый периметр.

Я очень не люблю DLP-системы. Моя неприязнь основана на маркетинговой стратегии продуктов, представляющих свои решения в виде этакой «серебряной пули», которая может предотвратить все утечки данных в любой компании. Не может. По моему мнению, реально DLP помогает в 2 случаях — предотвратить утечку данных из-за кривых рук (типа отправки платежных данных вместо ali@domain.mail на all@domain.mail) и помочь провести расследование, кто же унес данные (постфактум, естественно). Я изначально был уверен, что специалист, владеющий достаточными знаниями о Windows, например, сможет преодолеть почти любые фильтры. А мотивированный инсайдер сможет найти такого специалиста и обучиться нескольким трюкам. Но проверять разные трюки на конкретных комплексах довольно скучно, поэтому надо было придумать, как разом обойти их все.

Эта статья является продолжением темы «неквалифицированного заказчика», а также попыткой проанализировать причины взаимной неудовлетворенности менеджеров и специалистов в неудачных проектах. Думаю, что моим коллегам знакома ситуация, когда проект провалился и команда пытается понять причины.

Толчком для формулирования концепции «неквалифицированного исполнителя» послужила «Черная книга менеджера» Славы Панкратова, а точнее, кусочек из главы 5 «Люди».

Если человек чего-то не делает, есть 4 причины

1. Не понял
2. Не умеет
3. Не может
4. Не хочет»

Именно в такой последовательности эти причины следует рассматривать. Но вот как понять, какая из них привела к неудаче? Идти сверху вниз и использовать методы наблюдения? Просто поговорить «начистоту»? Но не факт, что в результате получим правильное понимание.

Решение я нашел в методологии теории деятельности, элементы которой описаны, например, в статье Елены Мундриевской (ссылки на авторов приведены в конце публикации). Автор статьи приводит некую аксиому (или предикат) деятельности, при следовании которой результат на выходе будет соответствовать заданию на входе. Мне показалось, что разбор ошибок и неудач с использованием этой методики помогает правильно определить причины поражения.