rzędzi

Tak, tylko ile by kosztował ?

Ale w NASA sie programy sprawdza, w Boeingu ostatnio też.

J.

Ogólnie w poważnej fimie nie da się wprowadzić lewego kodu do repozyorium bez całej masy zabezpieczeń, wliczajc w to białkowy code rewiev. A to oznacza, że kilka osób patrzy na ten kod przymusowo, a cała reszta ma zapewna jakiś poziom wglądu w niego, nawet przypadkiem. Nie był on specjalnie ukryty, skoro dekompilacja asm go ujawniła, to musiał być czytelny i w kodzie źródłowym. Idąc dalej: to oznacza, że kilka osób w firmie musiało by być uwikłane w tą "konspirację" a więc to żadna konspiracja, nastepnego dnai przy kawie wiedziałby cały dział.

Oczywiście może być firma bez śladu kontroli jakości kodu. To nawet bardzo prawdopodobne, firmy piszące w embedded czerpią garściami z lat 80.

Czyli ja widze dwie odpowiedzi:

1) jest to takie dzadostwo, że repozytorium kodu nie ma żanych współczesnych metod kontroli jakości 2) wszyscy z dostępem do repo wiedzieli o tej konspiracji

Oba dyskwalifikują firme z poważnych zagadnień.

Jest jeszcze trzecia: wiedział o tym tylko ktoś (+managment), kto dynamicznie dodawał kod podczas budowania obrazu systemu. Zakładam jednak, że to już spisek z grubej rury ocierajacy się o prokuraturę. Nie byli by aż tak głupi, prawda? Prawda?

Tylko ze "poważna firma" to byłby pewnie Newag.

Bo jakby jakies "koleje regionalne" mialy robic review firmware pociągu ...

J.

Chodzi o to, że ten zewnętrzny review w tym wypadku jest zbędny, bo tajemnicy wewnątrz firmy nie da się zachować. Ktoś to zauważy i zapyta w samym Newagu, a może i doniesie do prokuratory, bo w końcu to jest na granicy bezpieczeństwa, ingeruje wprost w krytyczne funkcje napędu. Ja by mieli prawiłowy cykl oczywiście.

Review czy autyt zewnątrzny czasem miałby sens, gdyby szukali bugów. Ale spisek tego typu byłby widoczny jak na dłoni, w dowolnej fimie z prawidłowym cyklem tworzenia oprogramowania, tego nei da się łatwo ukryć. Ja nie widzę opcji utrzymania tego w tajemnicy, chyba że jednak dziadostwo jakościowe na to pozwoliło. Bo "wszyscy w spisku" brzmi słabo.

W dniu 7.12.2023 o 21:17, heby pisze:

3) Ktoś kto bardzo chciał zaszkodzić producentowi, włamał się do różnych jego produktów u różnych przewoźników i wgrał oprogramowanie z obciążającą go modyfikacją.

W dniu 7.12.2023 o 22:12, heby pisze:

Tak się wydaje ale dieselgate udawało się jakiś czas utrzymać w tajemnicy. Volkswagen nie miał prawidłowego cyklu?

SW3 snipped-for-privacy@poczta.fm.invalid> napisał(a):

Odpada z wielu względów. Po pierwsze wymagałoby to zaangażowania pokaźnych środków, zarówno finansowych jak i ludzkich. Ponadto byłoby bardzo ryzykowne, taka seria włamań byłaby bardzo podejrzana. Wreszcie modyfikacje oprogramowania pozostawiają ślady i to już zostało wykluczone:

Bardzo możliwe.

To wymagało by zmian na poziomie kodu maszynowego. Były by widoczne. I była by to kompromitancja Newagu, że nie podpisują firmware. Bo za chwile ktoś odpali Dooma na tym pociągu.

Z reszta w artykule mowa też o backdoorze, wiec taki backdoor ciezko by było jakoś "wpleść" w istniający firmware. Raczej został napisany wspólnie z resztą kodu.

W dniu 08.12.2023 o 10:36, Grzegorz Niemirowski pisze:

Gościu w ogóle widział ten kod binarny, że się na jego temat wypowiada? Jeśli np kod czerpał dane z innych zasobów niż z siebie to całe jego rozważanie nie ma sensu bo po prostu można źródło podmienić.

io snipped-for-privacy@op.pl.invalid> napisał(a):

Nie musiał.

Pociąg pobierał sobie aktualizacje z jakiegoś repo i ktoś to repo przejął lub zmienił konfigurację pociągu przestawiając na inne repo?

Podpisywanie zapewnia spójność samego oprogramowania, ale Dooma da się wgrać :-)

Z wypowiedzi Newagu można odnieść wrażenie, że nie było podpisywane co oczywiście jest słabe ale wydaje się możliwe. Wcale nie chodzi o "współczesne metody kontroli jakości" tylko o standardy CENELEC, które obecnie muszą spełniać. Zajmowałem się weryfikacją oprogramowania kolejowego w nieco innym obszarze w innej firmie i to wszystko mało poważne było, kierownik bardziej był zainteresowany szybkim wykonywaniem weryfikacji niż jej jakością. Jak dostałem system do weryfikacji, która już wielokrotnie była wykonywana to na wstępie okazało się, że nie wiadomo z jakich modułów składa się system. Po prostu osoby, które wcześniej ją robiły, nie pofatygowały się by określić co dokładnie jest przedmiotem weryfikacji a co nie jest np dlatego, że nie musi. Czyli robiły ją "po łebkach".

io snipped-for-privacy@op.pl.invalid> napisał(a):

Od spójności jest suma kontrolna. Podpis jest od weryfikowania pochodzenia oprogramowania i do odrzucania oprogramowania obcego. I jeśli jest weryfikowany, to Dooma nie da się wgrać. Chyba że uda się nadpisać sam bootloader i usunąć weryfikację.

One dokładnie wyjasniają w prosty sposób ja bardzo *niemożliwe* jest aby lewy kod dostał się do repozytorium. Nie potrzebujesz nic innego, jak tylko prawidłowe metody pracy z kodem, aby wykluczyć takie numery na poziomie świadomej manipulacji, wstrzyknięcia kodu przez hackerów itd.

Czyli znowu: ktoś był na tyle głupi, co w świecie embedeed jest normą, że nie wprowadził dobrych metod pisania kodu z całą otoczką code review, coverage, statycznej analizy, podpisywania plików źródłowych i wynikowych i masy innych utrzymujących jakośc i przy okazji eliminujących możliwośc włożenia lewego kodu.

Najzwyczajniej, jak to bywa w dziadofirmach, "repozytorium" to wspólny katalog na \\dupa\build z kodem zmienianym w czasie rzeczywistym, który kierownik raz dziennie w pocie czoła kompiluje zmawiając jednoczesnie modlitwę.

Czy tu było tak? Nie wiem, ale pewne poszlaki wskazują na to, w szczególności fakt, że lewy kod powinien być widoczny dla pracowników firmy, bo takiej tajemnicy nie da się ukryć w poprawnym flow programowania. Więc albo wszyscy wiedzieli, albo flow był do dupy. Stawiam na drugie, to firma embedded i to niejako obowiązek każdej firmy embedded mieć coś dramatycznie spieprzone we flow.

To też z drugiej strony tylko teoria. W praktyce prawie każdy system z podpisywaniem obcego kodu dało się wysypać robiąc nieoczekiwane dla niego rzeczy, głównie przez wyszukanie exploitów.

Zgaduję jednak, że system embedded do sterowania pociągiem nie powinien mieć potrzeby ładowana zewnętrznego kodu. Nigdy.

Nawet update firmware powinno odbywać się w serwisie.

czwartek, 7 grudnia 2023 o 21:18:16 UTC+1 heby napisał(a):

Sprawdzić czy nie został lekko podrasowany kompilator :)

To chyba nie był jakiś ze stronki kompilatorki.buziaczek.pl tylko co najmniej kompilowany z podpisanych źródeł, a idealnie, cerytfikowany. Ogólnie poziom dziadostwa może być dowolny, ale to byłby raczej wtedy ukierunkowany atak i raczej miał by na celu sabotaż dostaw wojennych niż konkurencje napraw.

Bo po co jakies ambitne podpisywanie, skoro nowy program wgrywa autoryzowany serwis?

Zgodnie z zamówieniem kierownika :-)

J.

W dniu 08.12.2023 o 12:22, Grzegorz Niemirowski pisze:

Przeczytaj artykuł z analizą gościa. Twierdzi, że można stwierdzić czy kod wykonywalny powstał ze źródłowego czy ktoś wykonywalny poprawił, sugerując że musiał być ze źródłowego, czyli że Newag go napisał. A wystarczy, że ten kod jednak trochę inny jest niż pokazuje, że np. korzysta z tablicy dostarczonej z zewnątrz i już tablicę można podmienić wcale nie modyfikując kodu a sens może być zupełnie inny. Bo pomyśl, Newag to zgłosił różnym służbom, które na pewno pracowników rozpytały, sprawdziły to repo i niczego nie znalazły. No chyba, że same były w to umoczone czego nie da się wykluczyć. Oprócz pracy na repo można sobie wyobrazić, że ktoś po prostu kod wyniósł na zamówienie.