Пост#security #docker #devops и немного #всратость

#security #docker #devops и немного #всратость Заметка носит скорее исследовательский и развлекательный характер. Никакого поиска правды, настаивании на этом мнении или призыва к действию. Однажды приходит алерт от инфобеза: критическая уязвимость, CVE-666lupa666pupa в zlib, надо фиксить. Смотрю: zlib - это какая-то неизвестная мне хрень. Возможно и инфобезе, может и никому. Дебиан букворм держит zlib1g 1.2.13, в которой этот CVE есть. Триви его видит, алерт красный, белки-истерички кричат и бегают по кругу. Говорю инфобезу: это нас не касается, камон. Во-первых, статус в самом триви - will not fix. Во-вторых, есть флаг --ignore-unfixed, который именно для этого и придуман. Мы в тот момент работали без этого флага - по какой-то причине, уже не помню. Поэтому жалобка и прилетела. Поставили флаг + игнор файл для другой неэксплуатируемой штуки и вроде отстали от нас. В-третьих, сканер это опционально у нас, ну чо ты, какие блокеры, иди чай попей. Пока я пытался всё это объяснить, у меня в голове крутился вопрос: а насколько вообще можно доверять тому, что триви находит или не находит? Решил потом проверить. - - - Тест первый. Пересобрал образ, вручную скомпилировал из сорсов прямо в имадж: RUN apt-get update && apt-get install -y build-essential wget \ && wget https://github.com/madler/zlib/releases/download/v1.3.1/zlib-1.3.1.tar.gz \ && tar -xf zlib-1.3.1.tar.gz \ && cd zlib-1.3.1 \ && ./configure \ && make \ && make install \ && ldconfig \ && cd .. \ && rm -rf zlib-1.3.1 zlib-1.3.1.tar.gz \ && apt-get purge -y build-essential wget \ && apt-get autoremove -y Проверяю внутри контейнера - 1.3.1 там: $ ls -la /usr/local/lib/libz* lrwxrwxrwx /usr/local/lib/libz.so -> libz.so.1.3.1 lrwxrwxrwx /usr/local/lib/libz.so.1 -> libz.so.1.3.1 -rwxr-xr-x /usr/local/lib/libz.so.1.3.1 $ ldconfig -p | grep libz libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 <- dpkg-пакет, 1.2.13 libz.so.1 => /usr/local/lib/libz.so.1 <- скомпилированная 1.3.1 Запускаю триви - снова цве критикал 😬 Вероятно триви читает /var/lib/dpkg/status - базу пакетного менеджера. Что реально лежит в /usr/local/lib его не интересует. Скомпилированная версия для него невидима. Безопасность) Наверняка это не баг - это архитектурное решение, бинарный анализ каждой библиотеки был бы на порядки дороже. Но это означает, что сканер сообщает о CVE на основе базы пакетного менеджера, а не того, что реально резолвит линкер в рантайме - а это, вообще-то, отдельный вопрос, который одним ldconfig -p не закрыть. Ну не глупость ли, а? Сканер говорит "уязвимость есть" - а есть ли она реально в работающем процессе, это уже совсем другая история, и я её тут не проверял. Тест второй. Раз уж проверяем, проверим до конца. Берём образ с реальной уязвимостью - log4shell FROM alpine:3.18 WORKDIR /app RUN apk add --no-cache openjdk8-jre-base wget RUN wget https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.jar && \ wget https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.14.1/log4j-api-2.14.1.jar CMD ["/usr/bin/java", "-version"] Триви весело находит три CVE: log4shell, CVE-biba, CVE-boba. Всё верно. Теперь берём тот же JAR с уязвимым байткодом и просто меняем строку версии в метаданных внутри архива: RUN mkdir temp && \ unzip log4j-core-2.14.1.jar -d temp && \ sed -i 's/version=2.14.1/version=2.17.1/g' \ temp/META-INF/maven/org.apache.logging.log4j/log4j-core/pom.properties && \ cd temp && \ zip -r ../mylog4j-core.jar . && \ cd .. && \ rm -rf temp log4j-core-2.14.1.jar RUN mv log4j-api-2.14.1.jar mylog4j-api.jar Байткод не тронут, язвимый код на месте. Только pom.properties теперь говорит версию 2.17.1. trivy image test:latest --severity HIGH,CRITICAL Total: 0 (HIGH: 0, CRITICAL: 0) Триви для джавы читает мета pom.properties внутри JAR. Не байткод, не хэши классов - метаданные, так что поменял строку и тут же сканер доволен 😀. Сканер говорит "всё чисто" - а уязвимость есть 🤣. Тест третий. Проверим ещё - го бинари. Триви умеет читать зависимости прямо из скомпилированного го бинаря. В каком-то файле есть секция .go.buildinfo, куда компилятор записывает все модули с версиями. Это реально удобная фича - никаких go.sum в образе не нужно, сканер находит всё сам. Берём минимальное приложение с намеренно старой версией: golang.org/x/net v0.0.0-20210405180319-a5a99cb37ef4 Триви после сборки находит 20 CVE только в го депенденси. Теперь удаляем секцию билдинфо из бинаря с помощью objcopy: RUN go build -o myapp . \ && apt-get update && apt-get install -y --no-install-recommends binutils \ && objcopy --remove-section=.go.buildinfo myapp myapp-stripped \ && apt-get purge -y binutils && apt-get autoremove -y Бинарь работает и функционально идентичен, проверяю: $ objdump -s -j .go.buildinfo /myapp-stripped objdump: section '.go.buildinfo' mentioned in a -j option, but not found in any input file скан: trivy image test-go-stripped:latest --severity HIGH,CRITICAL Total: 9 (HIGH: 6, CRITICAL: 3) только пакеты операционки Все 20 гошные CVE исчезли, остались только 9 от Дебиан, которые will not fix. Безопасность 😎 На мультистейдже с финальным FROM scratch это тоже легко обходится - например, через upx, который пакует бинарь в свой формат и триви перестаёт читать билдинфо. Суть та же: все варианты работают, сканер молчит. Безопасность 😁 Так что с итогом: Да ничо, это просто было увлекательно. Изначальная проблема была решена чисто флагом вообще то. А вопросы остались. Я не говорю, что CVE сканеры имаджей бесполезны, наоборот - они полезны в штатных сиуациях. Они находят реальные проблемы, они дают точку отсчёта, они вполне работают как первый фильтр. Но некоторые сканеры, такие как триви, дают лишь аппроксимацию на основе сигнатур и метаданных. И в целом они не гарантируют ничего - ни того, что уязвимость есть, ни того, что её нет. Финальное решение - применимо ли эта CVE к вашей системе, надо ли бежать чинить прямо сейчас или игнорировать месяцами - пока принимает человек. Это не игнорирование безопасности - как по мне это и есть работа с безопасностью. - - - Эта заметка - аккуратно переработанный текст моих старых сообщений в чате куберентис ру, но без обсценной лексики 😬.