Исследование, проведенное совместными усилиями компаний Sonatype и Aspect Security, показало (http://www.zdnet.com/blog/open-source/study-more-than-50-of-...), что более 50 процентов крупнейших компаний из списка Fortune 500 используют программное обеспечение, построенное с использованием устаревших версий открытых фреймворков и библиотек, содержащих незакрытые уязвимости.Отчет (https://www.aspectsecurity.com/blog/the-unfortunate-reality-.../), основанный на исследовании 113 миллионов загрузок открытого ПО 60 тысячами коммерческими, государственными и некоммерческими организациями, показал, что около 46 миллионов из них приходилось на уязвимые библиотеки и фреймворки, среди которых Google Web Toolkit, Spring MVC, Struts 1.X и Hibernate. Фреймворк Struts 2, содержащий критическую уязвимость, был загружен около миллиона раз 18 тысячами корпораций.
Исследование выявило, что 37 процентов из всех загруженных версий наиболее популярных открытых компонентов содержали известные уязвимости, тогда как среди менее популярных компонентов уязвимости были найдены в 47% загрузок. Также исследование показало, что только 32% организаций, использующих открытые библиотеки и фреймворки в своих продуктах и сервисах, следят за их своевременным обновлением после обнаружения уязвимости.
В заключении исследования авторы делают вывод, что виной тому, что многие компании продолжают использовать небезопасные открытые компоненты даже после обнаружения уязвимости, служит тот факт, что в используемых открытых приложениях просто нет соответствующих средств для уведомления разработчиков о найденной уязвимости и своевременного автоматического обновления.
Некоторые из разработчиков открытых проектов отреагировали на это заявление. Так, Ренэ Гилэн (Rene Gielen) из комитета по управлению проектом Apache Struts сказал, что как и любое ПО, открытые фреймворки и библиотеки просто не могут не содержать уязвимостей и что его команда прикладывает все усилия для своевременного извещения об уязвимости и публикации исправленной версии. Но, как подчеркнул Ренэ, система уведомлений и автоматического обновления по определению не может быть встроена в такие продукты как веб-фреймворки и библиотеки из-за специфики их использования.
Марк Томас (Mark Thomas) заявил, что эти цифры вполне ожидаемые и они отнюдь не относятся только лишь к открытому ПО. Также он подчеркнул, что риски, связанные с этими уязвимостями на самом деле намного ниже, чем предполагают исследователи, так как многие организации осознанно не идут на обновления в связи с проблемами и затратами, которые они могут за собой повлечь, предпочитая использовать различные методы блокирования этих уязвимостей с помощью настроек, не допускающих их эксплуатацию. В качестве примера Марк привел установку веб-сервера Apache в режиме реверс-прокси перед Tomcat, который позволяет не допустить использование некоторых найденных уязвимостей в Tomcat.
URL: http://www.zdnet.com/blog/open-source/study-more-than-50-of-...
Новость: http://www.opennet.me/opennews/art.shtml?num=33457
Опастность открытого ПО!!! Get the facts!!!
Это если не читать текст новости.
В ней же поясняется, что опасность от этих уязвимостей просто-напросто оценивается специалистами как недостаточная для того, чтобы строго следить за обновлениями и рисковать нарваться на регрессию.
За этими уязвимостями следят дистрибутивы и выпускают обновления безопсности (с разной степенью оперативности) Чего там все эти корпоративные юзеры качают и почему не последних версий (сознательно выбирают более старые версии?) - вопрос. Ради совместимости там где нет обновлений безопасности и вообще репов?
> За этими уязвимостями следят дистрибутивы и выпускают обновления безопсности (с разной
> степенью оперативности) Чего там все эти корпоративные юзеры качают и почему
> не последних версий (сознательно выбирают более старые версии?) - вопрос. Ради
> совместимости там где нет обновлений безопасности и вообще репов?Че за бред? Указанные в новости фрейморки относятся к Web-технологиям. Что использование Struts, что использование GWT в принципе не пакетируются в Linux репозитории. Они являются частью приложения, а не внешней либой с которой можно слинковаться.
Стратс это сервлет который перефигачивает файлы из вида описания в то, что идет клиенту. Он же отвечает за связывание экранных форм и корректное преобразование типов... или Exception в ответ на попытку SQL-injection.
GWT вообще компиляет исходный код в JavaScript код, который дальше исполняется на клиенте.
По сути что Struts, что GWT имеют сложность на уровне интерпретатора PHP, но поскольку встраиваются в приложение, то вынос их как внешних либ затруднен.
> Что использование Struts, что использование GWT в принципе не пакетируются в Linux репозитории.
ты уверен, что эти (да и не только эти) фреймоворки в дистрибутиве будут актуальны для веб-разработки?
сколько себя помню, у нас для приложений использовались свои сборки либ и фреймворков
man ирония
Количество загрузок - очень синтетическое число.
Например, можно 1 раз скачать последнюю версию фреймворка и залить в svn/git.
Остальные разработчики получат её после обновления рабочей копии.
Количество загрузок скорее показывает количество компаний, которые не так сильно используют систему контроля версий.
А если в компании один раз скачали старую версию, засунули в git, и новые версии не качают, это на загрузках не скажется.
И анализ загрузок этого не покажет.
Хотя компания будет использовать древнюю библиотеку.
Так что, в данном случае, анализ загрузок плохо подходит.Далее, исследователи не учитывают такой фактор, как допиливание под себя.
Если в коде библиотеки уже полно своего кода, перейти на новую версию может быть физически невозможно (т.е. затраты на переход превысят разумные мерки).
Например, в redhat было ядро 2.6.18.
С одной стороны, древнее - это не то слово)
С другой стороны - заплатки, обновления и бекпорты новых фич туда прилетали оперативно.
И взять и "обновить ядрышко" так просто нельзя.
Вполне возможно, что в обновленном ядре все ещё есть дырки, которые уже закрыли в 2.6.18 от redhat.Вывод о том, что библиотека должна сама сигнализировать - показывает что люди очень далеки от производства.
Как они себе это представляют?
jquery или zend должны мигать в трее у разработчика с предложением обновиться?Как узнать об обновлении?
Послать запрос сервер и узнать номер последней версии.
Как скриптовые библиотеки смогут узнать об обновлении?
При каждой инициализации слать запрос на сервер.
И выдавать сообщение "вышла новая версия! обновитесь!".
Особенно интересно, как это будет делать та же jquery)
А если libpng будет при каждом обращении слать http запросы, её сразу сочтут троянской.
Про быстродействие можно сразу забыть.Проблема есть.
Но если исследовать количество загрузок, можно получить неверный вывод о размерах проблемы.
И лечить проблему надо совсем не так, как предлагают.
Как предлагают - это пример, как лечить не надо)
А почему, собсссно, об этом должны беспокоиться пользователи? Или даже пидо^Wпрограммисты, использующие фреймворки/библиотеки? ИМХО об этом должно свербить в ж^Wголове у разрабов инструментов, равно как и создание адекватной инфраструктуры обновлений. Двунаправленной. Как-никак, в 21м веке живем.
а почему, собственно, об этом должны заботиться разработчики? они пишут, имеют багтрекеры, выпускают релизы. если кто-то хочет дополнительного сервиса — он платит деньги и получает этот сервис.впрочем, я вижу, что ты недоволен такой ситуацией; так тебе и карты в руки! иди в любой проект и занимайся там созданием такой структуры. ведь ты же уверен, что это обязаны делать бесплатно? покажи пример, займись. глядишь — другие тоже подтянутся.
> А почему, собсссно, об этом должны беспокоиться пользователи? Или даже пидо^Wпрограммисты,
> использующие фреймворки/библиотеки? ИМХО об этом должно свербить в ж^Wголове у разрабов
> инструментов, равно как и создание адекватной инфраструктуры обновлений. Двунаправленной.
> Как-никак, в 21м веке живем.А как разрабы jquery смогут обновить jquery в Вашем закрытом git репозитории?
Предложите двунаправленный вариант.
это же очевидно: надо взять кого-нибудь из них на работу.
Нет, положительно, сегодня наш Кэп в ударе. Эталонный капитан :).
Ммм... а подписные рассылки оповещений по емылу или рсс религия не позволяет?
Просто большинство ОС проектов даже не задумываются о том, что можно сделать публичные оповещения, используя стандартные механизмы (емыл, рсс...). Можно ведь просто подписчикам слать вышла версия х.у. исправлены уязвимости: ...
Не редко внедрить патчи в "свою" версию не составляет труда. В любом случае получение свежей информации о состоянии проекта полезно. И рассылку можно делать автоматическими скриптами по коммитам (понятно, что не каждый коммит интересен, это уже можно задать в скрипте, например, по наличию ключевого слова или по наложению нового тега, зависит от внутренних правил разработчика, можно даже несколько уровневую рассылку сделать, при желании).
Понятно, что если "юзер" дебил, и не способен подписаться на рассылку это не поможет, но благо мир не только из идиотов состоит:)Не спора ради, но просто отмазки типа это не реализуемо, и т.п. - это просто бред.
делай! а если ты этого делать не хочешь — то почему кто-то другой должен?
Из списка Fortune 500?Будьте среди лучших — используйте версии открытого ПО с известными уязвимостями!
Спасибо, посмеялся :D
Почему бы не использовать клиент обновлений, который сможет проверять репозиторий на наличие новых commit/push в ветке. Например для скриптового LUA есть CURSE-client.
> для скриптового LUAоткуда в Limited User Access скрипты?!
> Почему бы не использовать клиент обновлений, который сможет проверять репозиторий на наличиеПотому что никто из разрабов не хочет в свое ЛИЧНОЕ ВРЕМЯ проверять какой из JS скриптов отвалился при каждом минорном апдейте. А в рабочее РМ может сказать нах - бюджет подписан на 2 месяца разработки, значит через 2 месяца выпуск должен быть.
PS подпишут другой бюджет или начнут платить за постоянную поддержку или секьюрити саппорт - тогда да. Только очень мало какие компании согласны за это платить.
Проприетарщина во всей своей красе. Вместо того чтобы поставить нормальный дистрибутив и получать обновления на халяву, они все качают, компилят вручную... вообщем сначала надо в консерватории исправлять.
Я тоже сначала так подумал... Потом понравилось и подумал ещё.1) Если софт вебовский - то никакой энтерпрайз-дистрибутив за ним не успеет, а багфикс-версии для такого софта делать обычно не модно. То есть для спринга они, конечно, будут - а вот jQuery какой-нибудь обязательно притащит кроме багфиксов какие-то изменения.
2) Допустим у нас есть репозиторий. Но библиотеки обычно растаскиваются по каталогам проектов, и влёгкую в разных рпоектах могут быть разные версии одной библиотеки. Из известных мне такое только гента съест более-менее спокойно, но гуенту на вебовский продакшн лепить - это явный перебор.
Так что это не столько проприетарщина сколько отсутствие единого стандартного механизма, пригодного для веб-софта.
> Я тоже сначала так подумал... Потом понравилось и подумал ещё.
> 1) Если софт вебовский - то никакой энтерпрайз-дистрибутив за ним не успеет,
> а багфикс-версии для такого софта делать обычно не модно. То есть
> для спринга они, конечно, будут - а вот jQuery какой-нибудь обязательно
> притащит кроме багфиксов какие-то изменения.интересно как можно сделать Linux-подходящую либу из JavaScript кода? учитывая, что JS не вызывается на сервере, а передается на исполнение клиенту. И уже работая на клиенте вызывает специфические для проекта сервисы.
Получается, что JS либу придется бить на части. Одна лежит в пакете (если его можно создать), а другая все равно впихивается в проект чтобы сконфигурировать работу с сервером, настроить UI и синхронизировать API между сервером и JS библиотекой.
Это конечно все туфта. За актуальностью библиотек следят производители дистрибутивов, которые безусловно профессиональнее отдельно взятого админа Васи.
Настоящая же беда с теми разработчиками софта, которые вместо самих библиотек используют копипаст из тех же библиотек. Ну и естественно, когда библиотека обновляется, то копипастный код не обновляется.
Одна радость, что так поступают, как правило виндозные разработчики.
а остальные 146 - 50% = 96% компаний из списка Fortune 500 используют уязвимое закрытое ПО?
Нет. Неуязвимое открытое!
> а остальные 146 - 50% = 96% компаний из списка Fortune 500
> используют уязвимое закрытое ПО?Голоса разделились.
20% - неуязвимое, закрытое
30% - неуязвимое, открытое
40% - уязвимое, закрытое
и, с небольшим отрывом, уязвимое открытое победило на выборах, набрав 50% =)
>Исследование, проведенное совместными усилиями компаний Sonatype и Aspect Security, показало, что более 50 процентовдевелоперов уроды. тоже мне новость.
Если криворукий столяр регулярно попадает себе молотком по пальцам, то виноват в этом молоток, который не предупреждает столяра о возможном соударении.
Да, конечно.
За свой продукт отвечать самому сейчас уже не модно.
>Если криворукий столяр регулярно попадает себе молотком по пальцам, то виноват в этом молоток, который не предупреждает столяра о возможном соударении.Несколько неточно. Молоток крайним сделать не получится. А вот насчет производителей молотка ..
Хочу заметить что компания Sonatype которая производила данное исследование- разработчик maven (см. http://www.apache-maven.ru/)
в maven'е есть репозиторий библиотек который позволяет управлять версиями продуктов, и в том числе использовать последние версии в автоматическом режиме.
ну тоесть все библиотеки перечисленные java библиотеки: Google Web Toolkit, Spring MVC, Struts 1.X Hibernate, Struts 2 можно было бы легко обновить до последних весии указав в в pom.xml версию "LATEST"
> ну тоесть все библиотеки перечисленные java библиотеки: Google Web Toolkit, Spring MVC,
> Struts 1.X Hibernate, Struts 2 можно было бы легко обновить до
> последних весии указав в в pom.xml версию «LATEST»ага. я так понимаю, у ребят есть навороченый AI, который, вдобавок, починит весь код, сможет опознать трюки и workaround'ы для прошлых версий, найдёт в новых баги и внесёт в код трюки и workaround'ы для текущих версий и так далее. не понимаю только, почему такая крутая компания ещё не захватила весь рынок ПО: у них же есть искусственный программист, на основе которого можно нарисовать кнопку «сделай мне хорошо!»
если для работы с библиотекой нужно использовать трюки и workaround'ы в заметном количестве то это плохая библиотека.Правильно если сначала происходит сборка приложения(возможно автоматическая с выкладыванием на тестовый сервер), потом тестирование, и только потом выкладывание новой версии на продакшен
> если для работы с библиотекой нужно использовать трюки и workaround'ы в заметном
> количестве то это плохая библиотека.я очень рад, что в твоём идеальном мире этого никогда не надо, и можно использовать только идеальные библиотеки. жаль, что в нашем мире такое получается далеко не всегда. а если есть ещё и 3rd-party код, который требует конкретных версий…
в общем, за пределами локалхоста и приветмира с идеальностью большие проблемы.
работал со Spring, вручную обновлял версии в pom.xml, новые ошибки давали о себе знать порядка 1 раза за 10 апдейтов.
Вообще инфраструктура для для обновлений безопасности (только беопасности, без обновления функционала) не создана. Вполне могу представить что обновления безопасности применяются в автоматическом режиме для проекта, автоматически тестируются например c с помощью selenium и выкладываются в продакшен.PS сейчас использовать версию "LATEST" в большом проекте признаюсь, да, рискованно, (особенно если в проекте используется больше зависимых 100 библиотек - могут возникнуть конфликты версий)
вот это всё, тащемта, должны решать специальные люди, задача которых — отслеживать дырки и фиксы, своевременно всё обновлять и бить по рукам девелоперов, если что-то не заработало. но, как я уже писал, проприерасты жадные, как все чатлане.я, если чо, тоже не совсем теорезирую по поводу апдейтов. правда, не веб-библиотек, но какая, в принципе, разница?
натурально, в проекте должно быть жестоко форсировано правило «любой хак/workaround помечается специальным видом комментария (для грепования) и подробно поясняется, что, как и почему». но даже это правило не помогает, потому что люди не идеальны, и иногда пишут подобные куски кода чисто автоматически (или даже не знают, что на самом деле написали хак).
хочу в идеальный мир! как дополнительный бонус — я тоже там буду писать идеальный код.
> хочу в идеальный мир! как дополнительный бонус — я тоже там буду писать идеальный код.Зачет, зачет. На правах trolling-lite, начни с себя: даешь идеальный код сегодня?! :)
> Зачет, зачет. На правах trolling-lite, начни с себя: даешь идеальный код сегодня?!
> :)нененене, только после телепортации меня в идеальный мир! я там тоже автоматически стану идеальным же. а тут, в реальном, увы — не получается, хоть я и стараюсь. потому и хочу туда, где даже гадят фиалками.
> вот это всё, тащемта, должны решать специальные люди, задача которых — отслеживать
> дырки и фиксы, своевременно всё обновлять и бить по рукам девелоперов,
> если что-то не заработало. но, как я уже писал, проприерасты жадные,
> как все чатлане.проприерасты жадные, ага, а ты похоже любишь много работать, тебе бы только пропатчить бы десяток десяток другой опенсорсных проектов и как бонус - погадить фиалками :)
> проприерасты жадные, ага, а ты похоже любишь много работать, тебе бы
> только пропатчить бы десяток десяток другой опенсорсных проектов и
> как бонус — погадить фиалками :)типичная логика. ты тоже не можешь понять, что я как раз предлагаю то, где меньше геморроя *всем*.
странно: многие люди отчего-то уверены, что слесарь одновременно должен являться и пекарем, и сапожником, и профессором математики. более того — всё это он должен делать одновременно и на одинаково высоком уровне. такую ситуацию эти люди называют, отчего-то, «меньше работать». вдобавок сильно удивляются, когда не могут найти подобного специалиста на зарплату в три с половиной копейки.
> и только потом выкладывание новой версии на продакшенС непременным jre нужной версии в пузе, угу.
> С непременным jre нужной версии в пузе, угу.это к чему я не понял..
фиксы безопасности к jre/jdk тоже нужны.
> в maven'е есть репозиторий библиотек который позволяет управлять версиями продуктов,Слушай, дядя, если какой-то проприерас не может освоить уже наконец пакетный манагер и обновления без отвалов башки - может быть, он сам себе злобный баклан?
репозиторий библиотек в maven изначально создан для компиляции и сборки программ, управлениям и обновлением зависимостей(библиотк и фреймворков) а не для обновлений конечных продуктов.Кстати у пакетных менеджеров есть недостаток - их много и они не совместимые. репозиторий maven можно использовать не только на любом линуксе но и на офтопике. И всё без каких либо изменений.
> Кстати у пакетных менеджеров есть недостаток - их много и они не
> совместимые.это решается очень просто: унификацией используемых систем. если у тебя зоопарк систем, то тут никто не поможет, только гильотина.
>никто не поможет, только гильотина.или любое другое кросплатформенное решение :)
>>никто не поможет, только гильотина.
> или любое другое кросплатформенное решение :)для пакетов. ага. если на всех системах пакеты одинаковые -- это, вообще-то, одна и та же система. даже пакеты для вебни иногда должны знать, на какую систему их тащат (или содержать в себе 100500 скриптов подстройки).
а так-то и apt можно под винду портануть, только зачем?