20:00
19/2/2017

Praktycznie po każdych wyborach, z ust tych co przegrali można usłyszeń oskarżenia o fałszerstwo. A fałszować wybory można na wiele sposobów. Przekupując głosujących, źle licząc głosy lub bardziej technicznie — jak to w przypadku ostatnich wyborów prezydenckich w USA zademonstrowała Rosja — włamując się do komputerów komitetów wyborczych i wywierając wpływ na obywateli przez środki masowego przekazu. Ale hackerzy (niezależnie od tego czy działający na zlecenie Rosjan, czy nie), to nie jedyna siła mogąca zmienić wynik wyborów. Okazuje się, że zhackować wyniki może także …Słońce.

Neutron oddaje supergłos

Przenieśmy się do Belgii, do małej gminy Schaerbeek, dzielnicy Brukseli, liczącej zaledwie 130 000 mieszkańców. To właśnie tam, w 2003 roku w lokalnych wyborach jeden z kandydatów niespodziewanie pozyskał okrągłe 4096 (2^12) dodatkowych głosów. Nie umknęło to uwadze władz, bo lokalne wybory mają to do siebie, że głosujących zazwyczaj nie jest zbyt wielu…

Kiedy zaczęto bliżej przyglądać się sprawie nieautoryzowanej zmianie wyników, okazało się, że głosy na kandydata oddało coś nie z tej Ziemi… Jak w swojej piątkowej prezentacji podczas spotkania AAS poinformował profesor Bharata Bhuvy, powodem pojawienia się dodatkowych głosów było SEU (Single Event Upset) — zjawisko polegające na opadzie zjonizowanych cząstek, które trafiając w układy pamięci komputera mogą spowodować zmianę bitu, a zatem modyfikację wartości przechowywanej w pamięci komputera zmiennej.

Objaśnienie zjawiska "przeskoku bitu"

Objaśnienie zjawiska “przeskoku bitu”, slajd z prezentacji Christophera Frosta

Tu warto nadmienić, że Słońce mogło podczas tego “fałszerstwa wyborczego” działać w zmowie z promieniowaniem kosmicznym, ponieważ nasza gwiazda nie jest jedynym źródłem tego bombardowania cząstkami docierającego do Ziemi.

Wykrywanie “oszustw” tego typu nie jest łatwe. Niespodziewana zmiana bitu może nie zostawić żadnych śladów. W przypadku Schaerbeek problem zauważono z racji nieprawdopodobnie dużej liczby głosów. Profesor Buhva zwraca uwagę, że w stanie Tennessee, z którego pochodzi, w wyborach lokalnych po głosowaniu nie zostaje żaden ślad “papierowy”. Wszystko jest trzymane przez elektroniczny system, więc sprawdzenie, czy zdarzyła się taka niefortunna zmiany bitu, która komuś dopisała glosy, może być niemożliwe. Niewykluczone że i w innych wyborach “hackerska grupa” Słońce & C0sm1c r4yz T34m także wpłynęła na wyniki, ale z racji mniejszych “różnic” nikt tego nie spostrzegł ;-)

Nie tylko systemy wyborcze są “zagrożone”

Oczywiście systemy wyborcze to nie jedyne systemy komputerowe narażone na błędy spowodowane promieniowaniem kosmicznym. Inny z panelistów tego samego spotkania, Christofer Frost zwrócił uwagę, że takie bombardowania cząstkami wysokiej energii są przyczyną wielu problemów związanych ze stabilnością systemów w samolotach.

Cząstki wysokiej energii mogą przyczynić się do awarii systemów w samolotach, slajd z prezentacji Christophera Frosta

Cząstki wysokiej energii mogą przyczynić się do awarii systemów w samolotach, slajd z prezentacji Christophera Frosta

Abyśmy mieli lepsze wyobrażenie, jak często nasze urządzenia mogą być bombardowane takim promieniowaniem, zwizualizujmy ten problem podpierając się slajdem z prezentacji Frosta. Na monetę spada średnio 1 cząstka na minutę. Ale jeśli moneta znajduje się na wysokości 10 kilometrów, to jest już “bombardowana” 300 razy na minutę.

Częstotliwość bombardowania neutronami

Częstotliwość bombardowania neutronami, slajd z prezentacji Christophera Frosta

Będzie coraz gorzej…

Co gorsza, zjawisko będzie wedle naukowców coraz częściej odczuwalne. Nie ze względu na wzmożoną aktywność Słońca, a dlatego, że w ostatnich latach produkowane układy są coraz “gęściej upakowane”. Utrata danych to nie jedyny problem. Możliwe są także ataki phishingowe — przypomnijmy tu nasz artykuł sprzed 5 lat, dotyczący negatywnego wpływu bombardowania pamięci komputera cząstkami o wysokiej energii na… domeny internetowe.

Tzw. bitsquatting może spowodować, że kliknięcie na link prowadzący do domeny X, przeniesie was na domenę Y. Zobrazujmy to na przykładzie domeny CNN.com.

01100011 01101110 01101110 0101110 01100011 01101111 01101101
c n n . c o m

Po kliknięciu na link cnn.com, zapis binarny tej domeny jest kopiowany w pamięci kilka razy:

  • poprzez stos TCP/IP z kernel do user mode.
  • przez przeglądarkę w trakcie parsowania HTML
  • w trakcie tworzenia reprezentacji DOM
  • w trakcie tworzenia żądania HTTP
  • poprzez API w trakcie rozwiązywania DNS

Załóżmy więc, że następuje przypadkowa modyfikacja bitu w nazwie domeny (jak poniżej) i zamiast cnn.com, przeglądarka trafia na con.com.

01100011 01101111 01101110 0101110 01100011 01101111 01101101
c o n . c o m

Dlatego właśnie warto rozważyć, czy nie zacząć rozpoczynającego się tygodnia od wykupienia wszystkich “bitflappingowych” wersji swojej domeny ;) Albo zakupu specjalnych kości pamięci ECC, które zostały zaprojektowane tak, aby minimalizować skutki “przeskoczenia bitu”.

PS. W kontekście powyższego przypominamy też o ataku Rowhammer, który udowodnił, że “przeskok bitu” w układach pamięci można wywołać bez udziału promieniowania kosmicznego w sposób kontrolowany, w celu kradzieży danych do których nie ma się dostępu.

Przeczytaj także:


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

47 komentarzy

Dodaj komentarz
  1. Że też taki bit nie chce sobie przeskoczyć kiedy wypłata do mnie jest przelewana i wszędzie ustawić dziewiątki… ;)

    • Znając życie, prędzej by zmienił kierunek przelewu… ;->

    • dla mnie system obsługi wyborów jest zagadką, bo liczenie powinno się odbywać na serwerze. Tutaj pamięci typu ECC są normą, ale niestety nie wiemy (choć możemy się łatwo dowiedzieć), czy kontroli parzystości podlega sama transmisja RAM-CPU, a nawet same cache w CPU. Ciekawe też jak na neutrony reagują dyski SSD, zwłaszcza te na TLC, bo o tradycyjne HDD to się raczej nie obawiam.

  2. “[..] lokalne wybory mają to do siebie, że głosujących zazwyczaj nie jest zbyt wielu… [..]” – no coz, w Belgii akurat istnieje przymus wyborczy wiec to nie do konca tak, ze nie jest ich zbyt wielu :) (https://pl.wikipedia.org/wiki/Przymus_wyborczy)

  3. Nie wiem jak w Belgii ale w Polsce wszystkie zapisy są wielokrotnie sumowane. Liczba głosów oddanych na kandydatów jednej partii po zsumowaniu daje liczbę głosów oddanych na listę i tak dalej. Wszystkie te wielokrotne zapisy i weryfikacje są tak upierdliwe że nawet niektóry operatorzy nie radzili sobie ze stworzeniem fikcyjnych danych do testów. Więc taki przeskok bardzo szybko wywalił by na którymś etapie komunikat.

    • Po za tym zapisane są wyniki z każdego lokalu wyborczego (na każdego kandydata w każdym lokalu) i w każdej chwili można je na nowo zsumować. Więc przeskok bitu może zniszczyć najwyżej informację o ilości głosów na danego kandydata w danym lokalu – błąd oczywiście do wykrycia bo nie będzie się zgadzało z sumą ważnych głosów ale nie do naprawienia bez ponownego sprawdzenia u źródła.

  4. Nazwanie pamięci ECC specjalnymi, gdy te istnieją już w zasadzie od początków pamięci RAM, jest sporym nadużyciem. Po prostu są droższe i dlatego rzadziej używane, ale w żadnej mierze nie są “specjalne”.

    • Jak najbardziej są specjalne, nie dlatego że są droższe, ani dlatego że powstały później/wcześniej niż coś tam. Tylko dlatego że mają specjalne przeznaczenie. I czas wprowadzenia do użycia nie ma tu nic do rzeczy.

    • Gratulacje, właśnie sam sobie zaprzeczyłeś…

  5. Czy ktoś może wyjaśnić w jaki sposób można zatrzymać takie zjonizowane cząstki tzn czy wystarczy że będę trzymał kompa w nienasłonecznionym miejscu na biurku czy może nawet w piwnicy może mnie dopaść taki zły jon? A w samolotach to oni to jakoś zabezpieczają? A jeżeli już zabezpieczają to czy tylko urządzenia pokładowe czy może cały samolot tj. czy “bezpieczne” jest używanie laptopa bądź telefonu na wysokości 10 km nad ziemią?

    • Odpowiedniej grubości ściana z ołowiu z pewnością zatrzyma większość z takich cząstek, niemniej jednak pamiętaj, że fale elektromagnetyczne generowane przez sam komputer mogą spowodować przeskok bitu. Ba, nawet przelatujące neutrino może zareagować z bitem twojej pamięci, mimo bardzo znikomego prawdopodobieństwa.
      Prościej i taniej użyć pamięci ECC, niż próbować się zabezpieczyć przed nieuniknionym.

    • A neutrino możesz też próbować zatrzymać pancerzem ołowianym. Musi być dość gruby – tak około jednego roku świetlnego grubości.

    • Założyć mu czapeczkę z foli aluminiowej….

    • @Kir Ale komu chcesz zakładać czapeczkę, temu neutrinu?

    • Bardzo wątpliwe, żeby tą cząstką był neutron. A jeszcze bardziej, że neutrino.

      Dwa słowa na temat tych cząstek.

      Co do neutrina to nie ma się jak przed tym chronić, bo bardzo słabo oddziałuje z materią.

      Do zatrzymania neutronu natomiast ołów jest średnio przydatny. W tym przypadku sprawa nie jest taka prosta, ale w największym skrócie można powiedzieć, że najlepiej sprawdzają się woda, parafina i specjalnie domieszkowane betony (domieszkowane solami baru).

  6. Nawet bym nie wpadł na to, że można hostować infrastrukturę krytyczną dla działania państwa / samorządu na czymś bez ECC…

  7. Mam 32 GB RAM (jak kupowałem 4 lata temu, to się łapali koledzy za głowę :D). Zrobię 2X12GB ramdysk i założę plik wypełniony zerami – a potem sprawdzę jak szybko zacznie się psuć :)

    • OK. 2 pliki, każdy po 12 GB, wypełnione zerami. Po 1,5h brak błędów. Test trwa :)

    • Poczekaj na słoneczny dzień :D.

    • @max
      “We’ll meet again
      Don’t know where
      Don’t know when
      But I know we’ll meet again
      Some sunny day”

    • 12 godzin, 0 błędów – oba pliki na ramdyskach jak wypełnione były zerami, tak dalej są. Może położyć banany na pamięciach RAM? :)

    • A według spaceweather.com jesteśmy właśnie w trakcie przelotu przez strefę silnego wiatru słonecznego :)

    • Statystycznie trzeba 3 miesięcy na to, aby powstał błąd w 256MB ramu.
      (niestety źródła nie podam, nie pamiętam). Więc na powstanie błędu w 12 GB musiałbyś czekać niecałe 2 dni.
      Ale to tylko statystyka i jest zapewne wiele czynników wpływających na to.

    • 1 dzień, oba pliki dalej takie same.
      Gwoli ścisłości – 24 GB. 2 X 12 GB pliki wypełnione zerami. Według https://niebezpiecznik.pl/post/bitsquatting-czyli-promieniowanie-kosmiczne-i-bledy-w-nazwach-domen/ – można spodziewać się jednego błędu dziennie na każde 4GB, więc statystycznie powinienem mieć już 6… :)

    • Mija 31 godzin, dwa dni i jedna noc. Błędów brak.

    • Trzeba było paternem 01 a nie samymi zerami. Prawdopodobnie zmiana zera wśród zer wymaga większej energii.

    • Planowałem postawić później FF, ale może faktycznie lepszy AA. Swoją drogą, jeśli gość dostał 4096 głosów to musiało mu też z 0 na 1 przeskoczyć…
      Różnic dalej brak :) Wieczorem sprawdzę w wersji AA.

    • Od wieczora 2 pliki po 12 GB wypełnione $AA (170). Zmian brak…

    • Różnic dalej brak. Rano polecą dwa pliki z losową zawartością na 3-4 dni.

    • Dzień 1, różnic brak.

    • Dzień 2, różnic brak.

    • Dzień 3, różnic brak. Może mnie neutrony nie lubią :)

    • 4 dzień, dalej bez zmian – dwa 12 gigowe pliki w ramdysku dalej takie same.

  8. Chwila, chwila, czy ja dobrze widzę? Maszyny do głosowania nie używają pamięci typu ECC?

    • Też się zdziwiłem, przecież to standard w zastosowaniach serwerowych.

  9. Jak pelikany…

  10. Przypomina mi się lemowskie “O maszynie cyfrowej, co ze smokiem walczyła”

  11. Pamięć ECC jest odpowiedzią na wszystkie pytania

  12. Na informatyce w liceum pisaliśmy program, który rysował semigraficzną szachownicę w wierszu polecenia (zamiast białych i czarnych pól były na przemian dwa różne znaki). Po pierwszym uruchomieniu jeden ze znaków był błędny, ale podczas następnych prób wszystko było prawidłowo, pomimo że nie zmodyfikowaliśmy programu. Jak myślicie, czy to mogło być spowodowane przez tego typu cząstkę, czy raczej jakiś błąd np. Windowsa (nasz program był bardzo prosty i nie korzystał z żadnych zewnętrznych zmiennych), który rzadko objawia się w podobny sposób?

    • Raczej to pierwsze, aczkolwiek jeśli program był w Javie, to obstawiałbym Javę ;)

    • A wartość początkową dla każdej zmiennej ustawiliście, czy korzystaliście z RAM-PRNG;)?

    • Przypomnij sobie jaki powinien być znak i na jaki się zmienił i zanalizujmy czy kody ascii różnią się tylko jednym bitem.

    • Niestety już nie pamiętam, jakie znaki się wyświetliły, bo to było kilka lat temu. Też się zastanawiałem nad niezainicjowanymi zmiennymi, ale to niemożliwe – które to miałyby być zmienne? Liczniki wierszy i kolumn? Wtedy tabela miałaby nieprawidłowe wymiary. Zmienna typu bool używana do przełączania znaków? Wtedy byłoby “przesunięcie fazy”. W dodatku błędny znak był w drugiej lub trzeciej linijce. Program był napisany w C++ i skompilowany w Dev-C++.

  13. Słońce ośmiesza grupę Anonymous :P

  14. Żeby mi takie zjawisko zjonizowanych cząstek trafiło na konto bankowe :D

  15. Wynik eksperymentu.
    7 dni trzymałem w ramdysku 2 12-gigowe pliki z losową zawartością. Mimo dość silnej aktywności Słońca w owym czasie (wg spaceweather.com) zmian w żadnym z nich nie stwierdzono…

  16. Przecież ten bit może przeskoczyć w czymkolwiek, nie koniecznie w pamięci RAM chronionej przy pomocy ECC. Mało jest pamięci chociażby w samych procesorach?

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: