Тут пришли подтверждения, так сказать, что VMware реально под ударом из-за бага с Log4j
https://twitter.com/tnpitsecurity/status/1469429810216771589
Вот страница от самой VMware, где можно отслеживать статус по продуктам, а так же узнать о workaround'е (не для всего есть)
https://www.vmware.com/security/advisories/VMSA-2021-0028.html
В общем, если у вас Варя наружу торчит, то пора меры принимать, потому что 10/10 критичность.
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 были новыми (то есть для них исправлений не было).
А ещё авторы отличились тем, что нормально выложили материалы по исследованию.
Well-Typed Programs Can Go Wrong: A Study of Typing-Related Bugs in JVM Compilers
В этой статье авторы отмечают, что усилия в тестировании компиляторов в основном направлены на отлов некорректных оптимизаций, при этом мало кто целенаправленно занимается отловом багов в фронтендах. Авторы выбрали 320 багов, связанных с типами, среди багов компиляторов Java, Scala, Kotlin и Groovy, и разобрались с тем, как они себя проявляют, какие фичи языка используют и как они фиксятся. Вооружившись этим знанием, они написали генератор тестовых программ, который смог найти 28 багов, из них 12 были новыми (то есть для них исправлений не было).
А ещё авторы отличились тем, что нормально выложили материалы по исследованию.
www.semanticscholar.org
Well-typed programs can go wrong: a study of typing-related bugs in JVM compilers | Semantic Scholar
This study conducts the first empirical study for understanding and characterizing typing-related compiler bugs, and believes that it opens up a new research direction by driving future researchers to build appropriate methods and techniques for a more holistic…
Мы думали, что всё, но это не всё. Теперь с 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/
+
https://nvd.nist.gov/vuln/detail/CVE-2021-45046
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 под раздачу попал
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.
Из текста релиза
Так что время пойти и лишний раз проверить ваш
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.http://logback.qos.ch/news.html
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.
Так что время пойти и лишний раз проверить ваш
logback и как он используется.Вы будете смеяться (нет), но log4j продолжают насиловать и будут делать это ещё долго, так что патчить и обновляться придётся ещё долго и много
>
https://issues.apache.org/jira/browse/LOG4J2-3230
Там же в issue есть ещё интересные комментарии.
>
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
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».
Пожелайте удачи. Если кто-то хочет присоединиться — милости прошу.
Я пошёл захватывать власть в 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
Экосистема разработки в 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, которая прошла
Именно так я (и многие в индустрии) видят правильное использование
Доклад не про безопасность, но все это справедливо и для безопасности:
- Security as Code
- Policy as Code
- Compliance as Code
На мой взгляд только так можно достичь высокого уровня безопасности в условиях:
- частых и постоянных изменений микросервисов,
- разительной разницы в количестве между разработкой и ИБ,
- нескончаемых патчей
- набирающих обороты атак на supply chain.
Старые подходы являются реактивными, пришло время проактивных.
9 декабря 2021 года.Именно так я (и многие в индустрии) видят правильное использование
Kubernetes, которое позволяет на максимум раскрыть его возможности. Доклад не про безопасность, но все это справедливо и для безопасности:
- Security as Code
- Policy as Code
- Compliance as Code
На мой взгляд только так можно достичь высокого уровня безопасности в условиях:
- частых и постоянных изменений микросервисов,
- разительной разницы в количестве между разработкой и ИБ,
- нескончаемых патчей
1day и 0day уязвимостей, - набирающих обороты атак на supply chain.
Старые подходы являются реактивными, пришло время проактивных.
YouTube
Kubernetes Resource Model (KRM): Everything-as-Code
Дмитрий Евдокимов, CTO Luntry
Это доклад про YAML для YAML-инженеров и тех, кто пока что в нем не разбирается. Эксперт рассказывает, как в Kubernetes правильно смотреть на эту картину и выжимать максимум пользы для своей компании.
— О взаимосвязи ресурсов…
Это доклад про YAML для YAML-инженеров и тех, кто пока что в нем не разбирается. Эксперт рассказывает, как в Kubernetes правильно смотреть на эту картину и выжимать максимум пользы для своей компании.
— О взаимосвязи ресурсов…
Integrating Open Policy Agent (OPA) With Kubernetes
https://techblost.com/integrating-open-policy-agent-opa-with-kubernetes/
https://techblost.com/integrating-open-policy-agent-opa-with-kubernetes/
Forwarded from Maxim Levchenko
Привет, надеюсь не нарушу правил чата.
Я по теме podman и cri-o статью небольшую опубликовал, про прозрачное кеширование образов контейнеров, может кому полезно будет.
Я по теме podman и cri-o статью небольшую опубликовал, про прозрачное кеширование образов контейнеров, может кому полезно будет.
Хабр
Прозрачно кешируем несколько Container Registry в CRI-O и Podman
Возможно, вы уже активно используете CRI-O и Podman, а может только смотрите на альтернативы Docker с осторожностью. Но, как бы там ни было, альтернативные решения создают конкуренцию монополисту...
Forwarded from Флант | Специалисты по DevOps и Kubernetes
Deckhouse стала первой Kubernetes-платформой, принятой в Единый реестр российских программ для ЭВМ и БД: https://habr.com/ru/company/flant/news/t/597623/
Хабр
Kubernetes-платформа Deckhouse зарегистрирована в Едином реестре российского ПО
В минувший вторник, 21 декабря, нашу Kubernetes-платформу Deckhouse включили в Единый реестр российских программ для ЭВМ и баз данных. Пока это первое подобное решение, добавленное в Реестр по...
👍1
Forwarded from AWS Notes
Подкасты — «AWS на русском»:
🔸 Яндекс.Музыка
🔸 Apple Podcasts
🔸 Google Подкасты
🔸 Spotify
🔸 Anchor
#podcasts
🔸 Яндекс.Музыка
🔸 Apple Podcasts
🔸 Google Подкасты
🔸 Spotify
🔸 Anchor
#podcasts
> На поддоменах .mos.ру яростно пренебрегали ограничениями к каталогам .git.
Писал уже как-то об этом https://xn--r1a.website/tech_b0lt_Genona/2558 и повторю дежурное напоминание
https://habr.com/ru/news/t/598121/
Писал уже как-то об этом 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
Ссылка на самый популярный пост
https://xn--r1a.website/tech_b0lt_Genona/2767
Как переехать с GKE на Deckhouse, чтобы разработчики этого даже не заметили. Кейс robota.ua
https://habr.com/ru/company/flant/blog/598399/
https://habr.com/ru/company/flant/blog/598399/