http://geektimes.ru/post/241460/

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

Паук смерти

Эта уже старая (примерно 8 лет давности) история прекрасно иллюстрирует, как легко тотальное головотяпство может всё испортить. Джош Брекмэн работал в компании, которая получила крупный заказ на разработку системы управления содержимым для сайта государственной структуры. CMS была нужна для того, чтобы работники могли редактировать контент на сайте. У заказчика уже был крупный сайт, поэтому для переноса старого контента потребовалось какое-то время. Через несколько месяцев новый сайт был готов к запуску.

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

Злостным хакером оказался не кто-то из-за океана — из Китая, России, Индии или ещё какого-нибудь известного своими недружелюбными хакерами государства. Это был googlebot.com. Нет, компания Google не занимается и занималась взломом сайтов госаппарата для того, чтобы вот так глупо нахулиганить. Как выяснилось позже, участия человека не было в принципе. Вот, что произошло на самом деле:

• Кнопки редактирования и удаления использовали метод GET, а не POST. Это означает, что URL кнопок «Удалить» и «Редактировать» содержали все необходимые идентификаторы для доступа к ним.
• Эти URL каким-то образом попали на страницы сайта — наверное, один из сотрудников, наполнявших сайт, случайно их скопировал.
• Проверка, залогинен ли пользователь, включала в себя чтение куки isLoggedOn. Если её значение установлено на false, то получить доступ к защищённому содержимому не удастся. Но бот-паук Google не использует куки, поэтому он легко обошёл эту «защиту».
• Боту было всё равно до Javascript-кода, который должен был перенаправить пользователя на страницу авторизации. Его интересовали все ссылки на странице, включая ссылки на кнопках удаления.
• Не было на сайте и нормального robots.txt. И бот перешёл по всем ссылкам кнопок «Удалить», сводя долгую работу контент-менеджеров на ноль.

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

Электронное письмо на 500 миль

Эта история датируется 24 ноября 2002 года, когда она была впервые опубликована. На самом деле она произошла раньше, примерно в периоде 1994—1997 годов, просто её автор — Трей Харрис — предпочитал оставлять её в качестве особо интересного анекдота для общения на деловых и не очень встречах. Несколько моментов в ней изменены (к примеру, сначала он исправил проблему, а лишь позже начал расследование), но, как утверждает автор, она действительно случилась.

Харрис обслуживал работу электронной почты кампуса университета Северной Каролины в Чапел-Хилл. Большая часть почтовых серверов кампуса обслуживалась Sendmail с конфигурационными файлами, которые были написаны Харрисом. Однажды системному администратору позвонил глава отдела статистики.

— У нас возникли проблемы с отсылкой писем отдела.
— Какие проблемы? — спросил я.
— Мы не можем отослать электронное письмо дальше, чем на 500 миль, — ответил он.
Я поперхнулся кофе.
— Что?
— Мы можем слать электронные письма только на 500 миль. Вообще, немного больше. Скажем, 520. Но не дальше.
— Ну-у… Электронная почта так не работает, в общем-то, — ответил я, пытаясь сдержать замешательство в собственном голосе. Замешательство показывать начальнику отдела нельзя, пусть это и какой-то захудалый отдел статистики. — Что заставляет Вас думать, что письма не идут дальше 500 миль?
— Это не то, что я думаю, — вспыльчиво начал он. — Видите ли, когда мы впервые заметили это несколько дней назад…
— Вы ждали дни? — прервал я его со звоном в голосе. — И вы не могли слать имейлы всё это время?
— Мы могли. Просто не дальше…
— …чем на 500 миль, — закончил я. — Я понял. Но почему вы раньше не позвонили?
— Ну, до этого момента у нас было недостаточно данных для уверенности в том, что происходит на самом деле, — ага. Это отдел статистики. — Так вот, я попросил одну из наших геостатистиков посмотреть, что…
— Геостатистик…
— …да, она сделала карту с радиусом, по который мы можем слать письма, и получилось чуть больше 500 миль. Однако внутри этого радиуса есть точки, до которых мы посылать письма не можем, а до некоторых можем, но не всегда. Дальше этого радиуса не получается.
— Понятно, — ответил я и обхватил голову руками. — А когда это началось? Вы сказали, что несколько дней назад. Что-то с системой менялось в тот период?
— Ну, приходил работник, пропатчил наш сервер и перезагрузил его. Но я ему уже звонил, и он сказал, что почтовик не трогал.
— Ладно, сейчас гляну и перезвоню, — я положил трубку, с трудом пытаясь убедить себя, что это была не шутка. Нет, это было не первое апреля. Я пытался вспомнить, не должен ли кто-то меня разыграть.

Харрис немедленно попробовал отослать несколько писем. Письма без проблем шли до Исследовательского треугольника Северной Каролины, Ричмонда, Атланты, Вашингтона и Принстона. Но до Мемфиса письмо не шло. Аналогичная ситуация случилась с серверами в Бостоне и Детройте. Харрис начал сужать поиск: Нью-Йорк (420 миль) работал, но Провиденс (580) — нет.

Здесь ему начало казаться, что он теряет рассудок, но после провалившейся попытки отослать письмо другу в Северной Каролине, сетевой провайдер которого имел соединение в Сиэтле, стало ясно, что дело не в географии.

Проверка конфигурационного файла sendmail.cf показала, что его не редактировали, это был тот же файл, который написал Харрис. Опции FAIL_MAIL_OVER_500_MILES там тоже не было и быть не могло. Администратор соединился с SMTP-портом по Telnet, и он радостно ответил баннером Sendmail SunOS.

И лишь здесь начала обнаруживаться причина всех проблем. В то время Sun всё ещё включала Sendmail 5 в свою операционную систему, несмотря на хорошую степень работоспособности Sendmail 8. Харрис неплохо разбирался в этом вопросе, поэтому поставил новую версию и написал к ней конфигурационные файлы. Само собой разумеется, что они включали переменные только для Sendmail 8.

Детали головоломки встали на своё место: тот работник пропатчил сервер и обновил версию SunOS, чем откатил версию Sendmail. Файл sendmail.cf остался без изменений, и по какой-то причине Sendmail 5 мог частично использовать эту новую версию конфигурационного файла. Новые, незнакомые настройки пропускались. Незаданные опции приравнивались нулю.

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

Харрис открыл консоль.

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds
You want: miles
        * 558.84719
        / 0.0017893979

«…500 миль. Вообще, немного больше.»

Падение почтового сервера

Очень часто корпоративные и публичные почтовые сервера забиваются копиями писем при неправильной настройке каких-то фильтров, автоответов или правил. Кэролайн Зилонка приводит типичный пример подобной ситуации. Она отослала письмо с темой “Fuck this shit”, и на него сработал языковой фильтр.

Этот фильтр выслал типичное предупреждение о том, что использование подобной лексики недопустимо. Но письмо-ответ имело тему “Re: Fuck that shit”, поэтому уже на это письмо фильтр сработал опять, ответив письмом “Re: Re: Fuck that shit”. Цикл продолжился.

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

Целочисленное переполнение

Традиционную в США и Канаде песенку «99 бутылок пива» в контексте этой ошибки дают в таком виде:

0 бутылок пива на стене
0 бутылок пива!
Возьми одну, пусти по кругу
4 294 967 295 бутылок пива на стене!

Это шутка об ошибке integer overflow, целочисленном переполнении (или недополнении?). 32-битное беззнаковое целое число не может хранить отрицательные значения, и здесь не проверяется на корректность, когда мы вычитаем из него единицу. В результате получается 2³²−1, или 4 294 967 295.

Эта ошибка распространена повсеместно, но наиболее известным её проявлением является поведение Махатма Ганди в самой первой игре легендарной серии «Цивилизация» (Civilization).

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

Игрок может управлять целым государством. Геополитика, культура, наука, религия, индустрия, международные отношения, войны и другие аспекты игры имеют сложную математическую модель с множеством параметров.

Реальный Ганди являлся автором философии ненасилия в борьбе за независимость Индии от Великобритании. И создатели игры решили отразить это: его параметр агрессии был равен 1 по шкале от 1 до 10, что значило минимальный уровень насилия с его стороны.

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

Конечно же, этот баг был исправлен в следующих играх серии. В последней, пятой «Цивилизации» его решили добавить, но в виде «пасхального яйца»: Ганди действительно ведёт себя мирно, но он куда более всех остальных лидеров (их значение находится в районе 4—6, максимум 8) склонен использовать ядерное вооружение (значение 12). После достижения атомной эры Индия легко может сделать несколько ядерных ударов.