Комментарии 127
На деле, конечно, достаточно будет короткого мейла от Microsoft в Valve с угрозой выкатить подобное предупреждение, чтобы Valve, вырывая на жопе волосы, бросила все силы на закрытие дыры.
MS не виноват и, в общем смысле вряд ли, имеет право указывать на ошибки.
МС, конечно, не виноваты. Но наверняка у них есть требования к разработчикам сервисов с системным уровнем доступа на тему делегирования прав и защиты от несанкционированного использования.
Вопрос такой — а насколько вообще корректна ситуация, что в Реестре Windows можно менять права у веток, на которые ссылаются симлинки? Другими словами, что мешает реализовать аналогичный подход без использования Steam? Ведь, если я правильно понял из текста, достаточно просто обладать правами на какую-то свою ветку в реестре и иметь возможность устанавливать права для дочерних веток. Нужны ли здесь вообще какие-то программы?
Без стима это все делать нельзя по ряду причин:
1) Симлинки из менее защищенных веток в более защищенные не работают (условно говоря, симлинк из HKCU в HKLM не будет работать).
2) Чтобы создать симлинк в HKLM в 99,99% ключей нужно уже иметь права администратора, по дефолтным правам доступа.
Это выглядит как-то странно. Получается, ни в коем случае нельзя давать доступ на запись обычным пользователям ни в один из ключей из HKLM?
Программы нужны. Права-то меняет не атакующий, а именно что Steam Client Service, в процессе рекурсивного обхода "своей" ветки реестра.
Не совсем понятно — при чем тут сотрудник h1 и его запрет
Valve отклонили отчет об уязвимости — т.е. они считают это не уязвимостью, а, вероятно фичей.
Почему бы и не рассказать всем о такой классной фиче? основания для запрета?
(мимо с линуксовой версией стима пробегал)
Т.е. я всё сделал правильно, когда при установке стима ни разу не дал ему рутовых прав (включая ручную распаковку deb'ки). В своём песочном пользователе steam он может копошиться, а в чужие домашние каталоги и в систему — ни-ни.
Это вы правильно делаете. Slack, например, в своем deb-файле пытается всунуть shell-скрипт в крон от рута, по комментариям в коде — чтобы восстанавливать себя в списке источников для менеджера пакетов, если запись будет закомментирована при обновлении системы. Но, конечно, добавляя себя в список источников, он позволяет компании Slack Inc перезаписать любой файл в системе, включая sshd или bash, например.
"Создание, распространение или использование компьютерных программ либо иной компьютерной информации, заведомо предназначенных для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации"
То есть — да, является. Программа из одной команды — тоже программа. Программа, содержащая команду «del C:\Windows», которая будет выполнена с повышенными правами без ведома пользователя — заведомо предназначена для несанкционированного уничтожения компьютерной информации
По идее, для отнесения к «заведомо предназначенным» программа помимо собственно деструктивных действий, должна содержать еще и средства маскировки от пользователя.
Интересно, а в конкурирующих площадках не были найдены подобные уязвимости? К примеру, в стремительно набирающим популярность Epic Games?
Я говорю, к примеру, о присутствии в hl2dm ряда откровенно явных косяков, которых до определенного обновления и не было. После их появления прошло уже несколько лет, об этом не раз писали в Вэлв, но ничего до сих пор не пофиксили. Вывод — им просто наплевать на игру, которая не приносит им дохода, и на комьюнити тоже.
Больше даже смахивает на то, что они умышленно эти баги добавили))
Все что живо — живо за счет игроков (модели и режимы в L4D2, кастомные карты в Dota 2)Все верно, но игрокам свойственно вырастать, обзаводится семьями и, зачастую, утрачивать возможность/желание играть в игры)) А для того, чтобы более младшие поколения тоже играли в эти же игры, их нужно поддерживать (обновлять движок, текстуры, придумывать новые фичи, как-то актуализировать игру, которой уже 5-10 лет). В противном случае потенциальные игроки могут даже не заметить такую игру. Что в итоге и случилось с Half-Life 2: Deathmatch, к примеру.
А через security@ я и вообще (в сравнении с этим) смешной exploit на Steamcommunity репортил, который для фишинга использовался. После того как человек на том конце смог воспроизвести проблему, буквально за считанные часы фикс добрался до прода.
UPD: «Attacks that require the ability to drop files in arbitrary locations on the user's filesystem.» если вчитаться, то действительно нужен уже локальный код, что не отменяет тот факт, что благодаря стиму любой зловред до NT SYSTEM может повыситься.
Это та самая, которая при запуске игр выводит вот такие запросы UAC:
Да, «ваше сообщение очень важно для них»!
Если так и есть, то интересно будет ли такое же безобразие, если при установке задать директорию для библиотеки игр за пределами Program Files?
(Вообще конечно подобные вещи — это полная задница. Chrome свои исполняемые файлы в AppData суёт, а этот, похоже, наоборот)
Сервису «Steam Client Service» соответствует файл C:\Program Files (x86)\Common Files\Steam\steamservice.exe и у него с правами все нормально.
Но есть еще файл C:\Program Files (x86)\Steam\bin\steamservice.exe — он лежит в папке, которой при установке стим дает разрешение на изменение для всех пользователей. Когда и как он запускается я не знаю.
«c:\Program Files (x86)\Steam» и туда же устанавливает и все свои приложения/игры
Это по умолчанию, origin делает также. В настройках можно выбрать произвольную директорию
Отличный отчет, интересная (показательная) уязвимость. Было бы здорово дополнить статью дескриптором безопасности ключа HKLM\SOFTWARE\Wow6432Node\Valve\Steam\Apps, что бы понять, какие пользователи могут создавать там симлинки (могут провести повышение привилегий).
Дескриптор безопасности, опуская подробности, KA для BU (KA [Key All] — Полный доступ, BU [Built-in User] — все пользователи).
Теперь забавный факт, по которому можно отличить диванных безопасников с реддита. Для создания симлинка в реестре не только не нужны права администратора, но и даже разрешение ключа на «create links». Нужно только разрешение на создание ключей.
Поздравляю, хайп по англоязчному интернету пошёл.
Но не уверен, что Valve «нормальные», учитывая, сколько раз я читал на тематических форумах «I found XSS in Steam, reported via ticket and email, posted on their forums and found my steam account disabled» и т.д. в таком же ключе.
Интересно, xi-tauw, локнут ли вам сам аккаунт. Если заблокируют — вообще отпетые.
Он даже вознаграждения не просил, просто хотел что бы пофиксили.
Проблема была в том что подменой отправляемых пакетов можно было вмешиваться в расчёт «рандомных» переменных, например задавая им всегда возможный максимум.
Максимальная точность… пробитие… урон…
«Вы вмешались в работу клиента игры, это не является ошибкой, ваш аккаунт заблокирован за нарушение пользовательского соглашения.»
После такого фееричного ответа, баг был успешно продан и существовал в приватных читах почти 3 года.
Переключайтесь на linux-версию стима. (Формально стим при этом не удаляется, а заменяется ОС).
Гостевая ось может находиться физически на одном винчестере в смежных разделах. Либо это какой-то узкоспециализированный термин?
Гостевая ось — это не ось, которой пользуются гости, а ось, запущенная на гостевой машине. Гостевая машина — это синоним слова "виртуалка".
all-ht.ru/inf/vpc/p_0_1.html
Отношение «хозяин-гость» между двумя ОС иерархично, а две операционки на разных разделах совершенно равны в правах (принцип «кто первый надел халат — тот и доктор» не может считаться нормальной системой разграничения прав).
Верите, что за скидку в 90% вы не получите скрытый майнер?
Так это известный факт — в стиме сотни майнеров продаётся. И вовсе даже не скрытых. Никого сей факт не смущает — ни Valve, ни покупателей.
Немецкий IT-Blog
steamcommunity.com/groups/SteamClientBeta#announcements/detail/1602638506845644644
Если Вам ответят, извините, ошиблись, вот ваши деньги за уязвимость — отпишитесь пожалуйста.
Интересно, признают ли они свою ошибку в итоге...
Судя по «радостным» комментариям, стим решил запушить это обновление как принудительное…
«Не баг» говорите? :)
steamcommunity.com/news/post/2412160539873037816
Client Update — Valve 13 авг
A new Steam client has been released and will be automatically downloaded.
…
Steam Windows Service
Fixed privilege escalation exploit using symbolic links in Windows registry
исследователь показал, что патч можно обойти, уязвимость все еще актуальна. Обход вкратце — можно вернуть предыдущие (до патча) версии сервиса.
Самое время найти ещё какой нибудь аналогичный баг и сразу его опубликовать извинившись за невозможность отправить его по программе, т.к. тебя в ней забанили =))
Я Вас поздравляю!!!
Вас разбанили, осталось носом ткнуть Вальве и потребовать с них награду!
https://habr.com/ru/news/t/464749/?utm_source=vk&utm_medium=social&utm_campaign=valve-priznala-svoyu-oshibku--kogda-haker
Я больше скажу, что сообщение от Valve в общем смысле никак не касается меня. Они просто сказали, что произошла ошибка и свалили все на недопонимание.
Да ладно???
Похоже попахивает чёрным пиаром. Феерично, мы признаём, что баг-таки есть, обновим программу, но тому чуваку шиш. Козлы.
Жаль, что мы Вам не можем никак помочь...
На самом деле, сообщество мне очень помогло, я очень ценю реакцию, в том числе русскоязычных, читателей.
Steam Windows Client Local Privilege Escalation 0day