https://www.opennet.ru/openforum/vsluhforumID3/135510.html Компания Google представила новый открытый проект Vanir, развивающий статический анализатор для автоматического выявления не применённых к коду патчей, устраняющих уязвимости. Vanir использует базу сигнатур с информацией об известных уязвимостях и патчах для устранения этих уязвимостей. Подобная БД ведётся Google с июля 2020 года и охватывает проекты, связанные с платформой Android, включая ядро Linux. В настоящее время поддерживается проверка исходного кода на языках C, C++ и Java. Код Vanir написан на языках С++ и Python, и распространяется под лицензией BSD...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62358<br> https://www.opennet.ru/openforum/vsluhforumID3/135510.html#39 Mon, 09 Dec 2024 22:17:19 GMT Надо больше хотеть.))) Чтобы по бинарнику получать полную персональную инфу на человека, его собравшего. Фотографию, место жительства, текущее его местонахождение.))) Чтоб было кому за кривой код морду бить.)))<br> https://www.opennet.ru/openforum/vsluhforumID3/135510.html#38 Mon, 09 Dec 2024 22:15:49 GMT Странная хотелка. Собрать бинарник можно и без всяких репозиториев. В принципе без них обойтись<br> https://www.opennet.ru/openforum/vsluhforumID3/135510.html#30 Sat, 07 Dec 2024 01:03:44 GMT А что делать, если два коммита идентичны?<br><br>И нет, это невозможно, потому что, например, в хедер-онли библиотеке может быть всё, что угодно, в частности, всё, что вообще выключает весь код из вашего проекта.<br><br> https://www.opennet.ru/openforum/vsluhforumID3/135510.html#26 Fri, 06 Dec 2024 17:17:22 GMT Это не возможно, потому что при разных флагах компилятора и линковщика, уже код будет различаться, не говоря про разные компилятора. Почитайте как работают линкеры. Имена символов манглятся или вовсе удаляются, остаются только имена экспортируемых функций. Для поиска багов есть git bisect и ничего вам не мешает смотреть историю коммитов по конкретному файлу, и найти смещение в бинарнике и дисассемблировать.<br> https://www.opennet.ru/openforum/vsluhforumID3/135510.html#25 Fri, 06 Dec 2024 17:04:05 GMT 1) В большинстве библиотек есть API для получения версии библиотеки, версия в большинстве случаев содержит git коммит в короткой форме, если это не stable версия. Ничего вам не мешает написать динамический загрузчик, и вызывать функцию для проверки версии библиотеки. Найти такие функции очень легко:<br><br>readelf -s /usr/lib64/libcurl.so.4 &#124; grep version<br><br>332: 0000000000000000 0 FUNC GLOBAL DEFAULT UND nghttp2_version<br>387: 00000000000625d0 220 FUNC GLOBAL DEFAULT 4 curl_version_info<br>398: 0000000000062c50 594 FUNC GLOBAL DEFAULT 4 curl_version<br><br>Думаю не маленькие и сможете это все связать вместе с find через xargs, если вам нужна информация по всем библиотекам.<br><br>2) Уже есть build-id и так работает debuginfod, плюс привязка к исходникам.<br>https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/developer_guide/compiling-build-id <br>https://fedoraproject.org/wiki/RolandMcGrath/BuildID<br><br>readelf -n /usr/lib64/libcurl.so.4<br><br>Displaying notes found in: .note.gnu.p https://www.opennet.ru/openforum/vsluhforumID3/135510.html#24 Fri, 06 Dec 2024 16:32:17 GMT &gt;для этого существует цифровая подпись<br><br>... но это неточно ... :)<br> https://www.opennet.ru/openforum/vsluhforumID3/135510.html#22 Fri, 06 Dec 2024 16:02:11 GMT &gt; Мне бы инструмент, который по бинарному файлу либы бы выдал точный коммит, из которого она собрана.<br><br>Вроде, для этого существует цифровая подпись. Сейчас все более-менее серьезные лавки свои бинарники подписывают.<br> https://www.opennet.ru/openforum/vsluhforumID3/135510.html#20 Fri, 06 Dec 2024 15:49:53 GMT &gt; прикольно. Т.е. взяв за основу предположение, судя по всему построенное на присутствии <br>&gt; борров-чекера (который типа защищает от CVE связанных с памятью), можно отказаться <br>&gt; от механизма каталогизации всех остальных CVE?<br><br>Разумеется нет. Нужно смотреть на дырявость языка - сколько CVE лепят бракоделы.<br>Вот почему в списке кроме раста нет go, haskel, python? А потому что они не дырявые.<br>А к си и с++ (как наследник угребищного си) доверия нет - у них cve как блох на дворняге.<br><br>Почему добавили java - не знаю.<br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/135510.html#14 Fri, 06 Dec 2024 15:12:12 GMT прикольно. Т.е. взяв за основу предположение, судя по всему построенное на присутствии борров-чекера (который типа защищает от CVE связанных с памятью), можно отказаться от механизма каталогизации всех остальных CVE?<br>