Технологический Болт Генона
8.26K subscribers
3.05K photos
372 videos
214 files
3.91K links
До Декарта никогда не существовало рационализма.

Музыкальный Болт Генона: @mus_b0lt_Genona
Мемный Болт Генона: @mem_b0lt_Genona
Кадровый Болт Генона @kadr_b0lt_Genona

Обратная связь: @rusdacent
Download Telegram
Тут пришли подтверждения, так сказать, что VMware реально под ударом из-за бага с Log4j
https://twitter.com/tnpitsecurity/status/1469429810216771589

Вот страница от самой VMware, где можно отслеживать статус по продуктам, а так же узнать о workaround'е (не для всего есть)
https://www.vmware.com/security/advisories/VMSA-2021-0028.html

В общем, если у вас Варя наружу торчит, то пора меры принимать, потому что 10/10 критичность.
Forwarded from Блог*
#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 есть ещё интересные комментарии.
👍1
Forwarded from oleg_log (Oleg Kovalov)
А вот это даже смешно. Лог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
👍1
Forwarded from Vladimir Sitnikov
Ну что, товарищи.
Я пошёл захватывать власть в log4j 1.x: https://lists.apache.org/thread/mx667xg7rps5b7rhgr7pojmj26o9qzq7

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

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

Экосистема разработки в 2021 году
https://www.jetbrains.com/ru-ru/lp/devecosystem-2021
Forwarded from k8s (in)security (D1g1)
Опубликовано видео моего выступления "Kubernetes Resource Model (KRM): Everything-as-Code" с VK Kubernetes Conference, которая прошла 9 декабря 2021 года.

Именно так я (и многие в индустрии) видят правильное использование Kubernetes, которое позволяет на максимум раскрыть его возможности.

Доклад не про безопасность, но все это справедливо и для безопасности:
- Security as Code
- Policy as Code
- Compliance as Code

На мой взгляд только так можно достичь высокого уровня безопасности в условиях:
- частых и постоянных изменений микросервисов,
- разительной разницы в количестве между разработкой и ИБ,
- нескончаемых патчей 1day и 0day уязвимостей,
- набирающих обороты атак на supply chain.

Старые подходы являются реактивными, пришло время проактивных.
Нам тут в @ru_podman занесли
Forwarded from AWS Notes
​​Подкасты — «AWS на русском»:

🔸 Яндекс.Музыка
🔸 Apple Podcasts
🔸 Google Подкасты
🔸 Spotify
🔸 Anchor

#podcasts
> На поддоменах .mos.ру яростно пренебрегали ограничениями к каталогам .git.

Писал уже как-то об этом https://xn--r1a.website/tech_b0lt_Genona/2558 и повторю дежурное напоминание

Дежурное напоминание: не делайте доставку сайтов через clone/pull кода на конечном хосте (ну или хотя бы вычищайте лишнее после этого) и не кладите репы исходников в контейнер.

Взлом Госуслуг: утечка исходного кода
https://habr.com/ru/news/t/598121/
Спасибо всем, кто был и остался, спасибо всем кто подписался, спасибо всем кто делился с другими и репостил.

Ссылка на самый популярный пост
https://xn--r1a.website/tech_b0lt_Genona/2767
Как переехать с GKE на Deckhouse, чтобы разработчики этого даже не заметили. Кейс robota.ua

https://habr.com/ru/company/flant/blog/598399/