Комментарии 11
steam точка йехе, как всегда.
./steam.sh, в отдельном network namespace от отдельного пользователя с запретом capabilities, ни разу не запущенный от root'а, с приватным home dir и devices.
При установке Valve установили такие права на свою ветку внутри HKLM, что в ней всем пользователям доступны любые действия («Full control» для группы «Users»).
Круто выходит.
К чему эти танцы со стимом? Большинство пользователей имеет права администратора, почему бы сразу не удалить папку C:/Windows/System32?
Если вручную поменять учётку под которой стартует сервис стима на учётку с только юзерскими правами, то нарушит ли это его работоспособность? Раз права на запись в его парку и ветку реестра уже есть у юзеров. Просто что бы хотя бы что-то не запускалось с правами системы.
С большой вероятностью нарушит, поскольку обычно основная задача сервиса как раз выполнять действия требующие высоких привилегий.
Сервис Steam при своем старте пытается обновить себя и без админских прав он не сможет скопировать файлы в C:\Program Files (x86)\Common Files\Steam — думаю что после этого он завершит свою работу.
Сервис Steam при своем старте пытается обновить себя и без админских прав он не сможет скопировать файлы в C:\Program Files (x86)\Common Files\Steam — думаю что после этого он завершит свою работу.
задача сервиса как раз выполнять действия требующие высоких привилегий
Так-то оно так, но мы же знаем, что на ветку в HKLM и папку в Program Files права на запись у юзеров уже есть. Про C:\Program Files (x86)\Common Files\Steam не знал — пишу с телефона и рабочего компа, тут Стима нет и посмотреть не могу.
То что я предложил выше это просто первое, что пришло в голову. Т.е. ситуация на мой взгляд такая — мы понимаем, что это насквозь дырявое поделие и задача малой кровью хотя бы не допустить эскалации привилегий до NT AUTHORITY\SYSTEM.
Может быть попробовать дать права на запись юзерам в C:\Program Files (x86)\Common Files\Steam. Да, согласен, что это не то что бы очень хорошее предложение. Но думается это меньшее из зол.
Если вопрос именно как не допустить эскалации, то в данный момент уязвимость закрыта (насколько я смотрел — пути нормализуются до записи в лог и сам файл лога перенесен из доступной пользователю папки).
Что случится при любых изменениях в правах — никому не известно. Некоторые пользователи указывали, что они отключали сервис вообще и клиент продолжал работать. но это до первого обновления, надо думать.
Что случится при любых изменениях в правах — никому не известно. Некоторые пользователи указывали, что они отключали сервис вообще и клиент продолжал работать. но это до первого обновления, надо думать.
Да вы так скоро им все lpe пофиксите :D
This article in english.
Думаю, такие ссылки лучше давать в начале статьи.
Steam- это маленькая инди-студия. Не нужно на них обижаться…
Они вон спустя несколько лет пофиксили моргания у NPC в Half-Life 2, а спустя 6 лет после выхода Dota 2 озаботились вопросами матчмейкинга и бустинга аккаунтов…
Они вон спустя несколько лет пофиксили моргания у NPC в Half-Life 2, а спустя 6 лет после выхода Dota 2 озаботились вопросами матчмейкинга и бустинга аккаунтов…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Третья уязвимость Steam Windows Client, но не 0day