[devel] severity "security"

[Dmitry V. Levin]

On Mon, Oct 02, 2006 at 08:10:09PM +0300, Andrew Kornilov wrote:
> Dmitry V. Levin wrote:
> 
> Пардон, что так затянул с ответом :(

Сказал, что отвечу через несколько лет, а потом передумал :)

> >>>Какой в этом смысл?
> >>>Постящий bug report и так может пометить его как security.
> >>>
> >>Отметить "Security Group"? Но ведь, во-первых, никто, кроме этой группы 
> >>не увидит описание проблемы,
> >
> >Предполагается, что для этой группы ошибок важна конфиденциальность.
> >
> Для всех пакетов? А зачем? Я понимаю, когда есть серьезная уязвимость и 
> exploit для неё и это приложение используется повсеместно. Но ведь 
> ежедневно находят немалое количество не очень серьезных уязвимостей, 
> которые, однако, исправить нужно в обозримом будущем. Если нет общей 
> системы для их учета, то приходится их писать на бумажке/в файле. И 
> читать одному человеку все рассылки по уязвимостям несколько 
> проблематично. Если уж элементарные баги сам найти не можешь в своем же 
> и используемом самим же пакете, тогда как другие натыкаются на это 
> сразу, то с этими уязвимостями ситуация еще хуже.

Идея в том, что если вы хотите сохранить конфиденциальность, то
выпомещаете bug report в эту группу.  Если же вам просто нужно дать
понять, что bug report is security sensitive, сделайте его blocker и
добавьте [security] в subject.

> >>Чтобы видеть, с какими пакетами проблемы. Неработоспособность видна 
> >>сразу обычно, как быть с безопасностью?
> >
> >Пойдите на http://cve.mitre.org/cve/ и посмотрите.
> >
> Там не всё. Вот только что приехала уязвимость на OpenVPN: DoS, System 
> Access; на mitre.org её нет. Что мне делать? Ждать, когда об этом узнает 
> майнтейнер, повесить баг, пересобрать самому?

Вы же не secoff, зачем вам быть в курсе всего?

> >>Если бы был некий список 
> >>уязвимостей приложения и их статуc в Сизифе, было бы проще  узнать, 
> >>можно ли его использовать в данный момент. Вот кто сходу может ответить, 
> >>можно ли использовать нашу сборку openvpn? А sshd? А как быть с 
> >>утилитами типа rkhunter, которые проверяют версию приложения? Он ведь 
> >>упорно ругается на наш sshd как на уязвимый, хотя это и не так. Кому 
> >>верить?  Как проверить?
> >
> >Либо я вас не понял, либо вы наивно полагаете, что дырявость пакета так же
> >легко проверяется, как и собираемость.
> >
> Неплохо бы иметь список проблем из разных источников, чтобы не метаться 
> по всем рассылкам. Да и security hole может быть и не из-за уязвимости 
> самого приложения, а из-за того, что майнтейнер установил некую опцию 
> типа RemoteRootAccess=yes. Ну и т.д.

Вы не понимаете, что занести указатель на проблему в bugzilla легко, в вот
установить факт наличия проблемы нетривиально?

> >Хотя есть, конечно, разные категории пакетов.
> >Например, есть такая категория пакетов, про которые известно, что они
> >дырявые от природы.
> >
> Но иногда и они нужны, когда больше никто подобную функциональность не 
> предоставляет.  Можно его как-то пометить, мол, вечно уязвимый, но 
> оставить. Я помню ситуацию с ntop несколько лет назад, когда мне 
> преложили его поместить в какой-то определенный каталог с "плохими" 
> приложениями, когда я предложел его в сизифе разместить :)

Без комментариев.

> >Как вы можете проверить, является ли пакет openssh в Сизифе уязвимым?
> >Это зависит от вашей профессиональной подготовки.
> >
> >Давайте это проверим.  Ответьте, по возможности, аргументированно на такой
> >вопрос: подвержен ли уязвимости CVE-2006-2607 пакет vixie-cron в Сизифе?
> >Как бы вы стали проверять crond на CVE-2006-2607?  Вешать багу на пакет?
> >
> Понятия не имею.

Плохо.  Очень плохо.

> У меня нет перез глазами явного списка всех его уязвимостей.

http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=vixie-cron

> И исправлена ли она, я могу (с трудом) определить, почитав 
> изначально --changelog (и поверим майнтейнеру, который написал там, мол, 
> исправлено),

В данном примере changelog вам не поможет, поскольку ошибка была
исправлена примерно за два года до того, как её стали считать уязвимостью
и присвоили номер CVE-2006-2607.

> могу почитать про уязвимость, посмотреть исправления, 
> заглянуть в код и с некоей долей вероятности определить, что, видимо, 
> [не]исправлено.

Вот именно.

> >>>>bugtraq читают многие, я думаю.
> >>>>
> >>>Не факт.  Этот список рассылки последнее время стал малоинформативным.
> >>>
> >>Но как быть тогда? Аналога полноценного нет.
> >
> >Это не так.  Есть много списков рассылок, которые вместе взятые дают
> >достаточно полную картину того, какие пакеты и на какую тему _принято_
> >исправлять.
> >  
> И все эти списки рассылки должен читать каждый майнтейнер? Я думаю, что 
> на это не согласятся даже за деньги :-)

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

> >>Но это ведь не повод игнорировать вообще проблемы с безопасностью.
> >
> >Нет, конечно.  Но мне кажется, что ваш взгляд на этот вопрос несколько
> >упрощённый.  Припоминаю, как несколько лет назад непосредственно перед
> >релизом какой-то версии Mandrake была найдена какая-то довольно глупая
> >ошибка в их пакете SysVinit, после чего один пользователь написал в список
> >рассылки предложение быстренько проверить и устранить оставшиеся дырки. :)
> >
> >Видите ли, если к безопасности относиться серьёзно, то это сложная
> >многослойная задача.
> >
> Да это все понятно.

Не факт, что всем, кому это должно быть понятно, это действительно
понятно.

> Но сейчас мне вообще непонятно, кто и что проверяет и контролирует.

Я всё проверяю и контролирую. :)

> И есть ли это вообще. Я могу быть майнтенером мелкой 
> утилиты, которую мало кто использует, но она есть в базовой системе и 
> для неё уже два года как local root exploit есть. Что с ней будет? 
> Видимо, ничего.

Это вряд ли.  Ваш пакет не может попасть в базовую систему случайно.

> >>>>Но ситуацию с security, похоже, никто не отслеживает совершенно.
> >>>>
> >>>Ну, тут вы сильно заблуждаетесь. :)
> >>>
> >>Я очень на это надеюсь. Но очень хочется увидеть какие-либо упоминания 
> >>об этом, а еще лучше результаты.
> >
> >Я определённо не понимаю, какое упоминание и какой результат вы хотите увидеть.
> >
> К примеру, оповещение где-либо о том, что исправлены такие-то ошибки и 
> доступны новые пакеты. Как это было раньше для пакетов из коробочных 
> дистрибутивов (и есть ли оно сейчас для них?). Все это достаточно не 
> сложно автоматизировать, если захотеть :)

Автоматизировать исправления уязвимостей нельзя.
Автоматизировать рассылку уведомлений можно.
Видимо, заняться этой автоматизацией некому.

> >>>>p.s. Интересно, если, к примеру, если будет выпускаться новый "Master", 
> >>>>что будет после заморозки? Некие специальные люди будут читать весь 
> >>>>архив bugtraq и анализировать текущие версии пакетов на предмет 
> >>>>уязвимостей  или это будет выпущено as is?
> >>>>
> >>>Коллега, вот я бы на вашем месте подумал, что будет в плане задраивания
> >>>отверстий в пакетах уже после релиза.
> >>>
> >>Не совсем понял. То есть, выпустить дистрибутив с уязвимостями можно, 
> >>главное, чтобы потом кто-то их исправлял?
> >>
> >Я имею в виду, что исправлять уязвимости в уже выпущенном дистрибутиве
> >в течение всего срока его жизни существенно сложнее, чем выпустить
> >дистрибутив с заткнутыми опубликованными дырками.
> >
> Насколько сложно? Сколько нужно людей на fulltime, чтобы исправлять в 
> среднем, одну уязвимость в день, пересобирать пакет, как-то тестировать 
> и выкладывать в публичный доступ?

Около одного человека высокой квалификации, не считая подстраховки.
При этом на security research у него, скорее всего, будет недостаточно
времени.

> Разве не сложнее прошерстить всё перед 
> выпуском дистрибутива? Можно ведь получить ситуацию как с виндой, когда 
> ставится изначально "дырявая" ОС, для которой все исправления доступны, 
> но поставить их не успеваешь, потому как время жизни такой ОС в сети 
> значительно меньше времени скачивания этих исправлений :)

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

У нас даже есть несколько хорошо зарекомендовавших себя мантейнеров,
которых secoff по возможности информирует об уязвимостях заранее.

> >>>Если бы мантейнеры действительно заботились о безопасности своих пакетов,
> >>>то вопрос информирования не стоял бы.
> >>>
> Майнтейнер майнтейнеру рознь. Ведь они это не за зарплату делают и это 
> не их основная задача. Кому-то все равно, есть ли remote access к этому 
> приложению, потому как у него и сети нет на этой машине и пользуется он 
> один этим. А кто-то использует это по полной программе. Причем, 
> майнтейнер может быть вообще в астрале и не реагировать на письма. Что 
> делать второму? Постоянно следить за пакетом, не надеясь на первого и 
> при первой же уязвимости делать NMU? Понятно, что вариантов масса и 
> всего учесть нельзя.

Мы переходим на gear, с помощью которого кооперативная работа будет
происходить гораздо проще и эффективней.

> >>Но ведь активности майнтейнеров недостаточно. Должен (читай: желательно) 
> >>быть какой-то человек, хоть каким-то образом отвечающий хотя бы за 
> >>безопасность пакетов.
> >
> >Что значит "отвечающий"?
> >
> Ну ведь есть же такое понятие Security Officer. Живьем я их еще не 
> видел, но знаю, что они есть :) И можно только предполагать, какой 
> процент компаний может себе позволить держать штат таких сотрудников для 
> каждого направления в безопасности. Компания, занимающаяся разработкой и 
> продажей дистрибутивов, позволить себе это может, в прямом или косвенном 
> виде. Хотя и это тоже все относительно...

Приходите в офис компании ALT Linux, там есть (всего лишь) один такой
сотрудник, который по совместительству ещё и secoff. :)

На самом деле число имён пакетов, ошибки в которых были признаны
уязвимостями, за год не так уж и велико, их реально проверить.

> >>того, как я узнал о них случайно где-то на форуме или в личном письме, 
> >>уж не помню. Никто не удосужился уведомить меня о них и в Сизифе было 
> >>приложения с remote hole. Если внимательно посмотреть, то подобных 
> >>проблемных пакетов наберётся немало, imho.  Разве это нормально?
> >
> >Видите ли, пакетов в Сизифе столько, что не интересно не только следить за
> >безопасностью их всех, но и просто за их именами.
> >Есть мантейнер не следит за своими пакетами, то это не мантейнер, а
> >муляж мантейнера.
> >  
> Понятно, что сферический майнтейнер в вакууме представляет значительно 
> больше интереса для всех, но реальность далека от этого, к сожалению. Я 
> так понимаю, что нормальная практика в том случае, если я перестаю 
> использовать приложение, это написать всем, что оно мне больше не нужно 
> и или забирайте его себе или выкидывайте из репозитария?

Логично.

> >>p.s. Я повторю вопрос: что будет после "заморозки" среза Сизифа? Будет 
> >>ли кто-нибудь анализировать срез на предмет безопасности?
> >
> >Не думаю, что имеет смысл "анализировать срез на предмет безопасности".
> >Надо просто следить за своими пакетами.
> >
> >P.S. Всех учу, а самому никак libtiff новый собрать некогда. :(
> >
> А как можно за ними за всеми следить? Вот только что глянул на Top 
> maintainers на sisyphus.ru (все знают, кто там :). В жизни не поверю, 
> что кто-то из них физически способен следить за своими пакетами, даже 
> если он этим будет заниматься 24/7 :) А вот если коллективно, то хоть 
> что-то получится.

Следить, на самом деле, не так уж и сложно.  Вот, нашёл публичную ссылку:
http://www.google.com/search?q=%22vendor-sec%20mailing%20list%22&num=1


-- 
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20061004/d7e67492/attachment-0001.bin>