The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Google опубликовал Vanir, статический анализатор для выявления неисправленных уязвимостей"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Google опубликовал Vanir, статический анализатор для выявления неисправленных уязвимостей"  +/
Сообщение от opennews (??), 06-Дек-24, 16:58 
Компания Google представила новый открытый проект Vanir, развивающий статический анализатор для автоматического выявления не применённых к коду патчей, устраняющих уязвимости. Vanir использует базу сигнатур с информацией об известных уязвимостях и патчах для устранения этих уязвимостей. Подобная БД ведётся Google с июля 2020 года и охватывает проекты, связанные с платформой Android, включая ядро Linux. В настоящее время поддерживается проверка исходного кода на языках C, C++ и Java. Код Vanir написан на языках С++ и Python, и распространяется под лицензией BSD...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62358

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

5. Сообщение от Аноним (5), 06-Дек-24, 17:09    Скрыто ботом-модератором+5 +/
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11

6. Сообщение от Аноним (6), 06-Дек-24, 17:11   –2 +/
Мне бы инструмент, который по бинарному файлу либы бы выдал точный коммит, из которого она собрана. При этом допущения:
* либа собрана из какого-то комиита из указанного репозитория
* сборочная система и версии зависимостей, включая те, что статически или на уровне хедера линкованы, неизвестны (система должна сама идентифицировать статически-линкованные и header-only либы и их версии)
* индекс специально для бинарников не создавался
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #8, #22, #25, #30, #38, #39

7. Сообщение от Аноним (6), 06-Дек-24, 17:13   +/
Если что - для целей апгрейда либ в старой системе Android без полной пересборки оной из исходников.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #10

8. Сообщение от Аноним (8), 06-Дек-24, 17:14   +2 +/
Такого инструмента не существует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #9

9. Сообщение от Аноним (6), 06-Дек-24, 17:22   +/
Жаль. В теори можно было бы реализовать как определение различий в именах символов из исходников, после чего извлечения символов из бинарей, определение по набору символов набора подходящих коммитов, после чего определение тех символов, которые поменялись, и извлечение из бинаря уже кода и данных по изменившимся символам (в первую очередь - констант и размеров), и матчинг их к изменениям в исходникам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #26

10. Сообщение от myster (ok), 06-Дек-24, 17:34   +1 +/
Если sha коммита не записывается в виде метаданных в саму либу, то само по себе значение sha бесполезно, т.к. оно может быть постоянно разное и зависит от других изменений в Git репозитории (не связанных именно с этой либой). То есть, это всё-равно, что измерять среднюю температуру по больнице.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

11. Сообщение от Аноним (-), 06-Дек-24, 17:34   +/
> и из-за хромиума и андроида его скоро выпилят

Влажные мечты хейтрочка.
А ведь намного логичнее предположить, что раст просто не настолько дыряв как сабжи и для него нет необходимости делать отдельный сложный механизм каталогизации CVE.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #13, #14

13. Сообщение от Аноним (13), 06-Дек-24, 17:57   +2 +/
БезопасТен (TM), абсолютна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

14. Сообщение от Аноним (14), 06-Дек-24, 18:12   –1 +/
прикольно. Т.е. взяв за основу предположение, судя по всему построенное на присутствии борров-чекера (который типа защищает от CVE связанных с памятью), можно отказаться от механизма каталогизации всех остальных CVE?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #20

20. Сообщение от Аноним (-), 06-Дек-24, 18:49   +/
> прикольно. Т.е. взяв за основу предположение, судя по всему построенное на присутствии
> борров-чекера (который типа защищает от CVE связанных с памятью), можно отказаться
> от механизма каталогизации всех остальных CVE?

Разумеется нет. Нужно смотреть на дырявость языка - сколько CVE лепят бракоделы.
Вот почему в списке кроме раста нет go, haskel, python? А потому что они не дырявые.
А к си и с++ (как наследник угребищного си) доверия нет - у них cve как блох на дворняге.

Почему добавили java - не знаю.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

22. Сообщение от Rock (?), 06-Дек-24, 19:02   +/
> Мне бы инструмент, который по бинарному файлу либы бы выдал точный коммит, из которого она собрана.

Вроде, для этого существует цифровая подпись. Сейчас все более-менее серьезные лавки свои бинарники подписывают.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #24

24. Сообщение от Аноним (6), 06-Дек-24, 19:32   +/
>для этого существует цифровая подпись

... но это неточно ... :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

25. Сообщение от Семен (??), 06-Дек-24, 20:04   +/
1) В большинстве библиотек есть API для получения версии библиотеки, версия в большинстве случаев содержит git коммит в короткой форме, если это не stable версия. Ничего вам не мешает написать динамический  загрузчик, и вызывать функцию для проверки версии библиотеки. Найти такие функции очень легко:

readelf -s /usr/lib64/libcurl.so.4 | grep version

332: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND nghttp2_version
387: 00000000000625d0   220 FUNC    GLOBAL DEFAULT    4 curl_version_info
398: 0000000000062c50   594 FUNC    GLOBAL DEFAULT    4 curl_version

Думаю не маленькие и сможете это все связать вместе с find через xargs, если вам нужна информация по всем библиотекам.

2) Уже есть build-id и так работает debuginfod, плюс привязка к исходникам.
https://docs.redhat.com/en/documentation/red_hat_enterprise_...
https://fedoraproject.org/wiki/RolandMcGrath/BuildID

readelf -n /usr/lib64/libcurl.so.4

Displaying notes found in: .note.gnu.property
  Владелец     Размер данных    Description
  GNU                  0x00000030    NT_GNU_PROPERTY_TYPE_0
    Свойства: x86 feature: IBT, SHSTK
    x86 feature used: x86, XMM
    x86 ISA used: x86-64-baseline

Displaying notes found in: .note.gnu.build-id
  Владелец     Размер данных    Description
  GNU                  0x00000014    NT_GNU_BUILD_ID (уникальный ID битовой строки сборки)
    ID сборки: 2f0d5d8846da760891684a6e301ce732ab8cefa0

Displaying notes found in: .note.package
  Владелец     Размер данных    Description
  FDO                  0x00000078    FDO_PACKAGING_METADATA
    Packaging Metadata: {"type":"rpm","name":"curl","version":"8.9.1-2.fc41","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:41"}

Displaying notes found in: .gnu.build.attributes
  Владелец     Размер данных    Description
  GA$<версия>3a1 0x00000010    OPEN
    Применяется к области с 0x1000 по 0x77c41

3) Это как в анекдоте про золотую рыбку:
Поймал дед золотую рыбку. Рыбка ему говорит:
- Отпусти меня и я исполню любое твое желание.
Дед, долго думал: машина, квартира, богатство, все не то, как-то мелко слишком. И сказал:
- Хочу мир во всем мире!
Рыбка в ответ:
- Дед, ну сам посмотри мир такой большой, а я всеволишь маленькая рыбка, давай что-то более приземленное.
Дед долго не думая, выдал:
- Хочу, что бы бабка мне мiнет сделала!
Рыбка:
- Дед! А Дед! А что ты там говорил, насчет мира во всем мире?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

26. Сообщение от Семен (??), 06-Дек-24, 20:17   +1 +/
Это не возможно, потому что при разных флагах компилятора и линковщика, уже код будет различаться, не говоря про разные компилятора. Почитайте как работают линкеры. Имена символов манглятся или вовсе удаляются, остаются только имена экспортируемых функций. Для поиска багов есть git bisect и ничего вам не мешает смотреть историю коммитов по конкретному файлу, и найти смещение в бинарнике и дисассемблировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

30. Сообщение от Аноним (30), 07-Дек-24, 04:03   +1 +/
А что делать, если два коммита идентичны?

И нет, это невозможно, потому что, например, в хедер-онли библиотеке может быть всё, что угодно, в частности, всё, что вообще выключает весь код из вашего проекта.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

38. Сообщение от Neon (??), 10-Дек-24, 01:15   +/
Странная хотелка. Собрать бинарник можно и без всяких репозиториев. В принципе без них обойтись
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

39. Сообщение от Neon (??), 10-Дек-24, 01:17   +/
Надо больше хотеть.))) Чтобы по бинарнику получать полную персональную инфу на человека, его собравшего. Фотографию, место жительства, текущее его местонахождение.))) Чтоб было кому за кривой код морду бить.)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру