ЛАТАЯ, молитесь

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

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

Slammer оказался просто отвратительным типом. Уже в первые минуты его жизни число инфицированных машин удваивалось через каждые 8,5 секунды. А ведь в июле 2001 года вирус Code Red наделал немало шуму, хотя количество зараженных компьютеров удваивалось тогда с интервалом в 37 минут. Slammer вышел на пиковую скорость распространения уже через три минуты; к этому моменту он ежесекундно сканировал 55 млн. потенциальных целей.

Но практически сразу его темп стал замедляться. Он оказался жертвой своей собственной высочайшей эффективности, захлебнувшись в порожденный им самим сканирующий трафик. Тем не менее к 10-минутной отметке 90% общего числа уязвимых машин на планете уже были заражены. А когда скорость его продвижения пошла на спад, специалисты начали обсуждать, какие печальные последствия мог повлечь за собой перенос атаки на рабочий день и что произошло бы, если бы Slammer нес в себе какую-то деструктивную нагрузку.

Со временем все обсуждения свелись к теме обновления программного обеспечения. Действительно, по скорости распространения Slammer оказался самым быстрым червем за всю историю компьютерной отрасли, но при этом его «триумфальное шествие» началось спустя полгода после того, как корпорация Microsoft выпустила заплату, которая должна была воспрепятствовать проникновению этого вируса в компьютеры. Голоса тех, кто пустился на поиск виновных, — и их было довольно много — слились в уже знакомый хор: если бы обновлению операционной системы уделялось должное внимание, нашествия Slammer не было бы.

Но на самом деле все обстоит совсем не так. Позвольте мне пояснить эту мысль.

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

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

Эти противоречия довели процесс модернизации и выполнения всех связанных с управлением обновлением процедур до абсурда.

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

«Мы находимся между молотом и наковальней, — подчеркнул директор по информационной безопасности штата Джорджия Боб Уинн. — Никто не в состоянии организовать эффективное управление данным процессом. Я даже не могу автоматически установить у себя обновления. А поскольку вирусы сейчас распространяются очень быстро, у меня не остается времени на то, чтобы проверить работоспособность обновленного программного обеспечения».

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

Искусство обучения

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

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

Но чем дальше, тем сильнее проявляются слабости такого подхода. Современные программы очень велики (Windows XP, в частности, содержит 45 млн. строк кода), а погрешности, возникающие из-за спешки (10-20 ошибок на тысячу строк кода), приводят к тому, что в системах появляются тысячи уязвимых мест. Центр реагирования на компьютерные инциденты (CERT) в прошлом году опубликовал информацию о 4200 новых брешах — на 3 тыс. больше, чем три года назад. Между тем программное обеспечение отвечает за выполнение все более важных бизнес-функций, и ошибки здесь могут повлечь за собой самые пагубные последствия. Другими словами, качество должно непрерывно повышаться, на деле же оно ухудшается экспоненциально.

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

В числе этих несчастных оказался и сетевой администратор Университета Дюка Тим Райс. «Начав устанавливать заплаты как придется, вы только наломаете дров, — заметил он. — Проводить обновление можно, лишь хорошо усвоив это искусство. Можно одинаковым образом установить шесть различных систем и интегрировать в них одно и то же обновление, после чего одна из шести систем начнет вести себя совершенно непредсказуемо».

Эту точку зрения разделяет и администратор по вопросам безопасности Медицинского центра Святой Елизаветы Ралей Бернс: «Многие полагают, что интерфейс у этих модулей прост, как Микки-Маус, но на самом деле даже самые примитивные обновления достаточно сложны».

«Когда мне приходится устанавливать заплаты, я чувствую себя будто между молотом и наковальней, — отметил директор по информационной безопасности штата Джорджия Боб Уинн. — Я не могу проводить модернизацию автоматически. И у меня нет времени на то, чтобы заниматься тестированием обновленных программ».

Если подходить к данному вопросу с формальных позиций, то, устанавливая обновление, вы улучшаете тем самым работу системы. Однако Уинн в этом далеко не уверен: «У всех у нас имеется опыт обновлений, которые приводили к нарушению работоспособности системы. Достаточно широкий спектр обновлений действительно порождает определенные трудности — вы лишь меняете одни уязвимые места на другие. Поэтому следует проявлять осторожность».

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

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

«Мы получаем свежие обновления практически ежедневно, но весьма неохотно устанавливаем их, — сообщил директор информационной службы медицинского центра Covenant Health Care Фрэнк Кларк. Компьютерная сеть центра была поражена вирусом Slammer, что заставило докторов на время вернуться к бумажным документам. — Мы убеждены в том, что гораздо безопаснее подождать, пока производитель исправит ошибки в пакете обновления».

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

Ужасы модернизации

Slammer наглядно продемонстрировал нам все недостатки предлагаемой производителем системы обновления программного обеспечения. Начало этому положило обнаружение уязвимости, информация о которой появилась в июле 2002 года, когда Microsoft выпустила обновление MS02-039. Исправленный вариант заменял файл ssnetlib.dll, где обнаружилась ошибка переполнения буфера.

«Опубликованная информация позволила хакерам составить схему атаки, — пояснил автор книги Building Secure Software («Создание безопасного программного обеспечения») Гэри Макгроу. — Совершенно неожиданно для себя они точно узнали, в каком направлении им следует двигаться. Раз люди не устанавливают у себя обновления — а все складывается именно так — значит, публикация соответствующих сведений идет на пользу хакерам».

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

В 2002 году корпорация представила еще три заплатки, которые должны были закрыть уязвимые места в SQL Server: MS02-043 появилась в августе, MS02-056 — в начале, а MS02-061 — в середине октября. После выпуска MS02-056 на смену прежней библиотеке ssnetlib.dll пришла ее новая версия. Тем не менее все три обновления нормально сочетались друг с другом.

Чуть позже Microsoft предложила клиентам пакет модернизации SQL Server Q317748, не имевший отношения к системе безопасности. В нем были исправлены ошибки, связанные с утечкой памяти, которые приводили к снижению производительности. Однако команда, занимавшаяся разработкой этого обновления, использовала старый вариант ssnetlib.dll, в котором остались бреши. Во время своей установки пакет Q317748 оставлял сервер беззащитным перед червями наподобие Slammer, как будто обновления системы безопасности до этого и не проводилось.

«На протяжении всего жизненного цикла программного обеспечения или по крайней мере в ходе его разработки участникам проекта необходимо иметь целостное представление о нем», — отметил Эрнан.

И только потом приходит время для обновлений.

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

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

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

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

А вот другой случай. В апреле прошлого года Microsoft выпустила обновление MS03-013, которое должно было ликвидировать серьезную брешь в системе безопасности Windows XP. После этого в некоторых конфигурациях производительность операционной системы упала почти на 90%. Разработчики вынуждены были срочно писать новую заплату, которую пользователям пришлось ждать целый месяц.

Авторы Slammer с удовольствием воспользовались имеющимися изъянами. Червь заражал как серверы, в которых уязвимые места появились вследствие конфликта обновлений, так и компьютеры, на которые обновленные версии программного обеспечения не устанавливались вовсе по причине чересчур запутанной схемы наложения заплат. Дело в том, что проведение обновлений требовало написания соответствующих сценариев, перемещения файлов, внесения изменений в системный реестр и права доступа. (После эпидемии Slammer даже инженерам Microsoft пришлось немало попотеть над обновлением собственных систем.) Многие избегали установки исправленных версий, потому что попросту опасались возможного отказа SQL Server.

Полная неразбериха

Первой реакцией на нашествие Slammer была суматоха. «Очень трудно понять, когда и куда в свое время была наложена каждая из заплат», — отметил Купер.

Slammer нанес удар в тот момент, когда ситуация менялась с калейдоскопической быстротой: несколькими днями раньше Microsoft выпустила пакет Service Pack 3 for SQL Server. В первые моменты было неясно, нуждается ли он в исправлениях (на самом деле в этом не было необходимости), и в Microsoft рекомендовали клиентам все-таки развернуть на своих компьютерах SP3 во избежание недоразумений.

Между тем пользователей, которым, несмотря на все сложности, удалось установить MS02-061, немало озадачило то, что пропускная способность их подвергшихся заражению серверов таяла буквально на глазах. А родственное SQL Server программное обеспечение Microsoft Desktop Engine вообще заставило всех замереть от ужаса. MSDE запускается на клиентских станциях и устанавливает обратную связь между ними и SQL Server. Эксперты предположили, что код MSDE уязвим для Slammer, поскольку все заплаты накладывались на компьютеры с SQL Server и MSDE.

Это действительно оказалось так, и Купер никогда не забудет то чувство страха, которое охватило его, когда он вспомнил, что код MSDE присутствует почти в 130 приложениях независимых разработчиков. Этот код запускается в фоновом режиме, и многие системные администраторы даже не предполагают о его существовании. Купер обнаружил соответствующие компоненты у половины клиентов своей компании. Правда, компьютеры больницы Beth Israel Deaconess Hospital в Бостоне были заражены даже несмотря на то, что все необходимые обновления на серверы SQL Server были установлены.

Когда в понедельник пользователи пришли на работу и загрузили свои клиентские станции, активизировав тем самым MSDE, Купер всерьез опасался, что эпидемия Slammer или какого-то его штамма вспыхнет с новой силой. Никто не знал, что произойдет дальше. Ведь установить заплаты на тысячи серверов SQL Server — это одно, а выявить и обновить миллионы клиентских машин с MSDE — совсем другое. Между тем в Microsoft настаивали на том, что в случае установки SP3 приложения на базе MSDE окажутся защищены.

Этот совет показался всем весьма разумным.

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

В кризисной ситуации заниматься исправлением пакета обновлений, который был выпущен всего несколько дней тому назад, представлялось неразумным. Вскоре Купер понял, что учетная программа MAS 500 разработки компании Best Software несовместима с Service Pack 3. Пользователи MAS 500, установившие на свои компьютеры SP3, чтобы противостоять нашествию Slammer, больше не могли запустить это приложение. Им пришлось начинать все заново, форматируя диски. Все пытались одолеть Slammer до начала рабочей недели, чтобы избежать его массового нашествия после включения в понедельник миллионов машин по всему миру. В противном случае все лицом к лицу столкнулись бы с червем, который в течение выходных пребывал в лениво-дремлющем состоянии.

«К вечеру воскресенья в Microsoft приняли решение собрать сотрудников в двух помещениях, — вспоминает Купер. — В одном из них находились специалисты службы технической поддержки, которые думали над тем, что они будут говорить клиентам. В другом собрались эксперты по безопасности, лихорадочно соображавшие, каким образом извлечь заплаты из пакета и обеспечить контроль за техническими отказами».

Повторение ошибок

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

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

У одной только Microsoft создана иерархия из восьми различных механизмов обновления (правда, в корпорации заявляют, что их число планируется сократить). Подобный подход порождает у клиентов дополнительные трудности.

Как узнать, когда следует устанавливать заплатки, закрывающие бреши в системе безопасности? Нужно ли после этого еще раз установить Service Pack 2 для Windows 2000? Надо ли переустанавливать заплаты после развертывания выпущенных раньше пакетов обновлений? Ответы на подобные вопросы, которыми пестрят бюллетени безопасности, занимают не одну страницу.

Бросается в глаза отсутствие документирования разработки обновлений и создания соответствующих архивов. Производители вновь и вновь совершают одни и те же ошибки. Они не используют накопленные ранее знания о том, когда и где возникают уязвимые места и как избежать появления этих брешей в дальнейшем. К примеру, у Web-браузера Apple Safari имелся серьезный недостаток. Проверка сертификатов осуществлялась средствами SSL, а это потребовало наложения заплатки. Аналогичный дефект присущ и всем браузерам, разработанным до Safari.

«Очень хотелось бы найти способ улучшить существующий процесс, — отметил директор информационной службы финансовой компании WP Carey Миколас Рамбус. — Нужна отраслевая группа, которая занималась бы разработкой спецификаций стандартов, организацией тестирования, а также решением множества других задач, включая создание базы знаний об обновлениях. С ее помощью я мог бы познакомиться с тем, как выполняют обновления другие компании и что при этом происходит».

Впрочем, особой надежды в голосе Рамбуса я не услышал.

Так или иначе, появление червя Slammer в определенной степени стало поворотной точкой. Яркой вспышки, за 10 минут охватившей огнем всю планету, и последовавшего комедийного представления с участием толпы пожарных, которые, на ходу разматывая свои шланги, взбежали на сцену и обнаружили, что здание уже сгорело, оказалось достаточно, для того чтобы у многих возникло твердое убеждение: на практике система обновлений не работает.

«Со своей стороны я предложил бы считать задачу обновления зоной ответственности производителей, а расходы, необходимые для ее решения, возложить на клиентов,» — заметил Рамбус.

Что ж, для Рамбуса есть как хорошие, так и плохие новости. Хорошо, что производители заинтересованы в совершенствовании процедуры обновлений. И они всерьез стремятся к повышению своей конкурентоспособности. А поиск необходимого лекарства заметно оживился после нашествия Slammer.

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

Больше или меньше

Существуют две противоположные друг другу философии обновлений: обновлять больше или обновлять меньше.

Производители, считающие, что обновлять нужно как можно чаще, практически ежедневно, сформировали новый класс программного инструментария, названный «средствами управления обновлениями» (Patch Management). Этот термин означает, что разные вещи адресованы разным людям (один из разработчиков уже предложил ввести «управление виртуальными обновлениями» — Virtual Patch Management), но в общем случае система управления обновлениями автоматизирует процедуру поиска, загрузки и установки заплат. Сторонники частых обновлений уверены в том, что сами по себе обновления не вызывают никаких затруднений, сложности возникают лишь с руководством по их проведению. Поверхностный контроль за внесенными изменениями и автоматическим развертыванием программного обеспечения, невнимательность при анализе потенциальных конфликтов и определении порядка отката (в случае обнаружения конфликтов) порождают, по мнению представителей данного направления, необходимость в исправлении обновленных версий. А инструменты управления обновлениями помогут оставаться на уровне, отвечающем самым последним требованиям, и исключить возможность человеческой ошибки.

Тим Райс уже успел протестировать инструментарий управления обновлениями на 550 машинах. Но если оказывается, что системе требуется 10 тыс. заплат, вряд ли это хорошо.

«Без сомнения, данный инструментарий скрывает в себе немалую мощь, но вместе с тем автоматизация оставляет вас беззащитными перед исправлениями, содержащими ошибки, — наверняка при этом Райс подумал об обновлениях, которые разрушили его дисковый массив. — Автоматизация нужна мне для того, чтобы упростить установку исправленных версий. Я не хочу использовать автоматизированную процедуру управления обновлениями».

Политику минимизации обновлений представил Питер Типпетт, директор по технологиям компании TruSecure. Типпетт не устает говорить об ошибках, встречающихся в обновлениях. Он убежден, что все проникновения в систему осуществляются через ограниченный набор уязвимых мест, доля которых не превышает 2% общего числа существующих брешей. Следовательно, большую часть обновлений устанавливать просто нет смысла. Говоря в терминах управления рисками, в лучшем случае эти меры окажутся излишними, а в худшем — повысят вероятность возникновения рисков.

Вместо этого Типпетт советует улучшать политику безопасности — блокировать порты, открывать которые нет смысла, — и платить независимым организациям за консультации по поводу того, какие обновления устанавливать необходимо, а какие можно проигнорировать. «Более половины из 72 наиболее опасных уязвимостей, обнаруженных в продуктах Microsoft в прошлом году, никем не использовались, — констатировал он. — Проводя обновления, мы следуем худшей из возможных моделей уменьшения вероятности риска».

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

«Даже в стремлении к минимизации обновлений подобную позицию занимать нельзя, — заметил Бернс. — Когда для проникновения будет использовано неизвестное системе уязвимое место — а это непременно произойдет — придется изрядно поломать голову. Типпетт придерживается старой школы анализа рисков».

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

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

«Могу понять замешательство руководителя, который предпочитает забыть обо всем и смириться с невозможностью установки всех обновлений, — отметил Эрнан. — С одной стороны, он может отказаться от проведения обновления. С другой — шансы на установку очередной заплаты тоже достаточно велики».

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

Уинн также испытывает двойственное отношение к этому вопросу: «Если вы считаете технологии управления обновлениями универсальным лекарством, то ошибаетесь. Воспринимайте это как нечто, требующее постоянного совершенствования. Я предпочитаю придерживаться золотой середины».

Эпилог

В ближайший после атаки Slammer понедельник Microsoft повторно выпустила заплату MS02-061, предназначенную для ликвидации утечки памяти и замены библиотеки ssnetlib.dll. Установить ее в этот раз было гораздо проще. Правда, к этому моменту нашествие Slammer уже приняло характер эпидемии. Да и сама корпорация достаточно серьезно пострадала от вируса, дав многим повод для злорадства. Сети Internet-провайдеров были парализованы; сразу несколько корневых серверов DNS не могли справиться с нагрузкой; авиакомпании отменяли полеты; банкоматы отказывались выдавать деньги. Канаде пришлось даже отложить национальные выборы.

И после всего этого заплаты в лучшем случае лишь несколько смягчили эффект Slammer. Помешать червю продолжить свой путь и нанести тем самым еще более серьезный ущерб мировому сообществу помогла необычная инициатива провайдеров. В тот злополучный понедельник они приняли совместное решение блокировать трафик, поступающий на порт UDP 1434, который Slammer избрал для своего распространения. «Только это и позволило нам выжить», — заметил Купер.

Естественно, как только провайдеры блокировали входную дверь, компании сразу ухватились за возможность модернизации, тестирования и установки новых заплат. А те, кто почувствовал себя готовым к этому, сразу перешли к развертыванию SP3. Людям была предоставлена возможность воспользоваться подаренным им временем для поиска и исправления всех MSDE-компонентов, с тем чтобы покончить со Slammer раз и навсегда.

Тем не менее десять дней спустя, когда провайдеры вновь открыли порт 1434, на серверах SQL Server произошла новая вспышка инфекции. А еще через полгода были опубликованы данные службы слежения Wormwatch.org, согласно которым Slammer в середине июля оставался самым распространенным вирусом, существующим в естественных условиях. Он встречался вдвое чаще любого другого червя. Slammer по-прежнему забрасывал свои сети, выискивал системы, которые не обновлялись, и заражал их.

Scott Berinato. Patch and Pray. CSO, August 2003.