114 ответов в этой теме

[Silver_klop]

Это конечно все так звучит... Но увы и ах - коллизии для стойких алгоритмов хеширования не найдены до сих пор

DES-56 (некоторое время назад) был стойким.
Но дело даже не в этом.
Примем отсутствие коллизий разных файлов как аксиому. И что? Для расчёта хэша необходимо проверить валидность самой ЭЦП и рассчитать сам хэш. Расчёт хэша требует вычитки всего файла и выполнение вычислений. Итог: чтение с диска - на прежнем уровне или больше. Вычислительные затраты - строго пропорциональны размеру файла. В чём профит?
А вот (принципиальный) недостаток - есть. Требуется доверять сторонней инфраструктуре. А почему, собственно? На каком основании внешняя организация должна быть святее папы римского?
Прежде чем ответить на этот вопрос - заглянить в список отозванных корневых сертификатов и вспомните историю про не вовремя проплаченный домен microsoft.com.
В общем, как говорят киношные злодеи: "Если хочешь, чтобы ЭТО было сделано хорошо - сделай это сам".
А сколько в system32 может "валяться" неподписанных рантаймов и прочего ...

лично я не прошу внедрять проверку ЭЦП в алгоритм сканера/спайдера, но вот инструмент отчасти аналогичный АВЗ не помешал бы для поиска не известных угроз. Просмотреть "выжимку" от system32 после работы утилиты куда проще, чем смотреть ее в исходном варианте.
PS. кто мешает проверять валидность файла по версия+размер+ЭЦП+еще какая-нибудь хеш функция?

Сообщение было изменено Silver_klop: 06 Июнь 2011 - 11:40

[mrbelyash]

Это конечно все так звучит... Но увы и ах - коллизии для стойких алгоритмов хеширования не найдены до сих пор

DES-56 (некоторое время назад) был стойким.
Но дело даже не в этом.
Примем отсутствие коллизий разных файлов как аксиому. И что? Для расчёта хэша необходимо проверить валидность самой ЭЦП и рассчитать сам хэш. Расчёт хэша требует вычитки всего файла и выполнение вычислений. Итог: чтение с диска - на прежнем уровне или больше. Вычислительные затраты - строго пропорциональны размеру файла. В чём профит?
А вот (принципиальный) недостаток - есть. Требуется доверять сторонней инфраструктуре. А почему, собственно? На каком основании внешняя организация должна быть святее папы римского?
Прежде чем ответить на этот вопрос - заглянить в список отозванных корневых сертификатов и вспомните историю про не вовремя проплаченный домен microsoft.com.
В общем, как говорят киношные злодеи: "Если хочешь, чтобы ЭТО было сделано хорошо - сделай это сам".
А сколько в system32 может "валяться" неподписанных рантаймов и прочего ...

лично я не прошу внедрять проверку ЭЦП в алгоритм сканера/спайдера, но вот инструмент отчасти аналогичный АВЗ не помешал бы для поиска не известных угроз. Просмотреть "выжимку" от system32 после работы утилиты куда проще, чем смотреть ее в исходном варианте.
PS. кто мешает проверять валидность файла по версия+размер+ЭЦП+еще какая-нибудь хеш функция?

Это есть в режиме шарка.

Проверка ЭЦП + хеш=больше занимать времени чем искать сигнатуру.


Для ЭЦП возможно обязательным будет соединение с сетью,а это не есть гуд(вдруг отозван сертификат).

Сообщение было изменено mrbelyash: 06 Июнь 2011 - 12:02

[HHH]

Для расчёта хэша необходимо проверить валидность самой ЭЦП и рассчитать сам хэш. Расчёт хэша требует вычитки всего файла и выполнение вычислений. Итог: чтение с диска - на прежнем уровне или больше. Вычислительные затраты - строго пропорциональны размеру файла. В чём профит?

Профит в минимизации ложных срабатываний.
Вы моё предложение читали вообще?

[mrbelyash]

Для расчёта хэша необходимо проверить валидность самой ЭЦП и рассчитать сам хэш. Расчёт хэша требует вычитки всего файла и выполнение вычислений. Итог: чтение с диска - на прежнем уровне или больше. Вычислительные затраты - строго пропорциональны размеру файла. В чём профит?

Профит в минимизации ложных срабатываний.
Вы моё предложение читали вообще?

А ужаснейшие тормоза куда девать будем?

[#user]

А ужаснейшие тормоза куда девать будем?

Интересно, а кто придумал этот миф про ужасные тормоза?

По теме предотвращения ложных срабатываний - вот такую картинку увидит пользователь Norton-а, если попытается, например, добавить в карантин любой легитимный файл, входящий в состав Windows (вплоть до картинок из "Sample Pictures" и т.п.):
 Capture_1.png   17,87К   36 Скачано раз

Причем отсутствие подписи Microsoft значения не имеет, и работает этот механизм даже на локальном ПК, не подключенном к Интернет.

[mrbelyash]

А ужаснейшие тормоза куда девать будем?

Интересно, а кто придумал этот миф про ужасные тормоза?

Открыть файл и прочитать по смещению будет быстрее чем взять хеш...а теперь добавьте еще и проверку ЭЦП.

Да,сделать защиту от дурака(отправки легитимного файла в карантин) конечно же нужно....вот только ресурсов видать не хватает на все сразу.

[HHH]

А ужаснейшие тормоза куда девать будем?

Я уже написал, куда девать тормоза. тыц
Давайте по пунктам. Почему это не будет работать?

Сообщение было изменено HHH: 06 Июнь 2011 - 13:21

[sergeyko]

А ужаснейшие тормоза куда девать будем?

Интересно, а кто придумал этот миф про ужасные тормоза?

Открыть файл и прочитать по смещению будет быстрее чем взять хеш...а теперь добавьте еще и проверку ЭЦП.

Зря стараетесь, кажется, #user из фанов и говорит о других тормозах и мифах.

[#user]

кажется, #user из фанов и говорит о других тормозах и мифах.

#user говорит о полезном (по его мнению) функционале, который способствует:
1. Первично - решению проблемы ложных срабатываний на легитимных файлах Windows.
2. Вторично - уменьшению времени сканирования, за счет исключения из проверки не изменившихся файлов, которые заведомо известны, как чистые/доверенные (в частности- файлы Windows).

Поэтому интересно было бы обсудить реализацию подобных механизмов в Dr.Web и узнать мнение разработчиков.
Надеюсь, что Вам, как техническому специалисту, гораздо более интересно обсуждать подобные вопросы, а не излагать фантазии на тему фанатства и прочих вселенских заговоров.
Спасибо.

[Konstantin Yudin]

1. Первично - решению проблемы ложных срабатываний на легитимных файлах Windows.
2. Вторично - уменьшению времени сканирования, за счет исключения из проверки не изменившихся файлов, которые заведомо известны, как чистые/доверенные (в частности- файлы Windows).

Поэтому интересно было бы обсудить реализацию подобных механизмов в Dr.Web и узнать мнение разработчиков.
Надеюсь, что Вам, как техническому специалисту, гораздо более интересно обсуждать подобные вопросы, а не излагать фантазии на тему фанатства и прочих вселенских заговоров.
Спасибо.

1. пункт у нас есть, но не активирован. есть причины. да и вообще наше видение с сертификатами сейчас в фазе пересмотра жизненного пути. второй не имеет смысла.

[#user]

1. пункт у нас есть, но не активирован. есть причины. да и вообще наше видение с сертификатами сейчас в фазе пересмотра жизненного пути.

Спасибо за информацию. Это уже совсем другой разговор.

второй не имеет смысла.

По-поводу второго пункта - я имел ввиду функционал, который в общих чертах описывали разработчики Symantec и Microsoft в блогах:
http://community.norton.com/t5/Norton-Prot...ity/ba-p/126699
http://blogs.technet.com/b/mmpc/archive/20...essentials.aspx

" With some basic algorithms we were able to identify many programs that we could trust – and we avoid scanning these files for infections. On typical users' computers we are able to trust 60% to 90% of all regularly used programs, drastically reducing our scan times."

"[AV] needs to be fast, and the fastest way to scan a file is to actually not scan the file at all - reputation helps it do just that. When [AV] first encounters a file, it performs a malware scan using all the technologies it needs to determine if the file is malicious. If the file is not malicious (which is hopefully the case), there's a background check that happens later, using idle cycles to see if the file's Authenticode signature or hash matches an internal list of trusted publishers and known clean files. If the file is on the list, it will be skipped in future scans, either on access or on demand."

[basid]

Профит в минимизации ложных срабатываний.
Вы моё предложение читали вообще?

Я напомню, что пока спайдер гард не принял решения - операция блокируется. По этой причине время проверки объекта для "защиты в реальном времени" имеет весьма высокий приоритет.
И повторю ещё раз: я не параноик, но не вижу ни одной причины, позволяющей доверять чужой инфраструктуре. Ключевые слова - "доверять" и "чужой".

[HHH]

Я напомню, что пока спайдер гард не принял решения - операция блокируется. По этой причине время проверки объекта для "защиты в реальном времени" имеет весьма высокий приоритет.

Лечение в любом случае не быстрая операция. Может минутами длиться. О каком реальном времени вы говорите???
Что лучше - чуть-чуть подождать, пока проверится подпись, или унести чистый файл в карантин?
Из ваших слов следует, что второй вариант вам больше по душе. Что странно.

И повторю ещё раз: я не параноик, но не вижу ни одной причины, позволяющей доверять чужой инфраструктуре. Ключевые слова - "доверять" и "чужой".

За отсутствием альтернативы.
Чуть выше по теме вы сами предлагали перемножить количество файлов на количество версий windows, на...

[basid]

Лечение в любом случае не быстрая операция. Может минутами длиться. О каком реальном времени вы говорите???

О времени, за которое можно принять решение "файл чист". Для принятия такого решения - хэши, даже если их заверить ЭЦП, совсем не помощники.
Если файл, не дай бог, таки, заражён, то вообще жесть - сначала потратили уйму времени и выяснили, что файл изменён, а потом потратим ещё время, чтобы "найти и обезвредить".

Чуть выше по теме вы сами предлагали перемножить количество файлов на количество версий windows, на...

Я поясню, для тех кому (всё ещё) непонятно: база чистых файлов, на которой обкатывается очередное обновление антивирусной базы в тестлабе - ничем не не лучше и не хуже проверки по базе хешей у клиента.

[#user]

сначала потратили уйму времени и выяснили, что файл изменён

Никакой уймы времени не будет. Хэш подсчитывается только один раз, а не постоянно.

" Q: Isn't computing the SHA256 more expensive than just scanning the file?
A: Yes it is. But we only compute the SHA256 once and then associate it with the file. Once the file is trusted, looking up the trust value is much faster than scanning the file. If the file is not trusted, then it is scanned every time the file is accessed."

Сообщение было изменено #user: 07 Июнь 2011 - 17:56

[Konstantin Yudin]

Профит в минимизации ложных срабатываний.
Вы моё предложение читали вообще?

Я напомню, что пока спайдер гард не принял решения - операция блокируется. По этой причине время проверки объекта для "защиты в реальном времени" имеет весьма высокий приоритет.
И повторю ещё раз: я не параноик, но не вижу ни одной причины, позволяющей доверять чужой инфраструктуре. Ключевые слова - "доверять" и "чужой".

тут речь о уже задетекченном файле. если мы его задетектили, то уже можем проверить подпись и сказать что лечить отказываемся, ибо это фолс.

[basid]

Никакой уймы времени не будет. Хэш подсчитывается только один раз, а не постоянно.

Только при условии, что злоумышленник изменил и файл и хэш.
Изменить хэш он не может - нет закрытого ключа. Как вы узнаете, что "ЭЦП неверна" без расчёта хэша файла, который мог быть (незаметно) изменён между двумя перезагрузками или остановками мониторинга?

[basid]

тут речь о уже задетекченном файле. если мы его задетектили, то уже можем проверить подпись и сказать что лечить отказываемся, ибо это фолс.

Это понятно, но проблема - в доверии чужой инфраструктуре:

Обновление .NET Framework 3.5 с пакетом обновления 1 и .NET Framework 2.0 с пакетом обновления 2

 для 32-разрядных (x86) версий Windows 2000, Windows Server 2003, Windows XP (KB979909)

Размер файла: 830 КБ , менее 1 мин

Была обнаружена проблема в системе безопасности, позволяющая злоумышленнику НЕЗАМЕТНО нарушить целостность содержимого

с цифровой подписью, когда оно используется приложением, которое обращается к Microsoft .NET Framework в ОС Windows.

Капс - мой.

[HHH]

Это понятно, но проблема - в доверии чужой инфраструктуре:

С вами не интересно спорить. Вы отвечаете на собственные мысли, а не на мои посты.
Я так и не увидел внятного объяснения, почему метод из поста 21 не будет работать.

[#user]

Как вы узнаете, что "ЭЦП неверна" без расчёта хэша файла, который мог быть (незаметно) изменён между двумя перезагрузками или остановками мониторинга?

Цитаты из упоминавшегося выше блога:

" Q: How do you know that a trusted file was modified and should not be trusted but scanned?
A: Our kernel mode device driver technology instantaneously revokes file trust attributes the moment the file is modified.

Q: How do you know that a trusted file was not modified when the product was not running, such as booting into safe mode or booting from a CD?
A: On startup, we analyze the NTFS file system, and if we determine that any changes were made that we cannot account for, all trust values of all files on that volume are revoked.

Q: How do you associate the SHA256 and trust attributes with the file? Specifically, will these cause similar problems experienced by users of a well
know security product that also associated information with files by using Alternate Data Streams (ADS) and the NTFS Object ID’s?
A: We store the information in a very high performance and secure product-specific database. We do not impact or change the normal file system."