Похоронил

Больше новых записей не будет.

Если потеряете.

Брюс Шнаер о безопасности и открытых исходниках

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

Безопасность — нечто иное. Представьте, что вы встраиваете функцию шифрова­ния в тот же текстовой процессор. Затем проверяете его таким же образом: шифруете ряд документов, затем расшифровываете их. Дешифрование восстанавливает откры­тый текст, а зашифрованный текст похож на бессмыслицу. Все это великолепно рабо­тает. К сожалению, эти испытания ничего не говорят о безопасности шифрования.

Функциональное тестирование хорошо для обнаружения случайных погреш­ностей, которые приводят к тому, что компьютерная программа ведет себя не­предсказуемо, в основном перестает работать. Недостатки системы защиты не проявляются столь эффектно; обычно они невидимы, пока не станут известны зло­умышленникам. Испытание средств безопасности — это не беспорядочное исполь­зование программного обеспечения и наблюдение за его работой. Это сознательное выявление проблем, создающих угрозу безопасности. Функциональное испытание никогда не выявило бы, что нападающий может создать веб-страницу, которая будет запускать некоторую программу на компьютере пользователя, просматриваю­щего эту страницу с помощью Microsoft Internet Explorer 3.0 или 3.0.1. Как раз это­го и не удастся обнаружить при бета-тестировании.

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

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

Даже достаточно полный анализ безопасности не сильно поможет. Я обнару­живал от 5 до 15 ошибок на тысячу строк кода, и это — в конечном продукте, после всех испытаний. Мы все знаем, какое огромное количество ошибок можно найти в операционной системе Microsoft, даже после сотен человеко-часов испытаний. Точно так же дни, недели и даже месяцы исследования безопасности не приведут ни к чему.

Другая сторона проблемы состоит в том, что полноценное исследование безопас­ности может быть проведено только опытными специалистами. Вспомним, что о продукте безопасности в лучшем случае можно будет сказать: «Я не могу взло­мать его, и другие умельцы также не смогут сделать этого». Только опытные спе­циалисты в области безопасности в состоянии действительно обнаружить недо­статки системы, поэтому качество любого испытания зависит от профессионализма исследователей.

Иногда недостатки защиты обнаруживаются случайно. Хороший пример — изъян в защите пароля Microsoft Bob: она позволяет повторно вводить пароль и по­сле трех неправильных попыток. Хотя это — исключение. Вероятность случайно­го попадания на какую-либо ошибку в системе безопасности очень низка, иногда она стремится к нулю. Более эффективен целенаправленный поиск.

К сожалению, еще не создана такая полезная вещь, как всеобъемлющий справоч­ник по вопросам безопасности. Те из нас, кто работают в этой области, зачастую созда­вали свои собственные справочники, содержащие перечни возможных нападений и уязвимых мест, которые встречаются в коммерческих продуктах, описаны в научной литературе или придуманы нами самими. Подобные перечни огромны — пару лет на­зад я составил такой список из 759 нападений, но и он не был исчерпывающим.

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

Обратите внимание, я не говорю «очень трудно» или «невероятно трудно». Я сказал «невозможно».

Что делать разработчику системы? В идеале — он должен перестать полагаться на своих собственных проектировщиков и бета-тестирование. Ему следует нанять независимых экспертов в области безопасности, которые проведут испытания. На них придется истратить значительные средства; скорее всего, это потребует стольких же усилий, сколько и сама разработка и реализация.

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

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

Обратите внимание: безопасность не имеет ничего общего с функционально­стью. Поэтому никакое бета-тестирование не поможет выявить недостатки безопасности. Единственный способ обрести уверенность в устойчивости системы к нападениям — это длительное испытание ее специалистами. И только одним способом можно достичь этого — сделать подробности системы общеизвестными.

Детали хорошо спроектированной защиты не являются секретом. В тайне со­храняются лишь некоторые изменяемые параметры: ключи шифрования, пароли, маркеры доступа и т. д. Противоположность этому — «безопасность через засекречивание» (security by obscurity), где сохранение в тайне деталей системы становит­ся условием безопасности. Если система разработана таким образом, то ее защита довольно хрупкая. Как смогли убедиться разработчики системы безопасности циф­ровой сотовой связи или схемы шифрования DVD, или интерфейса FireWire, рано или поздно потаенное становится явным. Плохо разработанная система защище­на, пока детали остаются в секрете, но быстро ломается, как только о них кто-ни­будь узнает. Хорошо разработанная система безопасна, даже если ее детали обще­известны.

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

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

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

Это наивное утверждение. Обнародование исходного кода увеличивает не ко­личество слабых мест, а осведомленность широкой публики. Производители, дер­жащие исходный код в тайне, скорее всего, небрежны. А производители, делающие tсвой код открытым, имеют больше шансов обнаружить уязвимые места и устра­нить их. Засекреченное программное обеспечение ненадежно. Публикация исход­ного кода обеспечивает большую безопасность, чем сохранение его в тайне.

Однако открытое программное обеспечение не гарантирует безопасность. Нуж­но помнить о двух вещах.

Во-первых, простая публикация кода не означает автоматически, что его ста­нут исследовать на предмет безопасности, и уж конечно не означает, что этим зай­мутся специалисты. Например, исследователи нашли ошибки переполнения бу­фера в коде, созданном в Массачусетском технологическом институте для Kerberos, через десять лет после выпуска этого кода. Другой открытый модуль — программа Mailman, предназначенная для работы со списками адресатов конференций, более трех лет имела бросающиеся в глаза недостатки защиты, пока сам разработчик не пересмотрел код и не обнаружил их.

Исследователи безопасности — непостоянные и вечно занятые люди. Они не имеют ни времени, ни склонности исследовать каждую часть опубликованного исходного кода. И хотя полезно сделать исходный код открытым, это не гаранти­рует безопасность. Я мог бы назвать дюжину библиотек открытого кода программ защиты, о которых никто никогда не слышал. С другой стороны, открытый исход­ный код защиты различных программных средств UNIX изучался многими про­фессионалами в области безопасности.

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

Я — за открытый исходный код и полагаю, что таким образом можно повысить уровень безопасности. Но программное обеспечение не становится автоматически надежным только потому, что делается открытым, и, наоборот, оно не делается небезопасным, если остается закрытым. Другие отмечали, что открытый код ка­жется более безопасным, и эта необоснованная вера заставляет людей доверять ему больше, чем следует. Это плохо.

Взято из перевода книги «secrets and lies: digital security in a networked world».

Unix system programming in Objective Caml

Курсы от Лероя. Наконец-то их перевели с французского на нормальный язык.
http://ocamlunix.forge.ocamlcore.org/ocamlunix.html

Давно я уже кино не рекомендовал

«Повелитель бури» («The Hurt Locker»)

«Война — это наркотик» применительно к персонажу, который за весь фильм стрелял в людей один раз, да и то сослуживца выручая. Перевод плохой. Рецензии не читать ни в коем случае, их идитоты писали.

Люби свою работу! Люби свою работу, сука!

Учимся на программиста

Недавно в МИФИ мы обнаружили студентов второго курса факультета кибернетики. Ребята занимались тем, что учили наизусть таблицу ASCII. Русскую таблицу ASCII. Русскую таблицу ASCII в кодировке cp-1251. Их потом на экзамене всех в обязательном порядке спрашивать будут.

Но это ерунда и неинтересно. Это вы ещё не видели студента, которому вручили стопку учебников по китайскому языку. Едем дальше.

Этим же ребятам задали написать переводчик. Консольный переводчик. Одним из условий для сдачи зачёта им поставили сборку приложения в университете. Ребята сразу же с проблемой столкнулись — кодировки-то в консоли и в MVS различаются. Поэтому при каждом обращении к системе производится двойная смена кодировок — до и после операции. Поскольку Microsoft Visual Studio в университете нелокализованная, а из-под «гостя» не позволяется добавлять туда либы, то пришлось искать обходные пути. При получении этих крякозябров в консольке ребята их копировали, а затем подбирали отступ для таблицы символов и таким образом написали модуль для перевода крякозябров во все буквы русского языка. Поскольку у каждого билда виндоуса смещение отступа различается, то они написали макросы для топа из десяти разных отступов. Благо им повезло и сборка в университете попала в этот топ.

Но это ерунда и тоже неинтересно. Дальше слушаем.

Трое ребят с пятого, выпускного курса подготовили дипломный проект — сайт на PHP. В настоящий момент сайт имеет несколько интересных архитектурных решений, вроде дублирования базы данных при каждом (sic!) обращении. Но меня особенно удивило, когда мне сказали, что «у них запрос хранится в куках»
— А-а, — говорю. — Имя таблицы небось хранят, да?
— Нет, сам запрос к серверу.
— Нихрена себе, весь SQL, что ли?
— Да нет. Запрос. Хочешь — хоть «rm -rf» пиши.
— Э-э… Это как?
— Ну так, переменная с запросом в куках хранится. Чтобы куки удобнее было в фаерфоксе редактировать

Эти трое собрали 40,000 рублей и попросили моего знакомого доделать проект, потому что этот сайт падает и нихера не работает. Тот им говорит — идите нахер, у меня завал с матаном.

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

Почему он пошёл на «Т», а не на «кибернетику»? Да потому что его, как и меня, на «кибернетику» не взяли. Нас втроём не взяли на «кибернетику», потому что мы хреново физику сдали. И поэтому пошли на факультет экспериментальной и теоретической физики, центральный факультет института.

Это МИФИ. Это вам не какая-нибудь шарашка. Это Национальный исследовательский ядерный университет. Это второй технический вуз в России, после физтеха.

Это вы ржали с моих постов о кубанском аграрном? Программист в «колхозе», гы-гы, ага. Плакать надо. У нас в «колхозе» за предложение спросить со студентов ASCII-таблицу всё ебло кирпичами бы отбили. Но не здесь. Здесь вам не Краснодар, здесь, блять, нанотехнологии двигают.

Дорогие дети! Пожалуйста, не повторяйте моих ошибок. Образования в России вообще нихуя нет. Хоть в престижных, хоть не в престижных институтах. Тут скоро пальмы из земли повылезают и обезьяны заведутся. Да, есть люди, которые одержимы наукой и которых иногда можно найти в университетах, но подавляющему большинству похуй на науку. И ни в коем случае не слушайте студентов и выпускников, когда они говорят о том, что их университеты такие охуенные. Потому что институт — это не школа, куда заставляют идти родители. Институты человек сам выбирает и сам борется за право там учится. И признаваться в том, что они добились только возможности страдать хуйнёй 5 лет подряд очень тяжело. И каждый студент вам расскажет, что именно его вуз — самый-самый. Это нормально.

Учитесь сами, держитесь поближе к нужным людям, никого вокруг не слушайте. Если нужно высшее образование — поступайте в самый халявный и спокойный университет. Voker57 так и делает, и делает правильно. А я идиот.

Кусочек истории

После этого Вагнер начал работу над компьютерной программой, котора эмулировала поведение калькулятора. Идея была возмутительной по своей сути. Для кого-то это было абсолютно нецелесообразным использованием дорогостоящего машинного времени. Оно, в соответствии со стандартными представлениями, должно было использоваться только для вещей, максимально полно использовавших возможности компьютеров и для которых в ином случае потребовалось бы множество математиков и масса времени на обсчет результатов. Хакеры считали иначе: все, что выглядело интересным и прикольным, заслужило быть отданным на съедение компьютеру. Они искренне верили в это и занимались этим, используя интерактивные способности машины когда никто не заглядывает через плечо и не требует допуска для выполнения конкретного проекта. После двух или трех месяцев напряженной работы на тонкостями организации арифметики с плавающей точкой (это необходимо для того чтобы программа знала, как обращаться с дробными числами) Вагнер написал три тысяч строк кода. Причем это все делалось на машине, которая не имела даже элементарного метода для умножения двух чисел. В результате, Вагнер заставил компьютер чудовищной стоимости выполнять работу, которую в состоянии сделать калькулятор, стоимостью в тысячи раз меньше. Чтобы отдать должное этой иронии, он назвал программу Expensive Desk Calculator (Дорогостоящий Настольный Калькулятор), после чего с гордостью продемонстрировал всему классу свое задание, сделанное на компьютере, на одном из занятий.

Ему поставили «единицу». «Вы использовали компьютер!», сказал ему профессор, «А это не может быть правильно».

Вагнер даже не попытался что-либо объяснить. Как бы он смог донести до своего учителя, что компьютер только что сделал реальностью то, что до сего момента относилось к разряду невероятных возможностей? Или как он смог бы ему объяснить то, что еще один хакер написал программу, которая называлась Expensive Typewriter (Дорогостоящая Пишущая Машинка), которая превращала TX 0 в нечто, на котором можно было набирать строки текста и печатать их на Flexowriter’е. Вы могли бы представить себе профессора, который принимает классную работу, написанную при помощи компьютера?

«Ambassador to the Computers (Mostly OCaml)»

Человек пишет неплохие статьи для новичков. Особенно радуют те, что про camlp4 и lwt.

http://ambassadortothecomputers.blogspot.com/