Правдивая история из моих первых дней в Microsoft.
Вы не знали страха до того дня, как проснулись и увидели заголовок на ZDNet.com этим утром: «Наихудшая дыра в безопасности Internet Explorer, обнаруженная в« Бла », где« Бла »- это код, который вы написали сами шесть месяцев назад. ,
Сразу после начала работы я проверил журналы изменений и обнаружил, что кто-то из другой команды - кто-то, кому мы доверяли вносить изменения в продукт - проверил мой код, изменил кучу параметров ключа реестра безопасности без веской причины, проверил это, и никогда не получал обзор кода и никому не говорил об этом. По сей день я понятия не имею, что, черт возьми, он думал, что делал; он покинул компанию вскоре после этого. (По его собственному желанию.)
(ОБНОВЛЕНИЕ: несколько ответов на вопросы, поднятые в комментариях:
Во-первых, обратите внимание, что я предпочитаю занять благотворительную позицию, что изменения ключа безопасности были непреднамеренными и основаны на небрежности или незнании, а не на злобе. У меня нет доказательств, так или иначе, и я считаю, что разумно приписывать ошибки человеческим ошибкам.
Во-вторых, наши системы регистрации намного, намного сильнее, чем они были двенадцать лет назад. Например, теперь невозможно зарегистрировать код, если система регистрации не отправит заинтересованным сторонам список изменений. В частности, изменения, внесенные в конце цикла корабля, связаны с большим количеством «процессов», которые обеспечивают правильные изменения для обеспечения стабильности и безопасности продукта.)
В любом случае, ошибка заключалась в том, что объект, который НЕ был безопасен для использования из Internet Explorer, был случайно выпущен как помеченный как «безопасный для сценариев». Объект был способен записывать двоичные файлы - фактически, библиотеки типов OLE Automation - в произвольные места на диске. Это означало, что злоумышленник может создать библиотеку типов, содержащую определенные строки враждебного кода, сохранить ее по пути, известному как исполняемый файл, дать ему расширение чего-либо, что может привести к выполнению сценария, и надеяться, что пользователь каким-то образом случайно запустит код. Я не знаю ни одной успешной атаки в "реальном мире", в которой использовалась эта уязвимость, но с ней можно было создать рабочий эксплойт.
Мы отправили патч довольно быстро, позвольте мне сказать вам.
Я вызвал и впоследствии исправил еще много дыр в безопасности в JScript, но ни одна из них никогда не была так близка к публичности, как одна.