У GitLab'а в GitLab есть замечательная репа в которой собираются CVE связанные с ним

https://gitlab.com/gitlab-org/cves

Там удобно можно следить чего новенького появляется и изменяется
Вот, например, обновление описания для CVE-2021-39923
https://gitlab.com/gitlab-org/cves/-/commit/cd66080376206983db21d30b545670290119daed

Или добавление информации о CVE-2021-39890
https://gitlab.com/gitlab-org/cves/-/commit/81afc741b4b2db7379b6dd0bd1ab0e88c57f95fb

Последняя, кстати, является критичной и затрагивает последние версии GitLab

It was possible to bypass 2FA for LDAP users and access some specific pages with Basic Authentication in GitLab 14.1.1 and above.

https://www.cve.org/CVERecord?id=CVE-2021-39890
https://vulmon.com/vulnerabilitydetails?qid=CVE-2021-39890

В связи с участившимися случаями захвата репозиториев крупных проектов и продвижения вредоносного кода через компрометацию учётных записей разработчиков, компания GitHub вводит повсеместную расширенную верификацию учётных записей. Отдельно для сопровождающих и администраторов 500 самых популярных NPM-пакетов в начале следующего года будет внедрена обязательная двухфакторная аутентификация.

С 7 декабря 2021 года по 4 января 2022 года будет произведён перевод всех мэйнтейнеров, имеющих право публикации NPM-пакетов, но не использующих двухфакторную аутентификацию, на использование расширенной верификации учётных записей. Расширенная верификация подразумевает необходимость ввода одноразового кода, отправляемого на email при попытке входа на сайт npmjs.com или выполнения аутентифицируемой операции в утилите npm.

GitHub внедряет в NPM обязательную расширенную верификацию учётных записей
https://www.opennet.ru/opennews/art.shtml?num=56304

Про безопасность разработки в большой организации

Не так давно ребята из Мимокрокодил позвали меня записать подкаст про современный DevSecOps в крупных организациях. Помимо главной темы, мы подняли концепцию AppSec/DevSecOps-платформ, путь моего развития в индустрии, влияние медийности на карьеру, а также подноготную ведения телеграм-каналов. Получилось весьма интересно:)

Предлагаю послушать:
https://podcast.ru/1505781025

#talks

Конференция в разгаре, ссылка на прямую трансляцию

https://www.youtube.com/watch?v=AQzjHRlk7AY

Трансляция с комментариями
https://facecast.net/w/xi2r3j

Программа
https://mcs.mail.ru/events/vk-kubernetes-conf

В Apache Log4j 2, популярном фреймворке для организации ведения логов в Java-приложениях, выявлена критическая уязвимость, позволяющая выполнить произвольный код при записи в лог специально оформленного значения в формате "{jndi:URL}". Атака может быть проведена на Java-приложения, записывающие в лог значения, полученные из внешних источников, например, при выводе проблемных значений в сообщениях об ошибках.

Отмечается, что проблеме подвержены почти все проекты, использующие такие фреймворки, как Apache Struts, Apache Solr, Apache Druid или Apache Flink, включая Steam, Apple iCloud, клиенты и серверы игры Minecraft. Ожидается, что уязвимость может привести к волне массовых атак на корпоративные приложения, повторив историю критических уязвимостей во фреймворке Apache Struts, который по приблизительной оценке применяется в web-приложениях 65% компаний из списка Fortune 100. В том числе уже зафиксированы попытки сканирования сети на предмет уязвимых систем.

Проблема усугубляется тем, что уже опубликован рабочий эксплоит, но исправления для стабильных веток на данный момент не сформированы. СVE-идентификатор пока не присвоен. Исправление включено только в тестовую ветку log4j-2.15.0-rc1. В качестве обходного пути блокирования уязвимости рекомендуется выставить параметр Log4j2.formatMsgNoLookups в значение true.

Критическая уязвимость в Apache Log4j 2, затрагивающая многие Java-проекты
https://www.opennet.ru/opennews/art.shtml?num=56319
+
https://github.com/tangxiaofeng7/apache-log4j-poc

ну что ж 😅

Пятница

CodeQL for Log4j

“Пятница-пятницей, а Log4j JNDI инъекцию никто не отменял :) все про нее уже в курсе, но если нет, то почитать можно тут или тут, ну или по-русски тут. Для CodeQL соответственно сразу же подъехали экспериментальные запросы: https://github.com/github/codeql/pull/7354/files
Можно уже погонять на своём коде. Сами запросы используют csv-модели, то есть разделенные точкой с запятой однострочные описания неймспейса, типа, подтипа, имени класса и еще нескольких параметров для задания source'a, sink'a и summary. Это укорачивает спецификацию этих элементов, позволяет их писать быстрее, но читать это чуть непривычнее :)»

За текст спасибо @shad0wrunner

Из чата @codeql

#dev #ops #attack #sast

Подробный постмортем падения AWS на несколько часов 7 декабря 2021:

https://aws.amazon.com/message/12721/

Кому нужна выжимка:

• Проблема была во внутренней сети AWS, где крутятся мониторинг и control plain некоторых сервисов. Поэтому сами сервисы не падали, но невозможно было внести изменения, что для некоторых сервисов, например, API Gateway оказалось равным проблемам его работоспособности (делается фикс такого поведения).

• Задержка с отображением проблем на странице статуса в том числе связана с недоступностью мониторинга в результате падения внутренней сети. Так как инженеры AWS долгое время не могли узнать (без мониторинга), что на самом деле происходит.

• Интересно отметить, что причиной послужил код, который уже несколько лет успешно крутится в проде, просто его поведение, когда он масштабируется, не было оттестировано (теперь протестировали – нет, не работает). Автоскелинг выключили, мощности хватает, как дотестируют, включат автоскелинг обратно (может быть).

Дополнительно отмечу для себя интересный факт, что S3 и DynamoDB ресурсы, которые, как и другие, не страдали во время инцидента, однако вот те, что подключены через VPC Endpoint – были недоступны. Причём, как понимаю (чего нет в постмортеме) – речь именно о (бесплатных) Gateway VPC Endpoints, в то время как (платные) Interface endpoints – не пострадали.

Итого: приятно читать столь детальный отчёт, проливающий свет на внутреннюю кухню AWS.

We want to apologize for the impact this event caused for our customers. While we are proud of our track record of availability, we know how critical our services are to our customers, their applications and end users, and their businesses. We know this event impacted many customers in significant ways. We will do everything we can to learn from this event and use it to improve our availability even further.

#postmortem

Оригинал

ZX Clive Tribute - ZX Spectrum 48 + AY Demo
https://www.youtube.com/watch?v=EaFG2AZdlD4

#prog #java #kotlin #scala

Well-Typed Programs Can Go Wrong: A Study of Typing-Related Bugs in JVM Compilers

В этой статье авторы отмечают, что усилия в тестировании компиляторов в основном направлены на отлов некорректных оптимизаций, при этом мало кто целенаправленно занимается отловом багов в фронтендах. Авторы выбрали 320 багов, связанных с типами, среди багов компиляторов Java, Scala, Kotlin и Groovy, и разобрались с тем, как они себя проявляют, какие фичи языка используют и как они фиксятся. Вооружившись этим знанием, они написали генератор тестовых программ, который смог найти 28 багов, из них 12 были новыми (то есть для них исправлений не было).

А ещё авторы отличились тем, что нормально выложили материалы по исследованию.

Мы думали, что всё, но это не всё. Теперь с log4j ещё долго время не слезут. Пока "все" баги там не найдут.

Log4Shell Update: Second log4j Vulnerability Published (CVE-2021-44228 + CVE-2021-45046)
https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/
+

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific vulnerability. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

https://nvd.nist.gov/vuln/detail/CVE-2021-45046

В связи с этой всей эпопеей с логами в Java под раздачу попал logback

Задача
Possibility of vulnerability
https://jira.qos.ch/browse/LOGBACK-1591

И обновление, где аж большими красными зелёными буквами написали

> We note that the vulnerability mentioned in LOGBACK-1591 requires write access to logback's configuration file as a prerequisite. Please understand that log4Shell/CVE-2021-44228 and LOGBACK-1591 are of different severity levels.

Из текста релиза

In response to LOGBACK-1591, we have disabled all JNDI lookup code in logback until further notice. This impacts ContextJNDISelector and <insertFromJNDI> element in configuration files.

We note that the vulnerability mentioned in LOGBACK-1591 requires write access to logback's configuration file as a prerequisite. Please understand that log4Shell/CVE-2021-44228 and LOGBACK-1591 are of different severity levels. A successul RCE requires all of the following conditions to be met:

- write access to logback.xml
- use of versions < 1.2.8
- reloading of poisoned configuration data, which implies application restart or scan="true" set prior to attack

As an additional extra precaution, in addition to upgrading to logback version 1.2.8, we also recommend users to set their logback configuration files as read-only.

http://logback.qos.ch/news.html

Так что время пойти и лишний раз проверить ваш logback и как он используется.

Вы будете смеяться (нет), но log4j продолжают насиловать и будут делать это ещё долго, так что патчить и обновляться придётся ещё долго и много

> If a string substitution is attempted for any reason on the following string, it will trigger an infinite recursion, and the application will crash: ${${::-${::-$${::-j}}}}

https://issues.apache.org/jira/browse/LOG4J2-3230

Там же в issue есть ещё интересные комментарии.

А вот это даже смешно. Лог4ж в Xcode https://developer.apple.com/forums/thread/696785

Я как-то пропустил момент, что в ноябре были выложены доклады с SREcon21

https://www.youtube.com/playlist?list=PLbRoZ5Rrl5lcjhxsp-V3-xJnHQpWLllRS

Программа тут
https://www.usenix.org/conference/srecon21/program

Ну что, товарищи.
Я пошёл захватывать власть в log4j 1.x: https://lists.apache.org/thread/mx667xg7rps5b7rhgr7pojmj26o9qzq7

Всё-таки оказалось, что коммитеры log4j вообще не хотят выкатывать новые вериии 1.x, а напирают, что «надо сделать идеальный compatibility wrapper и заставить всех обновиться на 2.x».

Пожелайте удачи. Если кто-то хочет присоединиться — милости прошу.