В свободном ПО существует очень тонкая грань между чисто внутренними дискуссиями и публичными заявлениями. Отчасти это так, потому что целевая аудитория всегда размыта: учитывая, что большинство или все сообщения доступны публично, проект не имеет полного контроля над образом, который получает окружающий мир. Кто-то - скажем, редактор slashdot.org может привлечь внимание миллионов читателей к сообщению, которое никто не ожидал увидеть вне границ проекта. Это факт, с которым приходится мирится всем проектам свободного ПО, но на практике такой риск обычно мал. Как правило, объявления, которые проект хочет сделать наиболее публичным, и будут наиболее публичными, предполагая, что вы используете правильные средства для того, чтобы показать внешнему миру какие из сообщений стоят того, чтобы сделать из них новости.
Для важных объявлений, в общем, есть четыре или пять основных каналов распространения, в которых надо сделать эти объявления по возможности одновременно:
Главную страницу вашего проекта, возможно, просматривает большее число людей, чем любую другую часть проекта. Если сообщение действительно важно, поместите здесь рекламу. Реклама должна представлять собой короткое резюме, отсылающее к пресс-релизу (смотрите ниже) за более подробной информацией.
В то же время, у вас должно быть место на web-сайте для "Новостей" или "Пресс-релизов", где объявление может быть расписано в деталях. Отчасти, цель пресс-релиза - это представить простой, базовый "объект объявления", на который могли бы ссылаться другие сайты, так что позаботьтесь, чтобы он был соответственно структурирован: либо одна web-страница на один релиз, как отдельная статья блога, либо в виде какой-то другой сущности, на которую можно ссылаться, и которая оставалась бы отличной от других релизов в том же месте.
Если в вашем проекте имеется лента RSS (см. «RSS Feeds»), позаботьтесь, чтобы объявление попало и туда. Это может происходить автоматически при создании пресс-релиза, в зависимости от того, как устроен ваш сайт.
Если объявление касается нового выпуска ПО, то обновите запись о вашем проекте на http://freshmeat.net/ (см.«Announcing» о создании записи в первый раз). Каждый раз, когда вы обновляете запись на Freshmeat, эта запись попадает в список дневных изменений Freshmeat. Список изменений обновляется не только на самом Freshmeat, но и на различных порталах (включая http://slashdot.org) которые просматривают огромные толпы людей. Freshmeat также предлагает эту информацию через ленту RSS, так что люди, которые не подписаны на RSS-ленту вашего проекта, тем не менее, смогут увидеть объявление через ленту Freshmeat.
Пошлите сообщение в новостной список рассылки вашего проекта. Название этого
списка должно быть действительно "announce", то есть, announce@yourprojectdomain.org,
поскольку сейчас это уже очевидное стандартное
соглашение, и устав списка должен утверждать, что это очень ненагруженный
список, зарезервированный для важных объявлений проекта. Большинство из таких
объявлений будут о новых выпусках ПО, но иногда могут быть сообщения и о других
событиях, таких как кампания по сбору средств, обнаружение брешей в безопасности
(смотрите «Объявление о дырах в безопасности») ниже в этой
главе, или важные сдвиги в направлении проекта. Поскольку трафик мал и
используется только для важных вещей, список announce обычно имеет наибольшее
число подписчиков среди списков рассылки проекта (конечно, это означает, что вы
не должны злоупотреблять этим - подумайте хорошенько перед тем, как писать). Чтобы
оградить список от объявлений случайных людей или, ещё хуже, спама, список
announce должен, конечно, модерироваться.
Постарайтесь сделать объявления во всех этих местах одновременно, насколько возможно. Людей может ввести в заблуждение объявление в списке рассылки, если они не видят его подтверждения на главной странице проекта или в пресс-релизах. Если вы поставили различные изменения (почту, изменение web-страницы и т.д.) в ожидание и затем послали их все одновременно, вы можете сделать окно несоответствия очень маленьким.
Для менее важных событий вы можете пропустить какие-то или все из приведённых каналов. Событие всё равно будет замечено во внешнем мире в зависимости от его важности. Например, новый выпуск ПО - это важное событие, тогда как просто объявление даты следующего выпуска - хотя и нечто интересное, но совсем не такое важное, как сам выпуск. Установка даты - подходящее сообщение для ежедневных списков рассылки (а не для списка announce), для обновления графика проекта и web-страницы текущего состояния, но не более.
Несмотря на это, вы всё же увидите, что дата релиза появляется в дискуссиях в разных местах в Интернете, где есть люди, заинтересованные в проекте. Люди-невидимки в ваших списках рассылки, которые просто слушают и никогда ничего не говорят, не обязательно молчат где-то ещё. Народная молва - очень широкий канал распространения; вы должны считаться с этим и строить даже второстепенные объявления таким образом, чтобы поддерживать точную передачу информации. В особенности, сообщения, которые предположительно будут цитироваться, должны иметь очевидную предназначенную-для-цитирования часть, как будто вы пишите официальный пресс-релиз. Например:
Уточнение планов: мы планируем выпустить версию 2.0 Scanley в середине Августа 2005 года. Вы всегда можете проверить наличие обновлений на http://www.scanley.org/status.html. Основной новой функцией будет поиск по регулярным выражениям.
Другие новые функции включают: ... Также будут исправлены различные ошибки, включая: ...
Первый параграф - короткий, выдаёт две наиболее важные порции информации (дата выпуска и главная новая функция), а также URL для просмотра будущих новостей. Если этот параграф - единственное, что пройдёт через чьё-то сито, - это тоже нормально. Остаток сообщения можно опустить, не искажая сущность содержимого. Конечно, некоторые люди всё равно дадут ссылку на полное сообщение, но часто они будут цитировать только небольшую часть. Учитывая вероятность последнего, вы можете облегчить им это занятие и получить свою выгоду о того, что контролируете, что именно будет процитировано.
Управление отчётом об уязвимости в безопасности отличается от управления отчётом о любой другой ошибке. В открытом ПО делать всё открыто и понятно - это обычно почти религиозное кредо. Каждый шаг стандартного процесса исправления ошибки виден всем, кто хочет видеть: появление первоначального отчёта, подтверждающая дискуссия и окончательное исправление.
Ошибки безопасности не такие. Они могут скомпрометировать данные пользователей или компьютеры пользователей в целом. Открытое обсуждение такой проблемы было бы рекламой во всем мире - включая всех тех, кто может злонамеренно использовать ошибку. Даже простой commit исправления в действительности анонсирует существование ошибки (есть потенциальные нападающие, которые просматривают журналы commit'ов открытых проектов, систематически выискивая изменения, которые указывают на проблемы безопасности в коде до изменения). Большинство проектов открытого ПО принимают примерно одинаковый набор шагов для урегулирования конфликта между открытостью и секретностью, основанный на следующих базовых положениях:
Не говорите об ошибке публично, пока не готово исправление; затем предоставьте исправление одновременно с объявлением об ошибке.
Поторопитесь с таким исправлением, как только можете - особенно, если об ошибке сообщил кто-то снаружи проекта, потому что вы знаете, что есть по крайней мере один человек вне проекта, который способен использовать уязвимость.
На практике такие принципы приводят к достаточно стандартизованной серии шагов, которые описаны в следующих разделах.
Очевидно, проекту нужна возможность получать от кого угодно отчёты об ошибках в безопасности. Но это не может быть адрес списка рассылки для отчётов об обычных ошибках, поскольку этот адрес открыт для всех. Поэтому заведите отдельный список рассылки для приёма отчётов об ошибках безопасности. У этого списка не должно быть общедоступного архива и подписчики на него должны строго контролироваться - только проверенные разработчики, участвующие длительное время, могут ими быть. Если вам нужно формальное определение слова "проверенный", можете использовать "любой, у кого был доступ на commit два и более года" или что-нибудь в этом роде, чтобы избежать фаворитизма. Это группа, которая будет разбираться с ошибками безопасности.
В идеале список безопасности не должен модерироваться и защищаться от спама, поскольку вы не захотите, чтобы важный отчёт был отфильтрован или задержан, потому что в эти выходные ни один модератор не был в сети. Если вы вынуждены использовать ПО для защиты от спама, попробуйте настроить его с очень мягкими установками; лучше пусть будет какой-то спам, чем потеряется отчёт. Чтобы список был эффективным, вы должны, конечно, отрекламировать его адрес; но, учитывая, что он будет немодерированным, более того, слабо защищённым от спама, постарайтесь никогда не посылать этот адрес без какого-либо преобразования для скрытия адреса, как описано в разделе «Address hiding in archives» в Глава 3, Техническое обеспечение. К счастью, скрытие адреса не обязательно делает его нечитаемым; посмотрите http://subversion.tigris.org/security.html, и её HTML-исходник для примера.
Что же должна делать группа безопасности, когда она получает отчёт? Первая задача - исследовать серьёзность и срочность проблемы:
Насколько серьёзна уязвимость? Позволяет ли она злоумышленнику получить контроль над компьютером того, кто использует ваше ПО? Или, скажем, просто подсмотреть информацию о размерах некоторых файлов пользователей?
Насколько просто использовать уязвимость? Достаточно написать скрипт для атаки или для этого требуются обстоятельные знания, догадки, основанные на опыте, и удача?
Кто сообщил вам о проблеме? Ответ на этот
вопрос, конечно, не изменяет природы уязвимости, но он даёт вам представление о
том, сколько народу может о ней знать. Если отчёт пришёл от одного из собственных
разработчиков проекта, вы можете вздохнуть несколько свободнее (но только чуть-чуть),
потому что вы можете надеяться, что они не рассказали об этом кому-то ещё.
С другой стороны, если он пришёл от anonymous14@globalhackerz.net
то будет лучше, если вы начнёте
действовать как можно быстрее. Человек, в конце концов, оказал вам услугу,
сообщив о проблеме, но вы не имеете представления, скольким ещё людям он это
сказал, или как долго он будет ждать перед тем, как воспользоваться уязвимостью
на живых инсталляциях.
Отметьте, что разница, о которой мы говорим, часто лежит между срочно и чрезвычайно срочно. Даже когда отчёт поступает из известного, дружественного источника, могут существовать другие люди в Сети, которые давно нашли эту ошибку и просто не сообщают о ней. Единственный случай, когда всё не так срочно, это когда ошибка по своей природе не очень серьёзно влияет на безопасность.
Пример с "anonymous14@globalhackerz.net" кстати, не шутка.
Вы действительно
можете получать отчёты об ошибках от скрывающих личность людей, которых, по их
словам и поведению, никогда нельзя уверенно отнести ни на вашу сторону, ни на
противоположную. Это не имеет значения: если они сообщили вам о дые в
безопасности, они полагают, что сделали вам добро, и вы должны ответить тем же.
Поблагодарите их за отчёт, сообщите дату, когда или до которой, вы планируете
выпустить публичное исправление, и не распространяйтесь об этих людях. Иногда
они могут назначить вам дату - то есть, недвусмысленно
угрожать опубликовать ошибку в определённый день, будете вы готовы или нет.
Это может выглядеть как попытка силой загнать вас в угол, но более вероятно,
это упреждающее действие, являющееся результатом прошлых разочарований в
безразличных производителях ПО, которые не воспринимали отчёты о безопасности достаточно серьёзно.
В любом случае, вы не можете допустить, чтобы этот человек рассердился. В конце концов, если ошибка
серьёзная, он обладает знаниями, которые могут вызвать большие неприятности у
ваших пользователей. Относитесь к таким корреспондентам хорошо и надейтесь, что
они будут относиться к вам также.
Другой частый корреспондент, сообщающий о дырах безопасности, - профессионал по безопасности, некто, кто занимается аудитом кода по жизни и следит за последними новостями в сфере уязвимости ПО. Эти люди обычно имеют опыт по обе стороны забора - они и посылали и получали отчёты, возможно больше, чем большинство разработчиков вашего проекта. Они также обычно назначают крайний срок устранения уязвимости перед преданием её огласке. Крайний срок можно обговорить, но он остается на усмотрение корреспондента. Крайние сроки превратились среди профессионалов по безопасности в единственный надёжный рычаг контроля над организациями, заставляющий их реагировать на проблемы быстро. Так что не рассматривайте крайний срок как грубость; это освящённая веками традиция, и для этого есть основания.
Как только вы выяснили серьёзность и срочность, вы можете начать работу над исправлением. Иногда существует компромисс между тем, сделать ли исправление элегантно, либо быстро; вот почему вы должны условиться о срочности перед тем как начнёте. Конечно, ограничивайте обсуждение исправления членами списка рассылки по безопасности, инициировавшим обсуждение корреспондентом (если он захочет) и разработчиками, которых необходимо включить по техническим причинам.
Не добавляйте исправление в репозиторий. Оставьте его в виде патча до даты обнародования. Если вам пришлось выложить его, даже сопроводив выглядящим невинно комментарием, кто-нибудь может заметить и понять его. Вы никогда не знаете, кто просматривает ваши репозитории и почему ими интересуются. Не поможет отключение почтовых уведомлений о commit'ах; прежде всего, зазор в последовательности сам по себе выглядит подозрительно, и ведь всё равно данные в репозитории будут. Просто ведите всю разработку в виде патча и храните его в каком то секретном месте, возможно, в отдельном закрытом репозитории, известном только людям, которые уже осведомлены об ошибке. (Если вы используете децентрализованную систему контроля версий типа Arch или SVK, вы можете выполнять работу под полным контролем версий, просто сохраняя репозиторий недоступным извне.)
Вы, возможно, встречали номера CAN или CVE, связанные с проблемами безопасности. Эти номера выглядят, например, как "CAN-2004-0397" или "CVE-2002-0092".
Числа обоих видов представляют сущность одного типа: запись в списке "Общие уязвимости и опасности", который ведётся на http://cve.mitre.org/. Цель списка - предоставить централизованные имена для всех известных проблем безопасности, чтобы каждый мог использовать уникальное каноническое имя при обсуждении проблемы, и центральное место, куда надо идти за дополнительной информацией. Единственное различие между CAN- и CVE-номером в том, что первый представляет запись-кандидат, ещё не проверенную для включения в официальный список Редакционной Коллегией CVE, а второй - проверенную запись. Однако, оба типа записей видны публично, и номер записи не изменяется после проверки - просто префикс "CAN" заменяется на "CVE".
Сам записи CAN/CVE не содержат полного описания ошибки и защиты от неё. Вместо этого они содержат краткое резюме и список ссылок на внешние ресурсы (такие как архивы списков рассылки), на которых люди могут найти более подробную информацию. Реальная цель http://cve.mitre.org/ - предоставить хорошо организованное место, где каждая уязвимость могла бы иметь имя и простой доступ к дальнейшим данным. Смотрите http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092 Заметим, что ссылки могут быть очень сжатыми, в которых источники кажутся зашифрованными аббревиатурами. Ключ к таким аббревиатурам находится на http://cve.mitre.org/data/refs/refkey.html.
Если ваша уязвимость удовлетворяет критерию CVE, вы можете пожелать получить для неё номер CAN. Эта процедура намеренно защищена: в общем, вы должны знать кого-нибудь, или знать кого-то, кто знает кого-нибудь. Это не так безумно, как кажется. Чтобы оградить Редакционную Коллегию CVE от завала фальшивыми или плохо оформленными представлениями, они принимают представления только от источников, которые они уже знают и которым доверяют. Чтобы вставить вашу уязвимость в список, вы должны найти способ извещения Редакционной Коллегии CVE о вашем проекте. Опросите своих разработчиков; возможно кто-нибудь из них знает кого-то ещё, кто проходил процесс CAN раньше, или знает того, кто знает, и т.д. Преимущество такого подхода ещё и в том, что где-то в цепочке есть кто-то, кто знает достаточно, чтобы сказать вам, что а) это не может считаться уязвимостью или опасностью в соответствии с критерием MITRE, так что нет смысла представлять её, или что б) уязвимость уже имеет CAN- или CVE-номер. Последнее могло случиться, если ошибка уже была опубликована в другом консультативном списке безопасности, например, на http://www.cert.org/ или в списке BugTraq на http://www.securityfocus.com/. (Если это произошло, а в вашем проекте об этом неизвестно, то вы должны обеспокоиться тем, что ещё могло случиться, о чём вы не знаете.)
Если вы вообще получаете номер CAN, вы обычно хотите сделать это на ранних стадиях изучения ошибки, чтобы все остальные обсуждения могли ссылаться на этот номер. На записи CAN накладывается эмбарго до даты оглашения; запись будет существовать в виде пустого зарезервированного места (чтобы вы не потеряли имя), но не будет показывать никакой информации об уязвимости до того дня, когда вы объявите об ошибке и исправите её.
Больше о процессе CAN/CVE можно найти на http://cve.mitre.org/cve/identifiers/candidates_explained.html, и особенно подробное описание конкретного использования в проекте открытого ПО номеров CAN/CVE - на http://www.debian.org/security/cve-compatibility.
Как только ваша команда безопасности (то есть, те разработчики, которые подписаны на список рассылки безопасности или те, кто добавился в связи с конкретным отчётом) получила готовое исправление, вы должны решить, как его распространить.
Если вы просто выложите исправление в репозиторий или иным способом сообщите о нём миру, вы насильно заставляете каждого, кто пользуется вашим ПО, немедленно произвести обновление или подвергнуться риску быть атакованным. Поэтому, иногда уместно сделать пред-объявление для некоторых важных пользователей. Это особенно верно для клиент-серверного ПО, когда могут существовать хорошо известные серверы, которые являются соблазнительными целями для атакующих. Администраторы таких серверов оценят дополнительные день-два, которые они получат для установки обновлений, чтобы быть защищёнными в тот момент, когда угроза станет публичным достоянием.
Пред-объявление просто означает посылку email-сообщений таким администраторам до даты опубликования, с описанием уязвимости и способа исправления. Вы должны послать пред-объявление только тем людям, которые, по вашему мненинию, будут осторожны с этой информацией. То есть, оснований для посылки пред-объявления должно быть два: получатель должен эксплуатировать большой важный сервер, для которого компрометация будет серьёзным делом, плюс получать должен быть известен как человек, который не будет болтать о проблеме безопасности до дня опубликования.
Посылайте каждое пред-уведомляющее письмо по отдельности (по одному за раз) каждому получателю. Не посылайте всему списку получателей сразу, потому что тогда они увидят имена друг друга - что означает, что вы предупреждаете каждого получателя, что у других могут быть дырки в безопасности. Посылка с использованием скрытых CC (BCC) также нехорошее решение, потому что некоторые администраторы защищают свои входящие ящики при помощи спам-фильтров, которые либо блокируют, либо уменьшают приоритет почты, полученной через BCC, поскольку слишком много спама посылается в наши дни через BCC.
Вот простое пред-уведомляющее письмо:
From: Здесь ваше имя To: admin@large-famous-server.com Reply-to: Здесь ваше имя (но не адрес списка безопасности) Subject: Конфиденциальное уведомление о уязвимости Scanley. Это сообщение - конфиденциальное пред-уведомление об ошибке безопасности в сервере Scanley. Пожалуйста, *не делайте forward* никакой части этого сообщения кому бы то ни было. Публичное объявление будет только 19 мая, и мы бы хотели сохранить информацию закрытой до этой даты. Вы получили это сообщение, потому что (мы надеемся) вы используете сервер Scanley и захотите наложить патч до того, как эта дыра в безопасности станет достоянием гласности 19 мая. Ссылки: ======= CAN-2004-1771: Переполнение стека Scanley в запросах Уязвимость: =========== Сервер можно заставить выполнять любые команды, если локаль сервера сконфигурирована неудачно и клиент посылает неверный запрос. Серьёзность: ============ Очень серьёзно, может повлечь исполнение произвольного кода на сервере. Обходные пути: ============== Установка опции 'natural-language-processing' в 'off' в файле scanley.conf закрывает данную уязвимость. Патч: ===== Приведённый ниже патч применим к Scanley 3.0, 3.1, и 3.2. Новое публичное обновление (Scanley 3.2.1) будет выпущено 19 мая или накануне, так что оно станет доступно одновременно с публичным объявлением о данной уязвимости. Вы можете наложить патч сейчас, либо дождаться публичного обновления. Единственным различием между 3.2 и 3.2.1 будет данный патч. [...здесь следует патч...]
Если у вас есть номер CAN, включите его в пред-уведомление (как показано выше), даже если информация всё ещё закрыта и, следовательно, страница MITRE ничего не покажет. Включение номера CAN позволяет получателю убедиться, что ошибка, о которой его предуведомили, та же самая, о которой он затем узнает по общедоступным каналам, так что он не должен беспокоиться о том, нужны или нет дальнейшие действия, что и составляет суть номеров CAN/CVE.
Последним шагом в обработке ошибки безопасности стоит публичное распространение исправления. В единственном обстоятельном объявлении вы должны описать проблему, дать номера CAN/CVE, если они есть, описать способ временного обхода и способ полного устранения. Обычно "устранить" ("fix") означает провести обновление до новой версии ПО, хотя иногда это означает наложение патча, особенно, если ПО в нормальном состоянии всё равно выполняется из исходников. Если вы сделали новый выпуск, он должен отличаться от предыдущего выпуска только патчем безопасности. Тогда консервативные администраторы могут провести обновление, не беспокоясь о том, на что ещё оно может повлиять; они также не должны беспокоиться по поводу следующих обновлений, поскольку исправление, конечно, будет в них входить естественным образом. (Детали процедур выпуска описываются в «Security Releases» в Глава 7, Packaging, Releasing, and Daily Development.)
Даже если публичное исправление не ведет к появлению нового выпуска, сделайте
объявление примерно с таким же приоритетом, как будто новый выпуск состоялся: пошлите
сообщение в список announce проекта, создайте новый пресс-релиз, обновите запись
Freshmeat, и т.д. Хотя вы никогда не должны пытаться преуменьшить наличие ошибок
безопасности, заботясь о репутации проекта, вы можете, несомненно, сохранить тон
и громкость объявления соответствующей действительной серьёзности проблемы. Если
дыра в безопасности - просто возможность раскрытия несущественной информации, а
не ошибка, которая позволяет получить управление всем компьютером пользователя,
то она может не вызывать сильного беспокойства. Вы даже можете решить не
беспокоить этим список announce. В конце концов, если проект каждый раз
поднимает ложную тревогу, пользователи начинают думать, что ПО меньше защищено,
чем это есть на самом деле, а также могут не поверить вам, когда вы анонсируете
действительно большую проблему. Смотрите на
http://cve.mitre.org/about/terminology.html хорошее введение в проблему
установления серьёзности.
В общем, если вы не уверены, как обращаться с проблемой безопасности, найдите кого-нибудь опытного и поговорите об этом с ним. Оценка и обработка уязвимостей очень сильно зависит от опыта, и первые несколько раз легко сделать неверные шаги.