Фаталните компютърни бъгове

Болшинството софтуерни бъгове (нали знаете какво е това?) всъщност са дребни, понякога комични грешки в създавания от програмистите код, които водят до често невидими за окото проблеми. Понякога обаче дори малко недоглеждане от страна на създателите на софтуера води до сериозни загуби на данни, блокиране на услуги или дори в някои случаи до смърт!

Все пак софтуерът се пише от хора и абсолютно всеки продукт притежава своите бъгове или „недокументирани възможности“, както търговците често обичат да ги наричат. Но това са случаите, в които софтуерът просто прави нещо, което не би трябвало, или обратното – не прави нещо, което е длъжен да прави. Бъговете могат да се появят заради лошо софтуерно планиране, неразбиране на поставените задачи или съвсем проста човешка грешка при изписване на важни ключови думи или числа. Точно като печатните грешки при книгите. Но ако при хартиените книги е лесно за четящия човек, намирайки грешна дума, просто да се досети коя е вярната или да я игнорира, то за компютрите това е голям проблем. Те са достатъчно „глупави“, за да не могат да съобразят какво да направят, и оттам може да се стартира поредица от грешки, понякога фатални.

Ето няколко интересни случая на технически бъгове, след които последиците са били огромни или дори исторически.

 

Therac-25 (1985 – 1987 година)

Therac-25 била специализирана медицинска машина, за лъчетерапия на пациенти с онкологични заболявания. Тя имала два режима на работа. Първият представлявал прецизно насочване на сноп електрони върху пациента на малки дози за кратко време. При вторият обаче лъчът използвал многократно по-голяма енергия и затова се насочвал отначало върху метална мишена, която преобразувала електронния сноп в рентгенови лъчи, след това предавани към пациента.

В първите модели на Therac заради втория режим на работа съществували физически защити (блокажи), които да гарантират правилното позициониране на металната плоча преди терапията. В противен случай било възможно високоенергийният сноп лъчи да попадне директно върху незащитеното тяло на пациента. И познайте… поради ред причини в по-новите модели физическите (хардуерни) защити били подменени със… софтуерни!

За нещастие малко след това се оказало, че в софтуера съществува бъг от типа на arithmetic overflow – грешка, при която резултатът е многократно (с цели порядъци) по-голям от предвидения. И това се случвало за зла участ именно по време на автоматичните проверки за безопасност. Получавайки неочаквано големи данни, системата отказвала за момент и металната мишена не се премествала на точната позиция. В резултат лъчение със стократно по-висок интензитет от безопасния се „изливало“ върху пациента, причинявайки му радиационно отравяне. Това се случило на 6 човека, 4 от които по-късно починали вследствие на инцидентите.

 

World of Warcraft “Corrupted-Blood” (13.09.2005)

Не съм играл тази игра и моля, ако някой от вас е попадал на посочения проблем, да добави своите наблюдения. Но ми се вижда адски любопитен и дори забавен - чак ме е яд, че не съм го видял на живо. Но добре, че става дума за „виртуална“, а не реална смърт.

Големият хит на Blizzard (WoW) през годините страда от различни бъгове, което е нормално за проект от такава величина. Много смущаващ инцидент обаче се случва след ъпдейт на играта на 13 септември 2005 година, който причинява масова виртуална смърт. Ъпдейтът съдържал нов персонаж (Hakkar), който притежавал интересната способност да причинява зараза, наречена Corrupted Blood (буквално „повредена кръв“). Той можел да предава на околните играчи заразата, която изсмуквала безжалостно живота им за определен (кратък) период време. Разбира се, болестта се предавала и от играч на играч, точно като в реалния свят и можела да убива всеки, имал досег с нея. Ефектът бил замислен да действа само в зоната на играта, в която участвал Hakkar.

 

Само че едно нещо не било предвидено. Че играчите можели да се телепортират в други зони от играта, докато още са инфектирани, и да предават болестта на останалите. И точно това се случило – лавинообразно! До ден-днешен не е ясен точният брой на „жертвите“, но цели виртуални градове в играта свят се оказали безлюдни, изпълнени с труповете на умрели играчи, покриващи улиците. Било наистина страховита гледка!

За щастие смъртта на играча в WoW не е постоянна и гафът бързо стига до знанието на администраторите, които рестартират сървърите и обновяват софтуера, изчиствайки грешката. Само че реакциите на много играчи по отношение на ефекта от масовото измиране били близки до този на реален инцидент. Чисто и просто „изкарали си акъла“!

САЩ в мрак (14.08.2003)

Сигурно си спомняте това събитие, което засегна около 55 милиона души, предимно в североизточните щати, както и Онтарио (Канада). Това беше едно от най-големите прекъсвания на тока (Blackouts) в историята. Всичко започва, когато електроцентрала на брега на езерото Ери излиза от строя заради претоварване, което от своя страна оказва влияние на голяма част от електропреносната мрежа. Когато тя (или грубо казано жиците) е подложена на тежко натоварване, започва нагряване и кабелите (най-често от алуминий и стомана) се разширяват. Няколко такива жични линии се отпускат заради разширението от топлината, увисват, закачат близките дървета и се прекъсват, което води до все по-нарастващо претоварване на общата система. Каскадният ефект на отказ на работата на станциите води до цели 20% намаляване на захранването на енергийната мрежа на САЩ, което е сериозно нещо.

 

Макар че конкретният случай не е с точно доказан произход (софтуерен бъг), то едва ли щеше да е факт, ако системата бе сработила както е била проектирана. Алармиращата за такива случаи схема действа по „състезателния сценарий“ – тоест, ако две части на енергийната система се съревновават за определен енергиен ресурс и няма как да се реши автоматично към коя да се пренасочи енергията, то трябва да се включи алармена система, която да предупреди работещите в енергийния център. При инцидента обаче тази система не е сработила и служителите не са получили информация за ситуацията веднага. Представете си – заради буквално една лампичка или звуков сигнал!

Последиците от това несработване на обикновен елементарен уред са цели градове без ток за няколко дни, засегната индустрия, служби, комуникации. „Затъмнението“ дори води до няколко недоказани смъртни инцидента.

 

Самолетоносачът USS Yorktown (21.09.1997)

В света на софтуерното програмиране съществуват няколко основни широкоизвестни бъгове, с които програмистите са добре запознати. Например divide by zero, който представлява объркваща стандартните компютърни системи калкулация, при която което и да е число се дели на нула. Такова изчисление е невъзможно, освен ако не се използва специална висша математика. Затова повечето компютри – всички от джобния калкулатор до суперкомпютъра, са проектирани да взимат това под внимание.

 

Само че през септември 1997-а се получава сериозно объркване, когато американският самолетоносач USS Yorktown претърпява пълен отказ на задвижващите си системи и се носи буквално „мъртъв“ из океана за цели 3 часа, защото член на екипажа изписва числото 0 в ключова система за управление на базата данни. Този софтуер е част от по-широка компютърна мрежа, използвана за автоматично управление на корабите така, че да намали командния състав. Предизвикването на divide by zero бъга води до спирането на функционирането и следователно корабът спира да се движи.

За щастие самолетоносачът по време на инцидента участвал само в маневри вместо в учение или истинско сражение, иначе последиците щяха да са далеч по-сериозни. От едно натискане на клавиша НУЛА!

На ръба на ядрена война (26.09.1983)

Станислав Петров е името на офицера от секретен бункер край Москва, който вероятно е спасил човечеството от ядрен ужас. Той следял за действието на руската система за ранно предупреждение от ядрени атаки (изстрелване на ракети). Минути след полунощ на конкретната дата в центъра, за който отговаря се, получава информация, че от американска територия са изстреляни междуконтинентални балистични ракети. Като част от утвърдената доктрина през Студената война, задълженията на всеки офицер на такава длъжност са били – незабавен отговор на атаката с ядрен удар към предварително набелязани цели.

 

Това означава, че ако първоначалната атака е истинска, трябва да се отговори бързо. На Станислав Петров обаче прави впечатление странният факт, че американците нападат само с няколко бойни глави, въпреки че можели да сторят това със стократно по-големи размери. Няколко ракети не биха могли да сторят кой знае каква вреда на огромния Съветски съюз. Освен това наземните радарни станции не прихващали нищо, макар че „изстреляните ракети“ били далеч зад хоризонта, т.е. скрити зад него няма как да бъдат засечени от обикновен радар.

Още едно допълнително съображение, което взима предвид руският офицер, за да прецени действията си е, че системата за ранно предупреждение по онова време има доста пропуски и той добре знаел какви са. „Претегляйки“ всички факти и оценявайки ситуацията, той решава да третира събитията като фалшива аларма. И въпреки че реално няма пред себе си „червен бутон“, който да натисне и да изстреля ракети, а трябва да придвижи решението за това към по-горна инстанция, той информира за инцидента с препоръка за изчакване и спиране на незабавния отговор. Ако този човек бе следвал инструкциите, без да мисли, и рискува, ситуацията неминуемо щеше да доведе до ядрена война. За щастие на база на опита, интуицията или просто късмета си решението на Петров е правилно.

По-късно става ясна причината за фалшивата тревога в софтуера за ранно предупреждение. Компютрите отчели отражението на слънцето в облаците като огън от реактивни струи и докладвали за изстрелване на вражески междуконтинентални ракети.

 

 

Защитата от копиране на Audio CD на Sony

Всички знаем какво е софтуерното пиратство. Каквито и защити от копиране да се измислят и въвеждат на CD, DVD, Blu-Ray и т.н., скоро след това се намират начини за преодоляването им и всичко започва отначало.

Само че от Sony стигат твърде далеч в тази битка и през 2005 година представят нова система за защита от копиране на аудио дисковете си. Когато сложите оригинален диск в Windows-базиран компютър, то в последния невидимо и автоматично се инсталира рууткит (софтуерен код на ниско ниво, който позволява почти невидимо следене и манипулиране на системата). Въпреки че този рууткит не е вредоносен по своята същност, той служел на Sony за контрол на Windows системите, който да предотвратява копирането и конвертирането на музиката към MP3 формат. От компанията се надявали, че така ще намалят загубите си от софтуерното пиратство.

 

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

 

Бъг в ракетните системи Patriot (25.02.1991)

По време на операция „Пустинна буря“ в Ирак, целяща свалянето на Саддам Хюсеин от власт, американската армия разполага своите противоракетни системи „Пейтриът“, за да пази позициите си. Софтуерът, който ги задвижва, използва скоростта на своята цел, както и текущото време, за да предскаже и изчисли предварително позицията на целта и да може да я порази ефективно. Но тъй като една летяща ракета развива твърде голяма скорост (до 5 пъти по-висока от звука), то тези изчисления трябва да бъдат изключително точни.

По онова време имало известен бъг в софтуера за проследяване на целите. С течение на времето вътрешните часовници на системата изоставали (като всеки нормален часовник), което, натрупвайки се с времето, водело до малки разлики, които обаче при свръхточните изчисления ставали причина за сериозни разминавания. За да избегнат този бъг, военните трябвало периодично и често да рестартират системата и по този начин да сверяват и „ресетват“ часовника.

 

За жалост някои от хората на командни постове явно не разбрали добре този проблем и оставили системата да работи без рестарт за цели 100 часа. Когато иракската армия изстреляла ракета с цел американско летище в Дахран, Саудитска Арабия, тя веднага била засечена от системата "Пейтриът". Само че към дадения момент часовникът и изоставал с 0,34 от секундата и при изчисленията къде ще се намира ракетата в следващия момент, тя сгрешила с разлика от половин километър спрямо реалната позиция. Системата реално „не виждала“ вражеска ракета, приела атаката за фалшива, и се изключила.
Само че ракетата реално продължавала да лети към целта си, поразила я и убила 28 войници, като ранила още 98. И това само заради един рестарт…

Millenium Bug

Нарочно го пиша на английски, за да се сетите. Е, ако сте под 20-годишни може и да не помните този проблем, но няколко години преди датата 1 януари 2000 година из световната преса се носеха апокалиптични заглавия, хвърляха се огромни средства за предпазване от ужасния проблем, който бе „надвиснал“ над света.

Y2K проблемът води началото си от там, че в средата на миналия век, когато са създавани и пускани първите операционни системи и компютри, те работели и разпознавали годината от датата само с две цифри. Например годината 1995, те разпознавали само като 95. По онова време това решение било логично, спестявало памет, изчисления и пр.

 

Цялата истерия започва, когато някой решава, че следвайки тази логика, с настъпването на годината 2000 компютърните системи ще отчетат 00 и ще решат че сме в 1900 година. Което може да доведе до страховити последици, като например в данъчното изведнъж да се окаже, че някой, роден през 1920 година, е на минус 19 години.

В отговор на проблема софтуерните компании бързо започват да ъпдейтват своите продукти, които вече контролират всичко – от банковата система, до болнични компютри, транспорт и каквото се сетите. Дори е създаден световен Y2K център през февруари 1999 година, за да помага в координацията между правителства и организации. В края на краищата новата 2000 година настъпва почти без никакви инциденти (аз лично не знам никакви!) въпреки страховития шум и милионите изсипани безсмислено долари.

Трудно е да се каже до каква степен липсата на апокалипсис е следствие на положените от компаниите усилия или пък просто проблемът е бил преекспониран прекалено много от медиите. Може би отговорът е някъде по средата. Но факт е, че нищо особено не се случи.

 

Year 2038

Въпреки че успешно преминахме Y2K проблема, то все още не сме избегнали ядовете с „часовниците“. Не всички компютърни системи обработват времето еднакво, а много от UNIX-базираните изчисляват датите, сравнявайки колко секунди са изминали спрямо датата 01.01.1970 година. Например датата 01.01.1980 г. за тези машини означава „315 532 800 секунди след 01.01.1970 г.“. Това число е кодирано поначало в тях като 32-битово непроменящо се число (32-bit integer). Само че, както програмистите знаят, 32-битовото число има size limit (граница) от 2 147 483 647. За по-големи числа 32-битовият регистър не е достатъчен.

Това означава, че дати, които са до 2 147 483 647 секунди, ще бъдат отчитани правилно. Но след това? Ако изчислите колко са 2 147 483 647 след първи януари 1970 година, ще получите… 19 януари 2038-а. След което отново ще си имаме проблеми.

 

Разбира се, не трябва да се притеснявате относно този факт. Въпреки че изглежда страшно, то до настъпването на тази дата едва ли ще са останали толкова стари компютри и операционни системи, които да не са ъпдейтвани с по-нови версии на хардуерно и софтуерно ниво. Освен това за един домашен компютър това не би било проблем – той ще се коригира и ръчно. Проблем по-скоро би се появил при специализирани системи, като например роботизирани линии за производство, цифрови часовници, мрежово оборудване, системи за сигурност. Но пак казвам – едва ли след 23 години някой ще използва половинвековно оборудване, нали?