infosecurity
@tg_infosec
? Деление на ноль: катастрофические последствия программных ошибок.
• Практика не устает доказывать, что в любом ПО самая главная уязвимость — человеческий фактор. И неважно, появился ли баг из-за нехватки квалифицированности специалиста, выжил после долгих часов дебага в поисках ошибки, или считался хитро замаскировавшейся фичей. Иногда ошибки приводят не только к неприятностям в жизни рядового разработчика, но и вызывают настоящие катастрофы. Вот несколько историй о таких багах и их последствиях:
• В 1997 американский ракетный крейсер «Йорктаун» (CG-48), на котором были установлены 27 компьютеров (Pentium-Pro на 200 МГц), решил поделить на ноль и полностью вышел из строя.
Компьютеры работали на Windows NT — и работали они ровно так, как вы и ожидаете, узнав название оси. В то время ВМФ США старался максимально широко использовать коммерческое ПО с целью снижения стоимости военной техники. Компьютеры же позволяли автоматизировать управление кораблем без участия человека.
• На компьютеры «Йорктауна» поставили новую программу, управляющую двигателями. Один из операторов, занимавшийся калибровкой клапанов топливной системы, записал в одну из ячеек расчетной таблицы нулевое значение. 21 сентября 1997 года программа запустила операцию деления на этот самый ноль, началась цепная реакция, и ошибка быстро перекинулась на другие компьютеры локальной сети. В результате отказала вся компьютерная система «Йорктауна». Потребовалось почти три часа, чтобы подключить аварийную систему управления.
• Схожая проблема с нулем возникла при испытании истребителя в Израиле. Безупречно работавший самолет на автопилоте пролетел над равнинной частью, над горной частью, над долиной реки Иордан и приблизился к Мертвому морю. В этот момент произошел сбой, автопилот выключился, и пилоты посадили истребитель на ручном управлении.
• После долгих разбирательств удалось выяснить, что программы автопилота при вычислении параметров управления производили деление на значение текущей высоты истребителя над уровнем океана. Соответственно, у Мертвого моря, лежащего ниже уровня океана, высота становилась нулевой, провоцируя ошибку.
• В мире найдется немало историй, когда обновление софта, совершаемое с самыми благими целями, могло повести за собой множество проблем. В 2008 году атомная электростанция в штате Джорджия (США) мощностью 1,759 МВт в экстренном режиме приостановила работу на 48 часов.
• Инженер компании, занимающейся технологическим обслуживанием станции, установил обновление на главный компьютер сети АЭС. Компьютер использовался для слежения за химическими данными и диагностики одной из основных систем электростанции. После установки обновлений компьютер штатно перезагрузился, стерев из памяти данные управляющих систем. Система безопасности станции восприняла потерю части данных как выброс радиоактивных веществ в системы охлаждения реактора. В результате автоматика подала сигнал тревоги и остановила все процессы на станции... Вот такие дела...
#Разное
• Практика не устает доказывать, что в любом ПО самая главная уязвимость — человеческий фактор. И неважно, появился ли баг из-за нехватки квалифицированности специалиста, выжил после долгих часов дебага в поисках ошибки, или считался хитро замаскировавшейся фичей. Иногда ошибки приводят не только к неприятностям в жизни рядового разработчика, но и вызывают настоящие катастрофы. Вот несколько историй о таких багах и их последствиях:
• В 1997 американский ракетный крейсер «Йорктаун» (CG-48), на котором были установлены 27 компьютеров (Pentium-Pro на 200 МГц), решил поделить на ноль и полностью вышел из строя.
Компьютеры работали на Windows NT — и работали они ровно так, как вы и ожидаете, узнав название оси. В то время ВМФ США старался максимально широко использовать коммерческое ПО с целью снижения стоимости военной техники. Компьютеры же позволяли автоматизировать управление кораблем без участия человека.
• На компьютеры «Йорктауна» поставили новую программу, управляющую двигателями. Один из операторов, занимавшийся калибровкой клапанов топливной системы, записал в одну из ячеек расчетной таблицы нулевое значение. 21 сентября 1997 года программа запустила операцию деления на этот самый ноль, началась цепная реакция, и ошибка быстро перекинулась на другие компьютеры локальной сети. В результате отказала вся компьютерная система «Йорктауна». Потребовалось почти три часа, чтобы подключить аварийную систему управления.
• Схожая проблема с нулем возникла при испытании истребителя в Израиле. Безупречно работавший самолет на автопилоте пролетел над равнинной частью, над горной частью, над долиной реки Иордан и приблизился к Мертвому морю. В этот момент произошел сбой, автопилот выключился, и пилоты посадили истребитель на ручном управлении.
• После долгих разбирательств удалось выяснить, что программы автопилота при вычислении параметров управления производили деление на значение текущей высоты истребителя над уровнем океана. Соответственно, у Мертвого моря, лежащего ниже уровня океана, высота становилась нулевой, провоцируя ошибку.
• В мире найдется немало историй, когда обновление софта, совершаемое с самыми благими целями, могло повести за собой множество проблем. В 2008 году атомная электростанция в штате Джорджия (США) мощностью 1,759 МВт в экстренном режиме приостановила работу на 48 часов.
• Инженер компании, занимающейся технологическим обслуживанием станции, установил обновление на главный компьютер сети АЭС. Компьютер использовался для слежения за химическими данными и диагностики одной из основных систем электростанции. После установки обновлений компьютер штатно перезагрузился, стерев из памяти данные управляющих систем. Система безопасности станции восприняла потерю части данных как выброс радиоактивных веществ в системы охлаждения реактора. В результате автоматика подала сигнал тревоги и остановила все процессы на станции... Вот такие дела...
#Разное
? 15
? 10
? 4
52 5.3K
Обсуждение 0
Обсуждение не доступно в веб-версии. Чтобы написать комментарий, перейдите в приложение Telegram.
Обсудить в Telegram