Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.
The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.
Версия 2.15, которую вы называете "новейшей", на данный момент (28.12.2021) а) уязвима к CVE-2021-45046 б) уж точно не новейшая.
Единственный правильный вариант по исправлению уязвимости в своих приложениях на данный момент - обновление на 2.17.
Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
Про «надо помолчать» есть ещё один интересный психологический момент.
Случается, что технические специалисты воспринимают подобные ситуации как личный вызов «своему» решению и стараются искать ответ в текущей парадигме. Такая игра: придумай ответ, который максимально впихивается в ранее высказанное / существующее решение. И всё обсуждение сводится к посылу «я и раньше был прав», а вернуться на шаг назад и пересмотреть предпосылки — ментально сильно тяжелее.
Всё это напоминает градиентный метод, который приближает нас к оптимуму, но тот вполне вероятно — локальный.
В таких ситуациях время на «помолчать» имеет смысл использовать для «придумать больше одного решения», чтобы была какая-то возможность сравнивать решения, хотя бы и свои.
Может у кого есть рецепты для фасилитации подобных дискуссий?
Подскажите, кто в теме, насколько в принципе законно расшифровывать трафик трафик сотрудников? Казалось бы это должно нарушать право на тайну личной переписки, которую гарантирует Конституция РФ и никакой трудовой договор не может этого отменить.
Наша организация как раз начала внедрять подобную практики, что поломало нам весь CI, завязанный на Linux-сервера, которые, понятное дело, не в AD и знать не знали о новом корневом сертификате, которым подписано всё от GitHub до DockerHub.
Посоветуйте, как бороться с такой «безопасностью»?
Алексей, скажите, пожалуйста, есть ли у вас опыт участия в реальном проекте по разработке ПО? В т.ч. с использованием тех методологий, которые вы упомянули в статье.
Я поэтому и спросил, т.к. не в курсе положения дел, и не делал никаких утверждений.
Если вы знаете — расскажите, плз.
Популярно ли решать задачи на ФЯП? Эффективно ли с точки зрения времени выполнения (по сравнению с другими) и, собственно, самой реализации?
А вот интересно. Как обстоят дела с применимостью функциональных ЯП в ACM-like задачах, где требуется иметь очень хорошее представление о вычислительной сложности операций, которое формируется в т.ч. за счет использования явных императивных конструкций?
У нас противоположный опыт использования собственного NuGet-репозитория. Действительно, добавление еще одной точки отказа может привести к проблемам, но преимуществ оказалось больше. Возможно дело в специфике проектов. Никаких «случайных» обновлений не замечено.
А эти же 600 МБ теперь тоже тянутся, но из VCS?
Лично мне, не смотря на все сравнения и примеры, ну никак не получается «понимать» такие большие (и малые) числа. Ноликом больше или меньше с определенного момента не имеет принципиального значения.
Об этом, кстати, писал Дуглас Адамс, что человек просто не может представить себе и осознать реальных размеров вселенной, а изысканный способ свести его с ума — машина, которая показывает человеку масштабы вселенной и его место в ней.
У вас устаревшие данные и вы вводите людей в заблуждение.
LOG4J_FORMAT_MSG_NO_LOOKUPS недостаточно (https://logging.apache.org/log4j/2.x/security.html)
Версия 2.15, которую вы называете "новейшей", на данный момент (28.12.2021) а) уязвима к CVE-2021-45046 б) уж точно не новейшая.
Единственный правильный вариант по исправлению уязвимости в своих приложениях на данный момент - обновление на 2.17.
Модуль
log4j-api
не содержит уязвимости:На 20 декабря 2021 правильнее обновляться сразу на 2.17 в которой исправлены ещё и CVE-2021-45105.
Случается, что технические специалисты воспринимают подобные ситуации как личный вызов «своему» решению и стараются искать ответ в текущей парадигме. Такая игра: придумай ответ, который максимально впихивается в ранее высказанное / существующее решение. И всё обсуждение сводится к посылу «я и раньше был прав», а вернуться на шаг назад и пересмотреть предпосылки — ментально сильно тяжелее.
Всё это напоминает градиентный метод, который приближает нас к оптимуму, но тот вполне вероятно — локальный.
В таких ситуациях время на «помолчать» имеет смысл использовать для «придумать больше одного решения», чтобы была какая-то возможность сравнивать решения, хотя бы и свои.
Может у кого есть рецепты для фасилитации подобных дискуссий?
Наша организация как раз начала внедрять подобную практики, что поломало нам весь CI, завязанный на Linux-сервера, которые, понятное дело, не в AD и знать не знали о новом корневом сертификате, которым подписано всё от GitHub до DockerHub.
Посоветуйте, как бороться с такой «безопасностью»?
Если вы знаете — расскажите, плз.
Популярно ли решать задачи на ФЯП? Эффективно ли с точки зрения времени выполнения (по сравнению с другими) и, собственно, самой реализации?
Расскажите, плз, кто знает.
А эти же 600 МБ теперь тоже тянутся, но из VCS?
Если у кого-то есть интерес, пишите в личку.
Лично мне, не смотря на все сравнения и примеры, ну никак не получается «понимать» такие большие (и малые) числа. Ноликом больше или меньше с определенного момента не имеет принципиального значения.
Об этом, кстати, писал Дуглас Адамс, что человек просто не может представить себе и осознать реальных размеров вселенной, а изысканный способ свести его с ума — машина, которая показывает человеку масштабы вселенной и его место в ней.
Так вообще бывает? Посмотреть на другую компанию и решить работать точно так же?
Может быть получится не нарушая условий написать статью?
Про доработку под пользователей это точно, а еще бывает, что «в старой системе было не так, мы привыкли, сделайте как было».