Глава 12. Безопасность портов

Этот перевод может быть устаревшим. Для того, чтобы помочь с переводом, пожалуйста, обратитесь к Сервер переводов FreeBSD.

Содержание

12.1. Почему безопасность так важна

Ошибки в программном обеспечении появляются случайно. Возможно, самые опасные из них те, что создают уязвимости безопасности. С технической точки зрения подобные уязвимости должны быть закрыты путем исправления вызывающих их ошибок. Тем не менее, политики обработки несущественных ошибок и уязвимостей очень различаются.

Обычная небольшая ошибка затрагивает только тех пользователей, которые задействуют некоторые комбинации настроек, активирующие эту ошибку. Разработчик в конечном счете выпустит патч, а зачтем новую версию программного обеспечения, свободного от ошибки, но большинство пользователей не посчитают нужным сразу же произвести обновление, поскольку эта ошибка никогда у них не проявлялась. Критическая ошибка, которая может приводить к потере данных, представляет серьезную проблему. Тем не менее, предусмотрительные пользователи знают, что большинство возможных происшествий, и среди них программные ошибки, скорее всего приводят к потере данных, поэтому они выполняют резервное копирование важных данных; дополнительно, критическая ошибка будет обнаружена очень скоро.

С уязвимостью безопасности всё иначе. Во-первых, она может сохраняться необнаруженной целые годы, потому что чаще всего не вызывает ошибок в работе. Во-вторых, компания злоумышленников может использовать ее для получения неавторизованного доступа к уязвимой системе, уничтожить или подменить важные данные; в худшем случае пользователь даже не заметит нанесенный урон. В-третьих, взлом уязвимой системы часто упрощает задачу проникновения атакующих в другие системы, которые не могут быть скомпрометированы иначе. Таким образом, устранение уязвимости как таковой недостаточно: следует разослать всем заинтересованным уведомления в наиболее понятной и исчерпывающей форме, что позволит оценить риск и предпринять подходящие меры.

12.2. Исправление уязвимостей безопасности

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

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

Пожалуйста, убедитесь, что ревизия порта после закрытия уязвимости увеличена. Вот как пользователи, обновляющие установленные пакеты на постоянной основе, увидят, что им нужно запустить обновление. Кроме того, новый пакет будет собран и распространен через FTP и WWW зеркала, замещая уязвимый. Если в процессе исправления уязвимости не было изменено значение PORTVERSION, то должно быть увеличено значение PORTREVISION. Вам следует увеличить значение PORTREVISION после добавления в порт файла с патчем, но не когда вы обновили порт до последней версии программного обеспечения, попутно затронув при этом PORTVERSION. За дальнейшей информацией обращайтесь к соответствующему разделу.

12.3. Обеспечение сообщества информацией

12.3.1. База данных VuXML

Очень важным и первостепенным шагом при действии как можно раньше после раскрытия уязвимости является уведомление сообщества пользователей порта об опасности. Такие уведомления служат двум целям. Во-первых, в случае действительно серьезной угрозы, будет посоветовано применить мгновенное воздействие. Например, остановить затрагиваемый сетевой сервис или даже удалить порт целиком, пока уязвимость не будет устранена. Во-вторых, масса пользователей имеет тенденцию обновлять установленные пакеты только от случая к случаю. Из уведомления они узнают, что должны обновить пакет без промедления сразу же после появления исправленной версии.

Учитывая огромное число портов в дереве, невозможно по каждому случаю выпускать бюллетень безопасности без создания флуда и потери внимания сообщества к моменту появления действительно серьезных причин. Поэтому уязвимости безопасности, обнаруженные в портах, записываются в базу данных FreeBSD VuXML. Члены Команды Офицеров Безопасности также отслеживают её на предмет появления вопросов, требующих их вмешательства.

Если вы обладаете правами коммиттера, вы можете сам обновить базу данных VuXML. Так вы поможете Команде Офицеров Безопасности и своевременно пошлете ценную информацию сообществу. Тем не менее, если вы не являетесь коммиттером или верите, что нашли исключительно серьезную уязвимость, то не задумываясь свяжитесь с Командой Офицеров Безопасности напрямую как это описано на странице информационной безопасности FreeBSD.

База данных VuXML является документом XML. Его исходный файл vuln.xml содержится прямо внутри порта security/vuxml. Следовательно, полное имя пути к файлу будет PORTSDIR/security/vuxml/vuln.xml. Каждый раз, при обнаружении вами в порте уязвимости безопасности добавьте об этом запись в этот файл. Пока вы не знакомы с VuXML, лучшее, что вы можете сделать, это найти существующую запись, подпадающую под ваш случай, затем скопировать ее и использовать в качестве шаблона.

12.3.2. Короткое вступление в VuXML

В совокупности XML является очень сложным форматом, и его описание выходит далеко за рамки этой книги. Тем не менее, для достижения основного понимания структуры записи VuXML вам понадобится всего лишь понять теги. Имена тегов XML обрамляются в угловые скобки. Каждый открывающий <tag> должен иметь совпадающий закрывающий </tag>. Теги могут быть вложенными. При вложенности внутренние теги должны быть закрыты до закрытия внешних. Существует иерархия тегов, т.е. более сложные правила вкладывания тегов. Это похоже на HTML. Основное отличие в расширяемости XML, т.е. в определении собственных тегов. Из-за своей характерной структуры XML придает форму разрозненным данным. В частности, XML подходит для разметки описаний уязвимостей безопасности.

Теперь рассмотрим настоящую запись VuXML:

<vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> (1)
  <topic>Several vulnerabilities found in Foo</topic> (2)
  <affects>
    <package>
      <name>foo</name> (3)
      <name>foo-devel</name>
      <name>ja-foo</name>
      <range><ge>1.6</ge><lt>1.9</lt></range> (4)
      <range><ge>2.*</ge><lt>2.4_1</lt></range>
      <range><eq>3.0b1</eq></range>
    </package>
    <package>
      <name>openfoo</name> (5)
      <range><lt>1.10_7</lt></range> (6)
      <range><ge>1.2,1</ge><lt>1.3_1,1</lt></range>
    </package>
  </affects>
  <description>
    <body xmlns="http://www.w3.org/1999/xhtml">
      <p>J. Random Hacker reports:</p> (7)
      <blockquote
        cite="http://j.r.hacker.com/advisories/1">
        <p>Several issues in the Foo software may be exploited
          via carefully crafted QUUX requests.  These requests will
          permit the injection of Bar code, mumble theft, and the
          readability of the Foo administrator account.</p>
      </blockquote>
    </body>
  </description>
  <references> (8)
    <freebsdsa>SA-10:75.foo</freebsdsa> (9)
    <freebsdpr>ports/987654</freebsdpr> (10)
    <cvename>CVE-2023-48795</cvename> (11)
    <certvu>740169</certvu> (12)
    <uscertta>SA10-99A</uscertta> (13)
    <mlist msgid="201075606@hacker.com">http://marc.theaimsgroup.com/?l=bugtraq&amp;m=203886607825605</mlist> (14)
    <url>http://j.r.hacker.com/advisories/1</url> (15)
  </references>
  <dates>
    <discovery>2010-05-25</discovery> (16)
    <entry>2010-07-13</entry> (17)
    <modified>2010-09-17</modified> (18)
  </dates>
</vuln>

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

1Это тег верхнего уровня записи VuXML. У него есть обязательный атрибут vid, указывающий на универсальный уникальный идентификатор (UUID) для этой записи (в кавычках). Вы должны формировать UUID для каждой новой записи VuXML (и не забудьте заменить ее для шаблона UUID, если вы не пишете запись с нуля). Для получения VuXML UUID вы можете использовать uuidgen(1).
2Однострочное описание найденной проблемы.
3Здесь перечислены имена затронутых пакетов. Может быть дано несколько имен, поскольку некоторые пакеты могут быть основаны на одном главном порте или программном продукте. Сюда можно включить стабильную ветвь и ветвь разработки, локализованные версии и подчиненные порты, зависящие от различного выбора важных вариантов конфигурации, указанных на этапе построения.
4Затронутые версии пакета(ов) указаны там как один или несколько диапазонов с использованием комбинации элементов <lt>, <le>, <eq>, <ge> и <gt>. Убедитесь, что указанные диапазоны версий не перекрываются.
В спецификации диапазона * (звёздочка) обозначает наименьший номер версии. В частности, 2.* меньше, чем 2.a. Таким образом, звёздочка может использоваться в диапазоне для соответствия всем возможным версиям alpha, beta и RC. Например, <ge>2.</ge><lt>3.</lt> выборочно соответствует каждой версии 2.x, тогда как <ge>2.0</ge><lt>3.0</lt> — нет, поскольку последний пропускает 2.r3 и включает 3.b.
Приведённый пример указывает, что затронуты версии 1.6 и выше, но не включая 1.9, версии 2.x до 2.4_1 и версия 3.0b1.
5Некоторые связанные группы пакетов (в конечном счете, порты) могут быть указаны в разделе <affected>. Это можно использовать, если некоторые программные продукты (скажем, FooBar, FreeBar and OpenBar) являются производными от общей кодовой базы и всё еще совместно используют её ошибки и уязвимости. Имейте в виду отличие от перечисления множественных имён в одном разделе <package>.
6Диапазоны версий должны учитывать PORTEPOCH и PORTREVISION, если это применимо. Пожалуйста, помните, что в соответствии с правилами сравнения строк версия с ненулевым значением PORTEPOCH выше, чем любая версия без PORTEPOCH, например, 3.0,1 выше, чем 3.1 или даже 8.9.
7Сводная информация о проблеме. В этом поле используется XHTML. По крайней мере, должны быть обрамляющие <p> и </p>. Может быть использована более сложная разметка, но только в целях аккуратности и ясности: без эстетства, пожалуйста.
8Этот раздел содержит ссылки на имеющие отношение документы. Приветствуется как можно большее количество ссылок.
9Это бюллетень безопасности FreeBSD.
10Это сообщение об ошибке FreeBSD.
11Идентификатор MITRE CVE.
12Это SecurityFocus Bug ID.
13Бюллетень безопасности US-CERT.
14URL к архивному сообщению в списке рассылки. Атрибут msgid является необязательным и может указывать на message ID сообщения.
15Это общий URL. Используйте его только если ни одна из других категорий ссылок не подходит.
16Это дата, когда проблема была раскрыта (ГГГГ-ММ-ДД).
17Это дата добавления записи (ГГГГ-ММ-ДД).
18Это дата, когда любая информация в записи была последний раз изменена (ГГГГ-ММ-ДД). Новые записи не должны включать это поле. Добавьте его при редактировании существующей записи.

12.3.3. Тестирование ваших изменений в базе данных VuXML

Этот пример описывает новую запись об уязвимости в пакете dropbear, которая была исправлена в версии dropbear-2013.59.

В качестве предварительного условия установите свежую версию порта security/vuxml.

Сначала проверьте, есть ли уже запись об этой уязвимости. Если бы такая запись существовала, она соответствовала бы предыдущей версии пакета 2013.58:

% pkg audit dropbear-2013.58

Если запись не найдена, добавьте новую запись для этой уязвимости.

% cd ${PORTSDIR}/security/vuxml
% make newentry

Если уязвимость имеет идентификатор MITRE CVE, можно использовать следующую команду:

% cd ${PORTSDIR}/security/vuxml
% make newentry CVE_ID=CVE-YYYY-XXXXX

где CVE-YYYYY-XXXX является действительным идентификатором CVE.

Если уязвимость относится к FreeBSD Security Advisory, вместо этого можно использовать следующую команду:

% cd ${PORTSDIR}/security/vuxml
% make newentry SA_ID=FreeBSD-SA-YY-XXXXXX.asc

где FreeBSD-SA-YY-XXXXXX.asc является опубликованным FreeBSD Security Advisory.

Проверьте его синтаксис и форматирование:

% make validate

Предыдущая команда создает файл vuln-flat.xml. Его также можно создать с помощью:

% make vuln-flat.xml

Должен быть установлен хотя бы один из следующих пакетов: textproc/libxml2, textproc/jade.

Проверьте, что раздел <affected> записи соответствует правильным пакетам:

% pkg audit -f ${PORTSDIR}/security/vuxml/vuln-flat.xml dropbear-2013.58

Убедитесь, что запись не создает ложных совпадений в выводе.

Теперь проверьте, соответствуют ли записи правильные версии пакетов:

% pkg audit -f ${PORTSDIR}/security/vuxml/vuln-flat.xml dropbear-2013.58 dropbear-2013.59
dropbear-2012.58 is vulnerable:
dropbear -- exposure of sensitive information, DoS
CVE: CVE-2013-4434
CVE: CVE-2013-4421
WWW: https://portaudit.FreeBSD.org/8c9b48d1-3715-11e3-a624-00262d8b701d.html

1 problem(s) in the installed packages found.

Предыдущая версия совпадает, а последняя — нет.

12.3.4. Контрольный список для новой записи в VuXML

  • Проверьте название порта. Иногда имя проекта в вышестоящем репозитории не полностью совпадает с именем порта.

  • Добавить все флейворы. Если у порта есть варианты, все имена пакетов должны быть добавлены в запись как <package>. Используйте следующий скрипт для генерации всех имен пакетов с вариантами:

    % for flavor in $(make -V FLAVORS); do FLAVOR="${flavor}" make -VPKGNAME;done

  • Проверить, имеет ли порт PORTEPOCH. Приведённый выше фрагмент скрипта помогает в этом. Если порт использует PORTEPOCH, обязательно добавить его в тег <range>.

  • Перепроверьте диапазоны. В случае диапазонов, ограниченных с обеих сторон, убедитесь, что элементы <ge> и <lt> находятся внутри одного тега <range>. В противном случае запись может определить перекрывающийся диапазон.

  • Проверка производных версий. Если в вышестоящем проекте обнаружена уязвимость, проверьте, затронуты ли также производные или форки проекта, включённые в дерево портов. Например, если уязвимость обнаружена в www/firefox, оцените, есть ли такая же уязвимость в производных, таких как www/librewolf, www/waterfox или других подобных проектах. Включите все затронутые производные в запись VuXML, чтобы пользователи этих портов были проинформированы. Также проверьте наличие Linux-версий этого порта в дереве. Например, уязвимости в databases/sqlite3 скорее всего затрагивают и пакеты вроде databases/linux-c7-sqlite3.

  • Не делайте коммит записи, не запустив сначала make validate.

Изменено: 18 сентября 2025 г. by Vladlen Popolitov

Главная