rzędzi

Możliwość modyfikacji softu przez kogoś złego.

Z zalet: brak chain-of-trust może być znakomitym dupochronem, bo można zawsze powiedzieć, że te dodatki do softu, to się same zrobiły "gdzieś po drodze".

Problemem jest zmuszenie prawne do implementacji tego. Prawo tworzą przygłupy prawnicze i oni nie ogarną, nawet jak by im ktoś miesiąc tłumaczył, że infrastruktura krytyczna powinna mieć jakiś poziom zabezpieczeń inny, niż kłódkę i 5 lat w zawieszeniu.

Jest różnica: jak wycieknie kod źródłowy, to co najwyżej musisz martwić się o exploity (w systemie offline to nie jest aż tak ważne) ewentualnie spalasz się ze wstydu jak inni zobaczą co odp... Kaziuk z Januszem w tym C.

Wyciek klucza prywatnego jest niebezpieczny, bo po cichu można dokonać modyfikacji i doprowadzić do sabotażu.

Problem już nie dotyczy tego przypadku. Ten przypadek to jest żałosne kombinowanie będące skokiem na kasę.

Ja się obawiam, że nastepny firmware do tych pociągów może napisać Dima z Saszą, zamiast Kaziuk z Januszem. I nikt się nie dowie.

Po to powinny być podpisy.

Nie. Po prostu zesrają się na widok policji w firmie.

To tylko nerdy. Mogą trzymać mordę na kłódkę, ale siedzienie na dołku i bycie przesłuchiwanym już nie jest takie fajne jak na filmach.

Innymi słowy: utrzymanie tego w tajemnicy jest niemożliwe, jak już się mleko rozleje.

Ponoć rozlało się w maju, tako mówi ktoś ważny z ministerstwa, jak dzisiaj wyciekło.

Nie wiem czy mowa dalej o pociągach, ale jesli tak:

Po co komu Linux w pociągu, w komputerze sterujacym jazdą?

Ja rozumiem, do sterowania tablicami informacyjnymi, routerami wifi, czy wodą w kiblu.

Ale jazdą? Tam powinien być najmniej skomplikowany jak się da, wręcz na poziomie sterownika, maluteńki komputerek. Z kodem dającym się ogarnąc formalną weryfikacją, z coverage 100%, z lintem na 0 problemów.

Taa... jasne.

To, co widzimy na ekranie, to UI systemu a nie komputer sterujący jazdą.

Mamy wiec co najmniej dwa komputery:

1) sterujacy jazdą 2) panel kontrolny

Ponawiam i multiplikuję pytania:

1) po co w komputerze starujacym jazdą jest Linux?

2) po co w komputerze, wyswietlajacym kilka kółek i prostokątów, jest linux?

To że on tam jest, to czywiste. Ja pytam: po co.

No właśnie nie ma. Przynajmniej w tym newagowskim piszą coś o architekturze TriCore. Ale co to znaczy, że on steruje jazdą? To jest raczej odpowiednik ECU w samochodzie.

W dniu 2023-12-08 o 19:58, heby pisze:

I już wiem czego nie wiem :) Jesteśmy na poziomie AtXmega i powoli zaczynamy używać 32 bitowe Silabsy. Najnowsze mają coś, czego nie ogarnęliśmy, a może być tym o czym piszesz.

Napisz 1,2 zdania wyjaśniające pojęcie exploit.

Można też sobie wyobrazić kłopoty z wystarczająco bezpiecznym przechowaniem klucza do podpisywania i ewentualną możliwość, że ktoś niepowołany wszedł w posiadanie.

I znów to słowo :)

...

Nie wiedząc o istnieniu procesorów, o których piszesz, że są w powszechnym użyciu wyobrażałem to sobie tak jak my to mamy od 20 lat - bootloader weryfikuje podpis wsadu, ale wydawało mi się, że każdy procek ma przez złącze debug dostęp do 'kasujemy wszystko do stanu fabrycznego'.

Jest tyle innych rzeczy zawsze do zrobienia 'na wczoraj'... P.G.

W dniu 2023-12-08 o 23:17, heby pisze:

Skojarzenie. Zamiast wymagać co najmniej pinu do karty to teraz użycie obcej karty do kupienia czegoś za 10zł nazywa się "przełamaniem zabezpieczeń" i jest kradzieżą z włamaniem. P.G.

vamastach postuluje aby był. Pytam po co komu linux w sterowniku napędu.

Czyli steruja jazdą. Falowniki, hamulce, oddawanie energi (jesli jest) itd.

To powinno być pancerne, prymitywne, małe, wytestowane w 250%. Aby dało się ograniczyć ilość bugów, które są krytyczne dla bezpieczeństwa.

Na czymkolwiek do zastosowań embedded i nakierowanym na rysowanie prostokątów i kółek?

QNX na początek. Potem eCos, czy inny FreeRTOS. Na tym jakakolwiek bibliteka GUIowa, nawet jakaś prymitywna jak PW lib, czy bardziej wypasiona Java z Swing w wersji embedded. Qt starało się również wejśc na rynek embedded ale już tego nie śledzę. Gdzieś był prosty projek skompilowania wxWidgets na bodaj FreeRTOS, który ktoś zrobił dla zabawy na jakimś mikrokontrolerze.

Taki system startuje w milisekundy, mieści się we flashu w CPU i szanse na uszkodzenie są bliskie zeru.

Linux jest zbędny. Tam nie ma zastosowań dla cech, jakie ma linux. To tylko rysuje prostokąty i kółka i niech robi tylko to. Tak jest bezpieczniej.

Wyobraź sobie, że masz system z implementacją chain-of-trust. Nie da się uruchomić obcego kodu, wszystko musi być podpisane.

Ale twój system obsługuje USB.

Teraz, złośliwy hacker wie, że masz w tym buga. Na przykłąd nie oczekuje identyfikatora urządzenia mającego tysiąc znaków. Po prostu programista nie pomyślał. Typowy problem programatora w C:

char[200]; //should be enough.

W wyniku włożenia spreparowanego urządzenia udajacego pendrive, z tysiącznakową nazwą, podpisany kod przypadkowo uszkadza sobie stos i nadpisuje adres powrotu bajtami, które są nazwą urządzenia+kodem do wykonania.

Tada, nagle odpalasz obcy kod, wykrzystując błąd w kodzie podpisanym.

To exploit.

Prawie każdy kod podpisany miał jakieś explity, dotyczy to głównie konsol, jeśli chodzi o przykłady, bo tam najwięcej ich znaleziono. No i są czymś w rodzaju punktu honoru dla crackerów.

Na przykład w konsoli Wii, niektóre gry robiły zapisy na kartę SD. Można było te zapisy lekko zmodyfikować tak, że gra, poczas odczytu, wykonywała kod który chciał hacker (bo programatorzy w C nie potrafią pisać bezpiecznych parserów itd). Kod był wykonywany w konteście "zaufanego". Zabezpieczenie znika, możesz wykonać swój kod. Nie złamałeś konsoli (dalej jest to trudne do normalnego używania), ale chain-of-trust został złamany na jakimś etapie co daje rózne możliwości.

To jest tylko problem organizacyjny i radzimy sobie z nim na wiele sposobów, najczęsciej fizycznych. Ba, istnieją np układy TPM, które zawierają klucz, ale jednoczesnie zawierają bardzo wyrafine zabezpieczenia przed jego odczytem (w tym brutalnym, przez decapping). Wiec nawet jeśli "masz" klucz, bo ukradłeś scalak, to dalej go nie masz bo go nie ma jak wyciągnąć. Scalak pozwala na podpisanie czegoś, ale nie pozwala na wyciągnięcie klucza, a przy próbie ingerencji w krzem, uszkadza go, tracąc na zawsze.

Nie. To odróżnia procesory bezpieczne, do zastosowań krytycznych, od niebezpiecznych.

Ja nie wiem co Newag używa, ale bez względu na to co uzywa: skoro hackerzy dali radę zmienic wsad i go wgrać, to oznacza, że używają mikrokontrolera do migania diodami w celu napędzania infrastruktury krytycznej.

Czy już wspomniałem, że prawo tworzą prawnicze przygłupy?

Cytat bardzo wyraznie tyczyl sie alternatywy dla Windowsa i Microsoftu w urzedach. Co do sterowania jazda, nie widze pola do wiekszej dyskusji

- Linux nadaje sie rowniez i do tego, sa dostepne odpowiednie patche zapewniajace funkcjonalnosc systemu czasu rzeczywistego (PREEMPT_RT), choc rownie dobrze mozna by bylo zastosowac dowolny inny (m.in. Zephyr czy FreeRTOS). W pisanie na baremetal nikt rozsadny by sie nie pchal, znajac dynamiczne srodowisko biznesowe w branzy embedded (no chyba ze biznes programisty nie interesuje, co w pelni rozumiem).

Zgadza sie, nikt nikogo kryc nie bedzie, natomiast nikt tez sie nie bedzie wyrywac, by takie sprawy gdziekolwiek zglaszac. Przesluchiwany moze byc co najwyzej zarzad i wyzej postawione osoby w firmie, rotacja wsrod szeregowych pracownikow jest na tyle wysoka, ze nikt nie powinien zawracac sobie nimi glowy - a nawet jesli, to sie od nich nie dowie niczego, czego nie wiedzial wczesniej.

Nie, nie oznacza. Byla mowa wczesniej o tym, ze wykorzystuja architekture TriCore, a ona jak najbardziej wspiera Secure Boot (mikrokontrolery tej rodziny maja zwykle wbudowanego HSMa). Trzeba to tylko odpowiednio skonfigurowac. Ponadto to nie sa zabawki i maja wiele innych mechanizmow security (np blok CERBERUS do kontroli dostepu do portu debugowego).

Komus sie po prostu nie chcialo / nie oplacalo tego implementowac.

I jej nie wykorzystali? Czyli zwykłe odpierdalanie dziadostwa?

Skoko nie ma właczonego secure boot, to jest od miganai diodami, a nie od napędzania kolei.

Od początku w tym watku stawiam tezę, że to typowe dziadostwo, którego na pęczki jest w embedded. To dziadostwo może im teraz nawet pomóc w przypadku pozwu.

Tam była mowa o komputerach w urzędach a nie ECU.

[...]

Prostokąty i kółka... a ETCS to parę symboli i kresek. A jakież to niby cechy ma linux, k

kliknąłem przedwcześnie ;)

A jakież to niby cechy ma linux, które wykluczają go z takiego zastosowania? Czas startu nie ma żadnego znaczenia. Też może być we flashu procka jak się uprzesz. Szanse na uszkodzenie są również niewielkie, a jeśli nawet to masz dwa w kabinie dla wygody i bezpieczeństwa.

Tak, panel kontroly pokazany na filmie, pokazuje dokładnie to: prostokąty i kółka. Idę o zakład, że sam z siebnie nie steruje bezpośrednio czymkolwiek istotnym, co najwyżej komunikuje się z innymi sterowanikami.

To tylko trywialne GUI.

Uniwersalnego systemu operacyjnego, który we wszystkim jest kiepski, jak kazdy uniwersalny:

1) absurdalnie długie czasy uruchomienia (co widać na filmie), więc jak się zrobi reboot, to możesz już nie zdążyć hamować. 2) megabajty zbędnego kodu do obsługi zamykania klapy laptopa, obsługi karty dzwiękkowej na USB, sterowania nieistniejącymi wentylatorami i milionem podobnych "dodatków", z których każdy jest potencjalnym problemem bezpieczeństwa. Wyobraź sobie, że w wyniku błedu pracowania na nietypowej achitekturze, w połowie drogi do Koluszek, sterownik stwierdzi, że ktoś zamkną klapę. 3) system oparty o wiele procesów pracujących w systemie preemptive multitasking, z czego większość procesów systemowych jest zbędna. Co jest kompletnie bezuzyteczne w systemie gdzie jest tylko 1 okno i jedno UI i nie ma innej funkcjonalności. 4) Wymaga znacząco większego magazynu danych, w jakiejś minimalistycznej wersji rzedu setek MB, co powoduje nastepny punkt który może się popsuć 5) Z uwagi na megabajty kodu źródłowego do obsługi wszystkiego co zbędne, stanowi zagrożenie brakiem mozliwości audytu, co mogło być w zasadzie przyczyną wypadku kolejowego. Bo może to być sterownik myszki kórej nie ma. 6) Jest niemożliwy do łatwego kontrolowania spójności w przypadku sabotażu

To tylko prostokąty i kółka na ekranie. Urządzenie do ich wypasionego rysowania nie wymaga więcej niż kilkaset kB kodu. Dowód: Amiga.

Potrafimy je wyświetlać bez potrzeby ładowania 20MB kernela i modułów, w którym 95% kodu nigdy się nie wykona, ale poprawnie wymagało by audytu.

Nie chce mi się już kontrować na te nietrafione argumenty. Czyli co? Dziadostwo i druciarstwo ..\dupa\build? (choć w tej sytuacji raczej /dupa/build)