В номере от 14.08 ComputerWorld Русская Редакция опубликовала на первой полосе статью под названием "Ядерщики находят ошибку в SQL Server" ( http://www.osp.ru/cw/2001/28-29/cover.htm ), в которой утверждается, что Лос-Аламосская национальная лаборатория (США) и Курчатовский институт (Россия), использующие SQL Server в системах учета ядерных материалов, столкнулись с потерей информации в базе данных из-за багов в ПО Microsoft.
Данная статья является безграмотной компиляцией шумихи, которая поднялась в западной печати в начале июля, когда Вашингтон Пост опубликовала статью Брюса Блэра «Nukes: A Lesson From Russia» ( http://www.washingtonpost.com/wp-dyn/opinion/A44053-2001Jul10.html ), подхваченной и растиражированной многочисленными СМИ. Через несколько дней эта пурга докатилась до Европы ( http://www.heise.de/newsticker/data/lab-16.07.01-002/ ), а теперь с некоторым опозданием и до России. Чисто по-человечески понять репортеров можно: лето, жарко, новостей нет, читатели спят и вдруг бац – просто подарок судьбы какой-то. Сразу три жареных темы в одном флаконе: ядерное топливо, Россия и Microsoft. Международные террористы охапками выносили неучтенный плутоний, но умелые русские программисты предотвратили 3-ю мировую, своевременно обнаружив дырку. Оказывается, не все эти русские сплошь коварные хакеры, есть среди них и те, что не зря кушают гуманитарную помощь. Ну а дырка, сами понимаете, была не в заборе, а в маздайном софте, потому что где ж еще ей быть, как не у этого монополиста недоразделенного. В общем, чем дальше, тем страшнее сгущаются краски, а также более бестолково и запутанно все излагается.
Короче, если отбросить всю эту ботву, то техническое существо вопроса излагается здесь: http://www.cdi.org/nuclear/nukesoftware.html, откуда следует, что речь никоим образом не идет о пропаже данных из базы. Проблема состояла в том, что запрос типа
DECLARE @X int
SELECT @X = 0
SELECT @X = id FROM sysobjects WHERE id > @X AND type = 'P' ORDER BY id DESC
SELECT @X
в версии 6.5 возвращал некорректные результаты (отличные от тех, которые получались, если в условии WHERE вместо локальной переменной использовать константу: id > 0), из чего могло сложиться неверное представление о физическом исчезновении записей из таблицы. В течение дня после обращения клиента был предоставлен соответствующий hotfix. Последующие версии продукта эту ошибку не содержали. Вторая проблема, преподносимая как серьезная брешь в системе безопасности SQL Server, в действительности связана с вопросами connectivity. Если Вы имеете два логина, скажем, «sa» и «sa;», оба c одинаковыми (например, пустыми паролями), то Query Analyzer будет логинить «sa;» как «sa». Это происходит из-за того, что при формировании строки соединения типа символ «;» воспринимается как завершение свойства. В то же время присвоение значения каждому свойству в отдельности:
cnn.Properties(“User ID”) = “sa;”
cnn.Properties(“Password”) = “”
приводит к правильному результату. Таким образом, если здесь и идет речь о баге, то только в документации, которая не приводит «;» среди запрещенных символах в логине. Следует также отметить, что пустой пароль системного администратора вообще не способствует повышенной защищенности, а в серьезных проектах Microsoft всегда рекомендует использование не стандартного, а интегрированного с Windows NT /2000 режима аутентификации.
И последнее. Собственно, все описанные события происходили в мае 2000 г. Возникает вопрос: кому на руку ворошить события более чем годовой давности в преддверии выхода 64-разрядных версий Windows XP и SQL Server, ориентированных на применение в крупных организациях в том числе и госсектора, где в настоящее время особенно велика доля Sun и Oracle?