Итак, кое-какие новости, даже хорошие...
1. Важнейшее нововведение — возможность прекратить загаживание альтернативных потоков NTFS. По многочисленным просьбам пользователей, заметим.
Делается это отключением второй опции на вкладке Auto-Sandbox. Разумеется, при этом пропадет и слежение за происхождением файлов, поэтому сначала обязательно выбираем конфигурацию Proactive Security.
2. Приятная мелочь — отдельная кнопка, открывающая список активных процессов. Раньше приходилось сначала открывать список процессов, изолированных в Sandbox, вызывать контекстное меню и снимать ненужную галку. А теперь достаточно одной кнопки (ее можно добавить в виджет из списка задач Sandbox). Можно и командной строкой открыть окно с активными процессами: cis.exe --procViewUI
3. Списки неопознанных и доверенных файлов теперь объединили в один и добавили фильтр, какие показывать: доверенные, неопознанные или вредоносные. Забавно...
4. Пользовательский рейтинг. Раньше можно было лишь добавлять файлы в доверенные. Но сделать неопознанным файл, которому Comodo доверяет — как можно?? А теперь можно. Якобы. Т.е. файл имеет два рейтинга: комодовский и пользовательский. И пользователь может присвоить рейтинг неопознанного (или даже вредоносного) файлу, которому Comodo доверяет.
Но не тут-то было. Во-первых, есть скрытая база доверенных файлов, которым Comodo продолжает доверять, вообще не глядя на пользовательский рейтинг. Во-вторых, наблюдается какая-то странная лажа в случаях, когда путь к файлу содержит одинарную кавычку...
Так что нововведение сомнительное. Ему, конечно, напрашивается применение вроде подавления привилегий горе-инсталляторов (прежде всего, в портативных браузерах), но советовать остерегусь. Тем более, что, по уму, привилегии инсталляторам лучше вообще не давать, чем отбирать потом выборочно... (Кто статьи читал, поймет.)
5. Радостная новость, наравне с первой, — устранили пару проблем анализа командной строки. Если коротко — закрыта известная мне дыра фаервола. Злосчастная защита от поддельных интерпретаторов, видимо, больше нужна не будет.
Но — внимание! — ярлыки по-прежнему опасны. Грубо говоря, закрыта лишь одна уязвимость из главных четырех. Так что, напоминаю, защищаемся от левых ярлыков, причем лучше всего делать это «Политиками ограниченного использования программ».
Теперь подробнее про изменения в анализе командной строки, если кому интересно.
Раньше было как — если запускается программа с именем какого-нибудь интерпретатора, и передается ей в командной строке путь к какому-нибудь файлу, то она получает все права того самого файла.
Что сейчас. Во-первых, программа получит права «интерпетируемого» файла только в том случае, если она находится на своем законном месте, типа «%windir%\system32\wscript.exe». А если программа «wscript.exe» находится, например, на рабочем столе — выполнится она лишь со своими собственными правами.
Тут одно «но» (то самое, кстати, что и в моей «защите от поддельных интерпретаторов средствами CIS»). Если дело происходит в виртуальной среде, и программа с именем интерпретатора помещена на его законное место (лишь виртуально, не по-настоящему) — то она все же получит те привилегии, что указанный в командной строке файл. Повторю, дело это происходит в виртуальной среде, поэтому едва ли с этими привилегиями она натворит больше бед, чем без них. Единственное, что, конечно, настораживает, это привилегии доступа к сети...
И тут спасает другое исправление: во-вторых, теперь интерпретаторы принимают права не любых файлов, указанных в командной строке, а... только файлов, которые сами не являются исполняемыми! Т.е. программа, запущенная строкой «%windir%\system32\wscript.exe notepad.exe», теперь будет выполняться от имени «wscript.exe», а не «notepad.exe», как раньше. Если же вместо «notepad.exe» указать, скажем, «script.js» или «log.txt», — программа «wscript.exe» выполнится от имени файлов «script.js» или «log.txt» соответственно (с точки зрения CIS, разумеется).
(Любопытная деталь: определение исполняемых файлов происходит не по расширению, а по их содержимому.)
В результате возможностей использовать лютый баг с именами интерпретаторов вроде как и не осталось. Единственное, что пока приходит мне в голову, — это виртуально подменить интерпретатор шпионской программой и запустить, указав в командной строке путь как какому-нибудь скрипту, имеющему доступ в интернет. Но кто ж дает доступ в интернет скриптам...
1. Важнейшее нововведение — возможность прекратить загаживание альтернативных потоков NTFS. По многочисленным просьбам пользователей, заметим.
Делается это отключением второй опции на вкладке Auto-Sandbox. Разумеется, при этом пропадет и слежение за происхождением файлов, поэтому сначала обязательно выбираем конфигурацию Proactive Security.
2. Приятная мелочь — отдельная кнопка, открывающая список активных процессов. Раньше приходилось сначала открывать список процессов, изолированных в Sandbox, вызывать контекстное меню и снимать ненужную галку. А теперь достаточно одной кнопки (ее можно добавить в виджет из списка задач Sandbox). Можно и командной строкой открыть окно с активными процессами: cis.exe --procViewUI
3. Списки неопознанных и доверенных файлов теперь объединили в один и добавили фильтр, какие показывать: доверенные, неопознанные или вредоносные. Забавно...
4. Пользовательский рейтинг. Раньше можно было лишь добавлять файлы в доверенные. Но сделать неопознанным файл, которому Comodo доверяет — как можно?? А теперь можно. Якобы. Т.е. файл имеет два рейтинга: комодовский и пользовательский. И пользователь может присвоить рейтинг неопознанного (или даже вредоносного) файлу, которому Comodo доверяет.
Но не тут-то было. Во-первых, есть скрытая база доверенных файлов, которым Comodo продолжает доверять, вообще не глядя на пользовательский рейтинг. Во-вторых, наблюдается какая-то странная лажа в случаях, когда путь к файлу содержит одинарную кавычку...
Так что нововведение сомнительное. Ему, конечно, напрашивается применение вроде подавления привилегий горе-инсталляторов (прежде всего, в портативных браузерах), но советовать остерегусь. Тем более, что, по уму, привилегии инсталляторам лучше вообще не давать, чем отбирать потом выборочно... (Кто статьи читал, поймет.)
5. Радостная новость, наравне с первой, — устранили пару проблем анализа командной строки. Если коротко — закрыта известная мне дыра фаервола. Злосчастная защита от поддельных интерпретаторов, видимо, больше нужна не будет.
Но — внимание! — ярлыки по-прежнему опасны. Грубо говоря, закрыта лишь одна уязвимость из главных четырех. Так что, напоминаю, защищаемся от левых ярлыков, причем лучше всего делать это «Политиками ограниченного использования программ».
Теперь подробнее про изменения в анализе командной строки, если кому интересно.
Раньше было как — если запускается программа с именем какого-нибудь интерпретатора, и передается ей в командной строке путь к какому-нибудь файлу, то она получает все права того самого файла.
Что сейчас. Во-первых, программа получит права «интерпетируемого» файла только в том случае, если она находится на своем законном месте, типа «%windir%\system32\wscript.exe». А если программа «wscript.exe» находится, например, на рабочем столе — выполнится она лишь со своими собственными правами.
Тут одно «но» (то самое, кстати, что и в моей «защите от поддельных интерпретаторов средствами CIS»). Если дело происходит в виртуальной среде, и программа с именем интерпретатора помещена на его законное место (лишь виртуально, не по-настоящему) — то она все же получит те привилегии, что указанный в командной строке файл. Повторю, дело это происходит в виртуальной среде, поэтому едва ли с этими привилегиями она натворит больше бед, чем без них. Единственное, что, конечно, настораживает, это привилегии доступа к сети...
И тут спасает другое исправление: во-вторых, теперь интерпретаторы принимают права не любых файлов, указанных в командной строке, а... только файлов, которые сами не являются исполняемыми! Т.е. программа, запущенная строкой «%windir%\system32\wscript.exe notepad.exe», теперь будет выполняться от имени «wscript.exe», а не «notepad.exe», как раньше. Если же вместо «notepad.exe» указать, скажем, «script.js» или «log.txt», — программа «wscript.exe» выполнится от имени файлов «script.js» или «log.txt» соответственно (с точки зрения CIS, разумеется).
(Любопытная деталь: определение исполняемых файлов происходит не по расширению, а по их содержимому.)
В результате возможностей использовать лютый баг с именами интерпретаторов вроде как и не осталось. Единственное, что пока приходит мне в голову, — это виртуально подменить интерпретатор шпионской программой и запустить, указав в командной строке путь как какому-нибудь скрипту, имеющему доступ в интернет. Но кто ж дает доступ в интернет скриптам...
