W dniu 08.12.2023 o 12:43, Grzegorz Niemirowski pisze:
Czyli, że jednak się da :-) O to mi zasadniczo chodziło bo tak też tłumaczy Newag. A czy prawdę mówi to ja nie wiem, tylko że faktycznie w wielu przypadkach da się po prostu wgrać gdy ma się fizyczny dostęp.
W dniu 8.12.2023 o 15:13, io pisze:
To że zgłosił nic nie znaczy, wg mnie pali głupa, doskonale wiedział że jest blokada, świadczy o tym chociażby sekwencja od blokująca z kabiny, jak się wydało że hakerzy ją wyczaili i uruchomili składy to producent zdalnie ją zablokował? Przypadek? Nie, celowe działanie, cba i inne służby nic z tym nie zrobią bo ingerencja jest w system sterowania a nie bezpieczeństwa, a to ich guzik obchodzi. Teraz KD i inne poszkodowane powinny Newag-owi majtki przez głowę ściągnąć w sądzie.
Mam nadzieję, że te "wiele przypadków" nie dotyczy infrastruktury kolejowej.
Ale wymaga się standardów a nie "współczesnych metod kontroli jakości" więc po co się rozpędzać. Być może ich nawet nie spełniali, ale też kiedy te pociągi były robione, jak odbiorca nie chciał zgodnie ze standardem to nie dostał.
Mógł weryfikować, ale już zabezpieczenia przed lewym kodem nie zrobił. Nie bez powodu jest to osobne kryterium weryfikacji zdaje się nawet wymagane dopiero w wyższych SIL'ach.
Przestań, firmy jednak są dalej. Nie wiem jak dokładnie Newag, ale nie mam powodu podejrzewać, że nie.
To nie jest tłumaczenie. Firmy mają działy bezpieczeństwa gdzie naprawdę można zatrudniać ludzi którzy się na tym znają i podczas walidacji produktu wymagają.
Na razie nie wiadomo czy to aby na pewno Newag wrzucił. Sam przecież w to nie bardzo wierzysz. Ja bym uwierzył nie tyle w to, że to zrobił, ale że to mogłoby mieć sens w produktach powszechnego użytku. Gwarantuje 2 lata to czemu właściwie miałby działać dłużej.
A to był ten gościu-hacker, co znalazł te podejrzane miejsca?
IMO - w kodzie binarnym mozna conieco podmienic. Moze być problem z miejscem, moze trzeba sie będzie bardzo postarać, żeby to sensownie wyglądało, ale wykluczyc zmiany nie można. Oryginalny programista moze by wychwycił celowość tych zmian, ale przed sądem ... bo to wiadomo, który kłamie?
No chyba, że kod jakąś sumą kontrolną objęty (co ma sens, ale bardzo ambitna musiałaby być), albo sa pliki z oryginalnym kodem czy aktualizacjami, podpisane cyfrowo.
Podpis cyfrowy tez nie daje 100% pewnosci ...
J.
W dniu 08.12.2023 o 12:43, Grzegorz Niemirowski pisze:
W ten sposób nie zweryfikujesz spójności całego systemu, będziesz mógł dograć moduł, który jest wewnętrznie spójny a jednak nie pasuje do całego systemu.
Czyli, że jednak się da :-) O to mi zasadniczo chodziło bo tak też tłumaczy Newag. A czy prawdę mówi to ja nie wiem, tylko że faktycznie w wielu przypadkach da się po prostu wgrać gdy ma się fizyczny dostęp.
Tak se właśnie ludzie myślą, że zamknięte pomieszczenie, zamknięta sieć a to bardziej założenia niż realia. Więc ostatnio jest trend by do tego implementować normy cybersecurity.
Zapewne. Ale też ludzie zajmują się wszystkimi zagadnieniami: piszą projekty modułów, same moduły, instrukcje, testy, weryfikują. Nie mogą z wszystkiego być dobrzy.
No właśnie nie, on tylko rozważa nie widząc tego kodu. A to co jest w mediach to przecież nie są dokładnie te wstawki jakie zostały znalezione tylko ich demonstracja.
Nie jest pewne, że to w ogóle nadaje się na sąd skoro padło coś o złamaniu bezpieczeństwa.
Sumy kontrolne są liczone standardowo, jak wiesz jak to je policzysz i podmienisz.
No właśnie, i tutaj już da się stwierdzić, że nie jest oryginalne. Ale jeszcze system musi taki kod odrzucić. Nie jest oczywiste, że to robi. I co, że ktoś sobie podmienił jeden moduł.
Kto wie, kto wie :-)
To jedno i to samo.
Róznica głównie w tym, że standardy mają dużo dodatkowych detali, które tylko zaciemniają koncept przejrzystości kodu, ale czerpią całymi garściami z tych współczesnych metod.
Pojmijając kwestie prawne, jestem najzwyczajniej ciekaw, jako programista właśnie, jak to wygląda od kuchni. Opowieści ludzi, którzy przeżyli gułagi typu embedded, są straszne.
Trodno to nazwać zabezpieczeniami. To normalne praktyki w normalnej firmie programistycznej, ktore *przypadkowo* są również zabezpieczeniem przed "wstrzykiwaniem" podejrzanwgo kodu. To darmowe ciastko.
No, ale jeśli to jednak był:
1) spisek kierownika 2) atak hackerówTo dokładnie tak to wygląda. Nie kontrolują co kompilują i instalują w pociągach.
A jeśli zrobiono to "gdzieś po drodze", to nie kontroluja jaki kod jest wykonywany na maszynie.
Każda ewentualnośc świadczy o daleko idącym dziadostwie.
Ale szacuję, że to najbardziej prawdopodobne. W sensie: że nie kontrolowali kodu i jakaś grupa miała pojęcie.
Różnica tutaj jest taka, że skoro to mogło zatrzymać pociąg, to czy aby na pewno nie potrafiło go uruchomić, albo wyłączyć hamulce, albo zablokować panel kontrolny albo...
Skala problemu inna, niż podobna funkcjonalnośc w pralce.
W dniu 2023-12-08 o 18:11, heby pisze:
Żyję w świecie embedded (choć sam nie napisałem ani jednej linijki kodu dla procesora) i nie rozumiem o czym piszesz, a chciałbym choć pobieżnie (na poziomie 'dla idiotów') rozumieć.
Gdzie się mylę? Procesor ma jakieś złącze do wgrywania kodu (nie chodzi o wykonanie upgrade, tylko wgrywanie 'od zera'). Jeśli ktoś, jakoś wejdzie w posiadanie całego kodu dla danego urządzenia (w tym przypadku pociągu) to może to oprogramowanie dowolnie zmodyfikować i jeśli miałby dostęp do sprzętu to nie widzę metody, która uniemożliwiła by mu wymianę kodu oryginalnego na ten przerobiony. Skoro hakerzy potrafią się włamać do najpilniej strzeżonych serwerów to zapewne i do komputera autora tego oprogramowania mogli by się włamać. Pociągi stoją niby na terenie strzeżonym, ale może 'dla chcącego nic trudnego'.
Jak niby miała by wyglądać kontrola oprogramowania, które ktoś, bez naszej kontroli nad tym przerobił.
Znów - jak miałaby wyglądać taka kontrola? Przecież jak to już jest inny program to on kontroluje wszystko.
Program może sam siebie jakoś kontrolować. Ale jego przerobiona kopia będzie miała już swoje własne kontrolowanie samej siebie... P.G.
Dlaczego to złacze do wgrywania kodu akceptuje dowolny kod? Dlaczego w ogóle akcpetuje kod?
Dlaczego, z przyczyn bezpieczeństwa, nie wybrano procesora sprawdzajacego podczas bootowania podpis firmware/flash przed uruchomieniem kodu? Takie procesory są w powszechnym użyciu.
Jakiś OTP rom, który po wypaleniu (w procku) uniemożliwi wykonanie niepodpisanego kodu w dalszej częsci flasha. Możesz programować flash na zdrowie, ale jesli nie podpiszesz, to nie wystartuje.
Przykładem takiego rozwiązania jest konsola Wii, która uniemożliwia uruchomienie firmware bez podpisu. Jest jednorazowo, w fabryce, programowana wsadem sprawdzającym podpisy i dalej jest już chain-of-trust.
Zabawne: do dzisiaj nie złamano w pełni tego zabezpieczenia, mimo starań dziesiątek ludzi. A to zabawka. Znaleziono tylko exploity.
Wtedy jest niepodpisane. Prawidłowo zaprogramowany kontroler z funkcją chain-of-trust *NIE* uruchomi kodu we flash jesli nie zgadza się podpis.
Oczywiście, procesor musi mieć taką możliwość. Ale przecież w tych pociągach nie wstawia się AVRa, prawda?
OTP boot rom z kodem kryptograficznym weryfikującym firmware.
To jest niebezpieczne. Sam odczyt firmware może prowadzić do procesu audytu, który szuka exploitów, to znaczące ułatwienie.
Ale brak weryfikacji flasha za pomocą kryptografii jest niedopuszczalny w krytycznych rozwiązaniach dla bezpieczeństwa.
Świadomość takich rozwiązań jest bliska zeru, w środowisku programatorów embedded.
chain-of-trust.
Nawet PC to implementują od wielu lat. To tylko strach przed aferą na razie daje nam namiastkę swobody. Przyjdą czasy, że nic poza windowsem nie uruchomisz, tylko MS będzie mógł podpisać swój bootloader. Z reszta już przyszło: niektóe komputerki Yoga nie odpalają linuxa. Nie jest podpisany.
Więc właśnie tak by to musiało być realizowane a hackerzy twierdzą że pobrali kod, zmodyfikowali i wgrali bez większego trudu, pociąg "naprawiony", więc zapomnij.
Wiec dziadostwo.
Ktoś musiałby pilnować kluczy i chronić je przed sprzątaczką :-)
No i dzięki tej podatności niektórzy uświadomili sobie, że oprócz dobrych rzeczy kod może zawierać również złe, może nawet sprzątaczki :-)
Tak, nie ma nic dziwnego w trzyma niu ich w "sejfie" w postaci bezpiecznego pomieszczenia z autoryzowanym dostępem.
Jak trzymasz zdobycze ostatnich 40 lat informatyki w postaci praktyk flow kodu w firmie, to większośc z tych problemów najzwyczajniej nie istnieje.
W tym problem: wiele firm dalej mentalnie siedzi w latach 80 i dalej kompiluje krytyczny soft z \\dupa\build.
Wręcz przeciwnie, te standardy są stare, już dawno miały takie wymagania.
...
Nie dało się go odpalić jak za długo stał w serwisie i tyle.
Oficjalne funkcjonalności tym bardziej rodzą takie wątpliwości.
Masz bekluczyk w samochodzie?
to samo co do softu w pociagach - brak publicznie dostepnych zrodel
no chyba ze liczymy na to samo co i w ich przypadku, czyli wynajmujemy sztab hakerow analizujacych binarki
lepszym rozwiazaniem bylby wybor jakiejs komercyjnej dystrybucji Linuxa i placenie stricte za utrzymanie i pomoc techniczna - chocby z tego wzgledu, ze nie trzeba uzalezniac sie od monopolu Microsoftu
niestety takie zmiany wchodza w naszym kraju odgornie z inicjatywy UE (chocby uznanie otwartego ODT za obowiazujacy standard w urzedach), a nie naszych krotkowzrocznych wladz
Dbały odbiór pozwoliłby na późniejsze wykrycie tego typu wstawek przez średnio rozgarnięty zespół programistów, a nie specjalistów zajmujących się stricte inżynierią wsteczną (których jest na rynku wielokrotnie mniej)
Poza tym dbały odbiór pozwoliłby na bezproblemowy serwis pociągu z jakiegokolwiek powodu
no bez jaj, nie widze nic zlego w braku chain-of-trust, to tylko dodatkowa funkcjonalnosc za ktora de facto nikt nie chce placic, poza tym zadne mechanizmy weryfikacji autorstwa kodu nic tu nie rozwiazuja - firma nadal moglaby sie tlumaczyc ze wyciekl jej klucz prywatny (niczym to sie rozni od gadania ze wyciekl kod zrodlowy)
postawmy sprawe jasno - pociagi sa Newaga, wgrany soft tez (co da sie udowodnic z wystarczajaca pewnoscia:
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.