Поиск по сайту

bit.samag.ru

Web

Рассылка Subscribe.ru

подписаться письмом

Вход в систему


Запомнить меня
Регистрация Забыли пароль?

О журнале

Ваше мнение

Статьи

Общие тенденции и тренды

Архив

Мероприятия

Календарь мероприятий

ноябрь

2024

показать все

Новости партнеров

14.11.2024

Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость

14.11.2024

RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза

14.11.2024

Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium

14.11.2024

ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве

08.11.2024

Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов

показать все

Статьи

21.11.2024

ИИ: маршрут не построен, но уже проектируется

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

28.09.2024

Чем страшен ИИ, и с чем его едят

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

18.04.2024

5 способов повысить безопасность электронной подписи

18.04.2024

Как искусственный интеллект изменит экономику

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

показать все

Уязвимости в лицензиях СПО

Главная / Архив номеров / 2018 / Выпуск №08 (81) / Уязвимости в лицензиях СПО

Рубрика: Тема номера / СПО для бизнеса

Андрей Савченко, ведущий программист «Базальт СПО»

Уязвимости в лицензиях СПО

Лицензии на программное обеспечение можно рассматривать как программы. Как и любые программы, лицензии не идеальны и содержат уязвимости, которые эксплуатируются злоумышленниками в целях ограничения прав и свобод пользователей и разработчиков. Ситуация осложняется тем, что из-за недоработок в лицензиях можно формально их выполнить, но нарушить суть и основную идею

Представленные материалы излагаются в надежде, что будут полезны, но автор отмечает, что данная работа не является официальной юридической консультацией и что высказывается личная точка зрения автора на освещаемые проблемы.

Четыре свободы программного обеспечения

Философия свободного программного обеспечения (СПО) определяет четыре свободы пользователей [1]:

Свобода использования в любых целях.
Свобода изучения и модификации.
Свобода копирования.
Свобода распространения модифицированных версий.

В более простом и наглядном виде эти свободы отражены на рис. 1 [2]. Эти свободы – это то, что разработчики хотят защитить свободными лицензиями. Важно напомнить, что свободная не означает бесплатная, а наличие исходного кода еще не означает, что это свободное программное обеспечение.

Рисунок 1. Философия свободного программного обеспечения определяет четыре свободы пользователей

По мере роста сложности лицензий на программное обеспечение они сами приобретают признаки программы, поскольку они описывают набор правил и алгоритмов по использованию программного обеспечения. Лицензии развиваются, выходят новые версии и варианты, возникают вопросы наследования и совместимости. Как и любое программное обеспечение, лицензии не идеальны, они содержат как архитектурные ошибки, так и проблемы реализации, поскольку при разработке лицензии невозможно предусмотреть все краевые случаи и особые ситуации, которые могут возникнуть при ее использовании.

Взаимодействие основных свободных лицензий показано на рис. 2 [3]. Здесь приведены далеко не все существующие лицензии, но важно отметить четыре класса свободных лицензий:

Суть в том, что пользователи передают свои данные на удаленный сервис и получают результат. При этом у них нет никакого контроля, как их данные обрабатываются, нет даже бинарных файлов соответствующих программ. Это полное отсутствие всех четырех свобод, но лицензии здесь почти бессильны

Пермиссивные (разрешающие) лицензии. Эти лицензии накладывают лишь незначительные ограничения на то, как можно использовать код: например, запрещают использовать имена авторов или организаций, создавших код, для продвижения производных продуктов (лицензии семейства BSD) или запрещают предъявлять к авторам кода патентные иски (лицензии семейства Apache). Однако при соблюдении этих требований программный код можно использовать как в свободных, так и в закрытых, проприетарных программах.
Слабый копилефт (слабо защищающие лицензии) направлены на защиту четырех свобод программного обеспечения, упомянутых ранее. В частности, они запрещают совмещать код под данными лицензиями с кодом под менее строгими лицензиями, но разрешают линковку (динамическое связывание объектных файлов) с любым другим программным обеспечением. Эти лицензии чаще всего применяются для библиотек в целях обеспечения наиболее широкой аудитории пользователей. Данный класс лицензий представлен, в частности, лицензиями семейств LGPL и MPL.
Строгий копилефт (сильно защищающие лицензии) обеспечивают строгую защиту четырех свобод, не позволяя как использование кода в приложениях под более разрешающими или проприетарными лицензиями, так и линковку объектных файлов с ними, стимулируя тем самым использование GPL в производных приложениях. Использование данных лицензий рекомендуется FSF.
Лицензии, обеспечивающие сетевую защиту. Лицензии GPL и LGPL регламентируют использование кода при распространении бинарных или исходных файлов третьим лицам, т.е. если код используется несовместимым образом, но полученные программы никому не передаются, то это не нарушает GPL/LGPL. Создается проблема, когда берется свободный код, улучшается и дорабатывается, а затем на его основе создается сетевой сервис, обслуживающий клиентов; при этом исходный код не выкладывается, что законно, но нарушает дух лицензий GPL. Поэтому была создана новая лицензия Affero GPLv3 (AGPLv3), которая позволяет защитить свободу пользователей получать и применять код программного обеспечения, которым они публично и удаленно пользуются.

Рисунок 2. Взаимодействие основных свободных лицензий

Как мы теряем нашу свободу

Итак, на бумаге все выглядит неплохо. Но в реальности наши свободы во многом ограничиваются. Почему это происходит?

Во многих сферах ограничение свобод находится вне возможностей, регулируемых лицензией, например:

Прошивки и микрокод устройств: они выполняются на специализированном оборудовании (сетевые, видеокарты, микрокод процессора). Почти все это программное обеспечение закрытое, хотя оно выполняет критически важную функциональность и создает риски безопасности.
Экосистема мобильных устройств. Найти телефон со свободными ключевыми программными компонентами очень сложно; таким образом, звонки, контакты, sms и иные виды коммуникации находятся под угрозой скрытого сбора и неправомерного использования.
SaaS (Software as a Service) – программное обеспечение как платформа. Суть в том, что пользователи передают свои данные на удаленный сервис и получают результат. При этом у них нет никакого контроля, как их данные обрабатываются, нет даже бинарных файлов соответствующих программ. Это полное отсутствие всех четырех свобод, но лицензии здесь почти бессильны, так что пользователи должны быть осведомлены об этой проблеме и должны осознанно принимать решение о допустимости использования соответствующих сервисов.
JavaScript и прочее программное обеспечение на сайтах. Все мы используем веб и браузеры, но большинство сайтов использует несвободные скрипты и иное программное обеспечение, выполняющееся на стороне пользователя. Отключение JavaScript во многих случаях делает использование ресурсов невозможным, поэтому пользователи постоянно подвергают свои системы большому риску с точки зрения безопасности их систем и конфиденциальности их данных.
Сетевое, встраиваемое и иное специализированное оборудование часто работает на закрытом программном обеспечении, что лишает пользователей контроля над этими устройствами, подвергая их данные опасности несанкционированного доступа.

Если упомянутое выше программное обеспечение не было основано на свободном программном обеспечении, то лицензии тут бессильны. Однако есть ситуации, когда лицензии явно или косвенно нарушаются.

Рассмотрим их подробнее. Нарушения можно разделить на:

Прямые. Лицензия явно и очевидно нарушается, здесь можно действовать в юридической плоскости на основе имеющихся нарушений.
Случайные. Лицензия может быть нарушена случайно: по недосмотру, небрежности, недостаточному вниманию к тонкостям лицензии.
Умышленно спорные. Есть случаи, когда лицензия формально или оспариваемо выполняется, но нарушает дух, идею лицензии и лишает пользователя одной или нескольких из четырех свобод.

Причин случайных нарушений много, в частности:

Забыли добавить исходные коды для всех автоматически сгенерированных файлов. Это часто касается jar файлов, исходных данных bison, flex, *.am файлов autotools и т.п. Проблема очень коварна, т.к. проект часто собирается и работает без этих файлов на сгенерированных данных. Даже GNU Emacs – один из флагманов программного обеспечения проекта GNU – умудрился нарушить GPL [4, 5], забыв поставить исходные файлы лексического анализа в формате bison, используемые для генерации файлов грамматик emacs.
Недоступность исходных кодов по техническим причинам: битые ссылки, упавший сервер, просто потеряли исходники по небрежности.
Совместили несовмещаемое. Не все свободные лицензии совместимы друг с другом. Можно нарушить лицензию, просто используя разные части кода под разными лицензиями в одном приложении.

Проблема совместимости свободных лицензий стоит достаточно остро, т.к. совмещение кода под несовмещаемыми лицензиями нарушает как минимум одну из них. На рис. 2 показан граф совместимости между наиболее распространенными свободными лицензиями. A → B означает, что код под лицензией A можно включать в код под лицензией B (часто это подразумевает перелицензирование кода A, разрешаемое его лицензией). Важно учитывать эту информацию при включении стороннего кода в свой проект.

Серая зона

«Серая зона» – это те случаи, когда из-за несовершенства лицензии она формально соблюдается, но в реальности четыре свободы пользователей существенно или полностью ограничиваются, дух лицензии нарушается. Рассмотрим сначала случаи, когда проблему, существующую в лицензии, устранили в следующей версии этой лицензии.

Ярким примером является проблема тивоизации [6]. В GPLv2 содержится недоработка, позволяющая производителям на аппаратном уровне блокировать свободу пользователя обновлять ПО на устройстве, оставляя при этом такую возможность для производителя, – этот процесс и называется тивоизацией, в честь компании Tivo, его придумавшей и реализовавшей. Тем самым возможность использовать модифицированное программное обеспечение и все связанные с этим свободы блокируются на аппаратном уровне. Формально такое поведение не нарушает GPLv2 из-за несовершенства лицензии, не оговаривающей применение свобод программного обеспечения при использовании на целевом оборудовании. Для решения данной проблемы и устранения иных недочетов была создана лицензия GPLv3 [7].

Следующим примером является патентный шантаж: когда крупные компании объединяют свои патентные пулы [7, 8] и держатели патентов вносили вклад в свободное программное обеспечение и подавали патентные иски к авторам кода, пользователям и мелким участникам рынка в целях вытеснения конкурентов.

Еще одним примером являются технологии DRM, связанные с ним законодательные акты (DMCA и т.п. в зависимости от юрисдикции). Суть проблемы в том, что законодательство может накладывать ограничение на четыре свободы программного обеспечения, например, запрещая продавать оборудование без DRM.

Как были решены эти вопросы? Рассмотрим на примере GPLv3.

Тивоизация была решена явным ее запретом в лицензии. Если производитель оставляет возможность обновления программного обеспечения для себя, он обязан предоставить такую же возможность пользователю; при этом он имеет право аннулировать гарантию при использовании модифицированного программного обеспечения.
Патентный шантаж решается защитой от патентных исков. Требуется от всех держателей прав на программное обеспечение не предъявлять патентные иски к любым лицензиатам (пользователям) такового программного обеспечения [9]. Предъявление подобных исков приведет к отзыву лицензии и потере связанных с ней патентов.
Проблема с законодательным принуждением к DRM устраняется тем, что GPL разрешает использовать и реализовывать любые вариации DRM, но не позволяет ограничивать возможность распространения способов обхода этой защиты, в т.ч. модифицированных вариантов данного программного обеспечения. Таким образом, за пользователями сохраняются все четыре свободы.

Открытые вопросы

Разумеется, в «серой зоне» есть нерешенные проблемы. Обсудим некоторые из них.

Обфускация изменений

В качестве примера рассмотрим действия компании Red Hat, которая стала предоставлять патчи ядра Linux, слитые в единое изменение, примененное к ядру [10].

Поскольку воедино сливаются сотни, если не тысячи как связанных, так и независимых изменений на перекрывающиеся участки кода, разбор и последующая полезная модификация данных изменений чрезвычайно усложнены.

Формально GPLv2 строго соблюдается, т.к. исходные коды предоставлены, но фактически свобода модификации и использования кода сильно ограничена, поскольку лицензия не ограничивает умышленное существенное усложнение работы с модификациями.

Примечательно, что данные действия совершенно открыто были объяснены действиями по ограничению конкуренции [11].

Форсирование несовместимых лицензий

Примером является проблема ZFS для Linux: лицензирование модуля ядра под свободной лицензией CDDL, несовместимой с лицензией ядра GPLv2 [12, 13].

Суть проблемы проста: обе лицензии требуют, чтобы производный продукт был под той же лицензией. Предполагаемой причиной выпуска ZFS под CDDL компанией Sun Microsystems было как раз ограничение конкуренции со стороны Linux [12].

Юридическая проблема здесь в том, что понимать под «производной работой». Поскольку нет строгого юридического определения для программного обеспечения, нечистые на руку участники пытаются нарушить дух GPLv2, формально соответствуя ей.

Юридическая проблема в том, что понимать под «производной работой». Поскольку нет строгого юридического определения для ПО, нечистые на руку участники пытаются нарушить дух GPLv2, формально соответствуя ей

Это спорный краевой случай, где корпорации пытаются ослабить ограничения копилефта, и многие пользователи поддерживают их, поскольку им интересны технические решения и не важны лицензионные тонкости.

Следует обратить внимание, что сборка из исходных кодов ядра Linux и модуля ZFS без распространения полученных бинарных файлов законна, т.к. GPLv2 накладывает ограничение на распространение полученного продукта [12, 13]. А вот распространять полученные бинарные файлы совместно, в т.ч. в рамках одного продукта, нельзя, т.к. это будет нарушение лицензии ядра GPLv2.

Контрактные ограничения

Примером являются патчи Grsecurity для ядра Linux [14]: проект Grsecurity основан строго на исходных текстах ядра Linux (GPLv2) и не имеет смысла без него, но распространение кода и бинарных сборок ограничивается дополнительным коммерческим договором подписки. Данный договор содержит параграф об аннулировании подписки в случае публикации исходного кода. Это может быть легально в некоторых юрисдикциях, хотя оспаривается специалистами [14].

В данной ситуации базовые свободы распространения и модификации СПО нарушаются.

Пути решения проблем

Программное обеспечение обрабатывает и защищает данные, однако, если оно не справляется с защитой, подключается юридическая сфера. Но лицензии как программы несовершенны. Что делать, когда в них тоже находятся уязвимости и проблемы? Что можно сделать, если юридическая защита не сработала? Простых путей здесь нет.

Совершенствование лицензий

Уточнение лицензий приводит к увеличению их сложности. Более строгие и точные лицензии также будут намного больше и сложнее для понимания. Чрезмерная сложность будет отпугивать пользователей, т.к. одно дело – изучить лицензию на две страницы и совсем другое – на 50.

На примере семейства лицензий GPL можно рассмотреть рост сложности с эволюцией лицензий. На рис. 3 показано изменение числа строк лицензии в зависимости от поколения.

Рисунок 3. Изменение числа строк лицензии в зависимости от поколения семейства лицензий GPL

Красной кривой показано число строк строго в лицензии GPL. Однако следует учитывать, что GPL – это семейство лицензий.

В первом поколении была только одна лицензия GPLv1, во втором поколении появилась необходимость в дополнительной лицензии LGPL, ориентированной на библиотеки, в третьем добавилась еще одна лицензия AGPL для обеспечения сетевой защиты приложений.

Важно применять лицензии по назначению. Лицензии для программ следует использовать для программ, лицензии для документации или мультимедиа – для документации или мультимедиа

Поэтому правильнее суммировать число строк всех лицензий в каждом поколении, что и отражено на синей кривой.

Видно, что из ~250 строк в первом поколении группа лицензий развилась до ~1500 строк в третьем. Это та цена, которую приходится платить за уточнение лицензий и исправление накопившихся в них проблем.

Здесь могут помочь упрощенные пояснения и инструменты выбора лицензий, понятные простым пользователям, как, например, сделано для семейства Creative Commons [15] (лицензии для документации и мультимедиа).

Для выбора и сравнения свободных лицензий можно использовать ресурс Software licenses in Plain English [16], позволяющий на простом и понятном языке посмотреть основную информацию по всем распространенным свободным лицензиям.

Профессиональным юристам эти инструменты тоже помогут, поскольку будет уменьшено число лицензий, которые нужно тщательно проанализировать.

Развитие культуры использования лицензий

Повышение грамотности в работе с лицензиями также способствует уменьшению проблем при их использовании.

На что следует обратить внимание?

Грамотный выбор лицензий. У каждой лицензии есть свои особенности, нужно учитывать поставленную задачу при выборе лицензии. Помочь в этом могут инструменты [15, 16].
Следует предпочитать строгие копилефтные лицензии (см. рис. 2) для своих проектов, поскольку только они могут помочь сохранить и преумножить свободы пользователей и разработчиков.
Важно уделить внимание корректному заимствованию кода. Некорректное совмещение кода, созданного под разными лицензиями, – распространенная ошибка. Рис. 2 и подобные схемы помогут понять, когда можно заимствовать код, а когда – нет.
Всегда следует использовать последние версии лицензий. Они выходят не просто так, а с учетом накопившихся проблем и замечаний. Точно так же, как и с программами: для того чтобы быть в безопасности, нужно использовать актуальные версии.
Важно применять лицензии по назначению. Лицензии для программ следует использовать для программ, лицензии для документации или мультимедиа – для документации или мультимедиа. К примеру, не следует использовать GPL для музыки или документации, т.к. в этом случае придется предоставлять все сырые машиночитаемые данные. Для этого есть Creative Commons или GNU FDL (для документации). Точно так же не нужно использовать лицензии для документации или мультимедиа для исходных кодов, поскольку они не учитывают специфики программного обеспечения.