Дело о надувательстве в Quake

Выдающийся хакер Джон Кармак (John Carmack), чей гений стоит за компанией id Software и ее играми Castle Wolfenstein, Doom и Quake, плеснул масла в огонь святочных (1999 г.) дебатов участников движения за открытые исходные коды. Кармак отметил проблему, обнаружившуюся с началом распространения исходного кода Quake 1 на условиях GPL [1]. Похоже, некоторые стали использовать для жульничества возможность модификации клиента Quake.

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

Модель Quake особенно интересна своей связью с открытыми исходниками. Сторонники модели разработки софта с открытыми исходными кодами (включая меня) в течение последних двух лет выработали убедительную аргументацию в пользу того, что, например, Linux и Apache фундаментально более надежны, чем конкурирующие с ними продукты с закрытым кодом.

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

Так что, предположив, что проблему надувательства в Quake можно было бы решить только за счет пары шифрующих программ с закрытым исходником, Кармак поднял бурю на форуме "Slashdot" (www.slashdot.com). Сама проблема, как он правильно заметил, заключается в бесполезности требования от открытого клиента проверки своей собственной целостности - достаточно умный кракер всегда сможет написать клиентский код, который будет возвращать положительный результат проверки, а потом позволит игроку мошенничать.

Разгорелись дебаты, и ряд их участников заметил, что доверять клиентской стороне в клиент-серверной архитектуре - негодная практика с точки зрения безопасности вне зависимости от того, открыт код клиента или закрыт. Способа убедить сервер в том, что он не взаимодействует с умной имитацией "корректно" ведущего себя клиента, не существует в принципе. Таким образом, открытие исходников Quake 1 не создало проблему с безопасностью, а лишь проявило проблему, которая уже присутствовала в дизайне игры (и могла быть использована теми, кто знал о ней).

Тогда Кармак уточнил, что проблема несколько тоньше, чем предполагали спорящие. Для "жульнического" клиента нет возможности дать игроку неограниченное количество оружия или здоровья - сервер не доверяет клиенту в таких вещах и учитывает их сам. И это признак правильного дизайна, вне зависимости от того, открыт код или закрыт: банк не должен полагаться на клиентское обеспечение вкладчика в том, что касается баланса на счету последнего.

Кармак отметил, что ".жульнические" клиенты и прокси фокусируются в основном на двух вещах:

а) предоставлении игроку большей информации, чем тот должен иметь, и

б) более мастерском выполнении отдельных действий".

Серьезное "жульничество" с "лишней информацией" стало возможным из-за трюка, направленного на повышение производительности. Чтобы снизить требования к частоте обновлений клиентского образа мира Quake, сервер передает клиенту "предвосхищающую" информацию о расположении объектов и оппонентов, которых игрок еще не видит, но может увидеть до следующего обновления. Сервер полагается на клиента в том, что тот не покажет их игроку до того, как игрок "должен" их увидеть (то есть до того, как игрок окажется в определенном месте на карте, отрисовываемой клиентом). "Жульнический" клиент может открыть противника на секунды раньше, чем тот свернет за угол и подставится под огонь.

Эрик Спенсер Рэймонд (Eric Spenser Raymond), пожалуй, один из самых интересных членов хакерского сообщества. Славу за пределами профессиональной среды ему принесла серия тонких исследований антропологии и экономики программирования: "Храм и базар" ("The Cathedral and the Bazaar", 1997), "Обживаем ноосферу" ("Homesteading the Noosphere", 1997-98) и "Волшебный горшочек" ("The Magic Cauldron", 1999), републикованные в прошлом году издательством O'Reilly Associates отдельным томом. Тексты этих и других работ Рэймонда есть на www.tuxedo.org.

Рэймонд возглавляет Open Software Initiative (www.opensource.org) - организацию, призванную выделять и пропагандировать общие принципы лицензирования открытого программного обеспечения. Его самый известный программистский проект: fetchmail.

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

Жульничество с более искусным выполнением функций позволяет использовать скорость и точность компьютера для выполнения действий, которых сервер (и другие игроки) ожидают от рук и головы игрока. Кармак сообщает о "роботах-автоприцелах" (aim-bots), которые автоматически наводят оружие на видимого противника и поражают его с нечеловеческой точностью.

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

Казалось бы, аргументация Кармака безупречна. Но что-то здесь не так. Неужели нам действительно продемонстрировали, что закрытые исходники необходимы для обеспечения безопасности? А если все же нет, какие уроки насчет безопасности систем мы можем извлечь из дела о Quake?

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

Кармак, прочитав черновик этого эссе, заметил: "При задержках менее 100 мс и малом разбросе задержек можно было бы организовать синхронное обновление без передачи "лишней" информации, но в мире, где распространены тонкие модемные линии и типичные задержки составляют 200-400 мс, это просто не сработает". Таким образом, учитывая условия, для которых разрабатывался Quake, жертва была необходима. Но она нарушает первое правило хорошей разработки безопасности: принцип минимального раскрытия [2].

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

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

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

Вид ландшафта, на котором мы оказываемся, вполне знаком: история безопасности компьютерных систем оставила свой след в виде метафорических (а иногда, возможно, и реальных) скелетов тех, кто решил, что запутывания "закрытых" протоколов достаточно для безопасности. "Взломщики" в восторге от такой наивности и безжалостно ею пользуются.

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

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

Мошенничество с "автоприцелом" предотвратить еще труднее. Различия между действиями человека и робота измеряются лишь миллисекундами задержки. Изменение протокола, предотвращающее утечку предварительной информации, не решит проблему "автоприцелов". Даже просто обнаружить использование робота (выполняя статистический анализ на серверной стороне) крайне сложно, и, как отмечает Кармак, "такая гонка вооружений может привести в конце концов к тому, что умелого игрока примут за робота".

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

(Любые компьютерные игры, в которых компьютер эффективнее большинства людей, уязвимы для такого мошенничества. Кармак замечает, что "и шахматы по переписке были извращены игроками, использующими компьютеры". Это не поддается исправлению методами компьютерной безопасности.)

Если бы Quake изначально разрабатывался методом открытого исходного кода, жертвовать безопасностью ради производительности (что открывает возможности для мошенничества с подглядыванием за угол) никто бы не стал. Дизайн был бы изменен, чтобы не зависеть от миллисекундных задержек. А распознавание "автоприцелов" было бы встроено в сервер с самого начала.

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

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

Это тот тип безопасности, который свойствен ядру Linux или Web-серверу Apache и которого лишены жертвы Melissa, Chernobyl, Back Orifice и прочих ломалок для продуктов Microsoft. Если от целостности софта зависит ваша личная приватность или критические функции вашего бизнеса, то именно такой тип безопасности нужен и вам.

Резюмируем. Реальный урок дела о мошенничестве в Quake заключаются в том, что:

а) не следует доверять честности клиента;

б) подлинная безопасность не может сохраняться, если ею жертвовать во имя производительности;

в) подлинная безопасность следует не из запутанности, а из минимального раскрытия и мониторинга угроз;

и, что важнее всего,

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

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

Такая жертва может быть оправдана (и даже необходима) в аркадных играх, но она нетерпима в компонентах развивающегося Internet-бизнеса. Стремление избежать таких лихих наскоков является одной из причин для пользователя требовать открытия исходников для всего более серьезного, чем игры типа Quake.

27.12.1999

P. S. В течение дня после публикации этого эссе я узнал, что прокси-"автоприцелы" (программы, располагаемые между клиентом и сервером Quake и выполняющие автоприцеливание) на самом деле писались задолго до того, как исходники этой игры были открыты. Таким образом, утверждение, что закрытие исходника не остановит умного "взломщика" с пакетным анализатором, не является чисто умозрительным - так оно и произошло.

Я также понял, что предложенный Кармаком "закрытый" верификатор можно тривиально обойти: если проверка контрольной суммы осуществляется только при запуске, проверить, сохраняется ли целостность кода после запуска, будет невозможно (вызов ptrace() в Unix или его эквивалент легко может быть использован для обхода такой проверки). Более продвинутый верификатор может проверять сумму через случайные периоды времени, но и сам "безопасный" верификатор можно кастрировать, модифицировав его так, чтобы он возвращал OK при любой проверке. Разработать такую заплатку, обладая символическим отладчиком и дизассемблером, не очень сложно.

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

27.12.1999

P. P. S. Если вы страстный игрок и вам показалось, что я критикую дизайн Quake в целом или что-то имею против Джона Кармака, успокойтесь. Кармак сам читал (и одобрил) черновик этого эссе, и, конечно, он-то сообразил, что оно вовсе не про Quake. Сделайте десять глубоких вдохов-выдохов и - перечитайте.

29.12.1999

Пер. с англ. Максима Отставнова

1 (обратно к тексту) - GNU Public License - юридическая конструкция, использующая концепцию копирайта для предотвращения "приватизации" свободно распространяемого кода, см. www.gnu.org. - Здесь и далее прим. перев.

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