"Ilu programistów trzeba...", czyli 7 błędów w programach, które łatano latami

Flashowy exploit IE6

Jak długo istniał błąd: 12 lat i 9 miesięcy

Data powstania: sierpień 2001

Data usunięcia: maj 2014

Ta konkretna luka powstała w czasach, gdy MS Internet Explorer niepodzielnie dominował na rynku przeglądarek – był źle napisany, powolny, dziurawy i niewygodny w obsłudze, ale i tak korzystało z niego 90% internautów.

Czasy się jednak zmieniły i okres dominacji IE6 odszedł w niepamięć – ale jeszcze rok temu (w sierpniu 2014 r.) z przeglądarki tej korzystało niespełna 1,7% internautów. Ci ciekawe, to właśnie wtedy firma FireEye znalazła w niej lukę związaną z obsługą Flasha, która mogła być wykorzystana do zdalnego uruchomienia kodu. Microsoft potraktował sprawę poważnie i przygotował poprawkę – faktem jednak jest, że powstała ona dopiero prawie 13 lat po tym, jak ów błąd wprowadzono do kodu.

Virtual DOS Machine w Windows NT

Jak długo istniał błąd: 16 lat i 8 miesięcy

Data powstania: lipiec 1993

Data usunięcia: marzec 2010

Gdy Microsoft prezentował w lipcu 1993 r. Windows NT, czyli swój pierwszy system 32-bitowy, koncern nie chciał „osierocić” użytkowników aplikacji 16-bitowych – wprowadził więc do nowego OS-u rozwiązanie o nazwie Windows NT Virtual DOS Machine (VDM – umożliwiało ono uruchamianie aplikacji 16-bit w serwisie 32-bit).

16 lat później słynny specjalista od luk w oprogramowaniu, Tavis Ormandy (z Google’a) znalazł w NT VDM poważny błąd, pozwalający na wykonywanie w systemie akcji z uprawnieniami, których użytkownik teoretycznie mieć nie powinien. Mimo że o Windows NT mało kto już wtedy pamiętał, Ormandy zgłosił błąd do Microsoftu, a koncern go załatał (aczkolwiek dopiero po kilku miesiącach od otrzymania informacji o problemie).

Fot. Sam Howzit CC BY 2.0

Podatność OpenSSL ChangeCipherSpec

Jak długo istniał bład: 15 lat i 6 miesięcy

Data powstania: grudzień 1998

Data usunięcia: czerwiec 2014

OpenSSL powstał w 1998 r. jako open-source’owa implementacja protokołów SSL oraz TSL. Od tego czasu zyskał ogromną popularność i w wielu zastosowaniach stał się de facto standardem. Jest znakomity… ale nie jest wolny od błędów, również tych „długodystansowych”.

W 2014 r. głośno zrobiło się o krytycznej luce nazwanej Heartbleed – jej wykrycie sprawiło, że OpenSSL zaczęło przyglądać się krytycznie więcej osób. Jedną z nich był japoński specjalista ds. bezpieczeństwa, Masachi Kikuchi, który znalazł lukę związaną z przetwarzaniem ChangeCipherSpec. Analizy wykazały, że ów błąd mógł zostać wykorzystany m.in. do przeprowadzenia ataku typu man-in-the-middle i że istniał on w kodzie od początku prac nad OpenSSL. Ostatecznie go załatano – po 15 i pół roku od premiery.

Luka Microsoft Automation

Jak długo istniał błąd: 19 lat i 3 miesiące

Data powstania: sierpień 1995

Data usunięcia: listopad 2014

W Windows 95 – który zadebiutował równo 20 lat temu – Microsoft wprowadził rozwiązanie, które miało za zadanie ułatwić aplikacjom komunikowanie się miedzy sobą i wymianę danych – za pośrednictwem frameworków Object Linking and Embedding (OLE) oraz Component Object Model (COM).

Jedną z usług zbudowanych w oparciu o COM była OLE Automation (dziś nazywana po prostu Automation)… i to właśnie w niej w maju 2014 specjaliści z IBM X-Force znaleźli krytyczną lukę bezpieczeństwa. IBM bez specjalnego rozgłosu przekazał informację o problemie do Microsoftu, a ten szybko załatał lukę (i dopiero wtedy poinformował o wszystkim użytkowników). Nastąpiło to 231 tygodni po tym, jak ów błąd powstał.

Fot. Justin Henry CC BY 2.0

Excela problem z rokiem 1900

Jak długo istniał błąd: 27 lat (i wciąż nie jest załatany)

Data powstania: 1987

Data usunięcia: wciąż czekamy

Gdy Microsoft tworzył w połowie lat 80. pierwszą wersję Excela dla Windows, koncern miał do pokonania lidera rynku – program Lotus 1-2-3 IBM-a. Aby sobie to ułatwić, Microsoft postarał się by portowanie arkuszy stworzonych w programie IBM-a do Excela było możliwie najłatwiejsze. Koncern tak bardzo się zapatrzył w kod konkurenta, że z rozpędu skopiował nie tylko niektóre rozwiązania, ale również błędy.

Chodzi tu przede wszystkim o potraktowanie w aplikacji roku 1900 jako przestępnego. Programiści Lotusa zrobili to celowo, by ułatwić obliczenie – jednak by potem móc skorygować fakt wprowadzenia nieistniejącego dnia przestępnego, ustalili początek „ery” aplikacji (epoch) jako 0 dzień stycznia 1900 r. Wtedy nie wydawało się to kłopotem, ponieważ nikt nie uwzględniał takiego okresu w obliczeniach – z czasem jednak okazało się, że ów błąd powoduje problemy z prezentowaniem niektórych dat występujących bezpośrednio po początku ery. Jak już wspomnieliśmy, ów błąd skopiował również Microsoft – od 1987 r. istnieje on w MS Excel. Koncern o tym wie – jednak nie szykuje poprawki, ponieważ istnieje ryzyko, że naprawienie tego błędu mogłoby wygenerować szereg kolejnych.

fot. OliBac CC BY 2.0

Błąd przepełnienia bufora w YACC

Jak długo istniał błąd: 33 lata i dwa miesiące

Data powstania: maj 1975

Data usunięcia: lipiec 2008

Czas na rekordzistę – błąd, na którego załatanie trzeba było czekać ponad trzy dekady. W 1975 r. Stephen Johnson z AT&T Bell Labs stworzył narzędzie o nazwie Yet Another Compiler-Compiler (YACC – program służący do generowania analizatorów składniowych). Początkowo napisano go w języku programowania B, a później w C i pozostawał przed lata domyślnym tego typu narzędziem dla systemów uniksowych.

W 2008 r. Otto Moerbeek, jeden z developerów systemu OpenBSD (w którym również wykorzystywany jest YACC), próbował zidentyfikować przyczynę pewnego błędu, który pojawiał się podczas kompilowania programów C++ na Sparc64. Moerbeek przez dłuższy czas szukał problemu w swoim kodzie, jednak ostatecznie okazało się, że przyczyną komplikacji był błąd w oryginalny kodzie Stephena Johnsona (aczkolwiek przyznać należy, że ów błąd ujawniał się wyłączenie w pewnych specyficznych okolicznościach w systemach Sparc64 – i to dlatego przez tyle lat pozostawał niezauważony). Ostatecznie problem rozwiązał Otto Moerbeek – w 33 lata i dwa miesiąca po pojawieniu się błędu w kodzie.