W dniu 7.12.2023 o 21:17, heby pisze:
> 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
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ą.

--
SW3

do góry

W dniu 7.12.2023 o 22:12, heby pisze:
> 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.

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

--
SW3

do góry

SW3 <s...@p...fm.invalid> napisał(a):
> 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ą.

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:
https://gynvael.coldwind.pl/?lang=pl&id=777

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 08/12/2023 10:30, SW3 wrote:
> Tak się wydaje ale dieselgate udawało się jakiś czas utrzymać w
> tajemnicy. Volkswagen nie miał prawidłowego cyklu?

Bardzo możliwe.

do góry

On 08/12/2023 10:27, SW3 wrote:
> W dniu 7.12.2023 o 21:17, heby pisze:
>> 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
> 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ą.

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.

do góry

W dniu 08.12.2023 o 10:36, Grzegorz Niemirowski pisze:
> SW3 <s...@p...fm.invalid> napisał(a):
>> 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ą.
>
> 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: https://gynvael.coldwind.pl/?lang=pl&id=777
>

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ć.

do góry

io <i...@o...pl.invalid> napisał(a):
> Gościu w ogóle widział ten kod binarny, że się na jego temat wypowiada?

Nie musiał.

> 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ć.

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

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

W dniu 08.12.2023 o 11:00, heby pisze:
> On 08/12/2023 10:27, SW3 wrote:
>> W dniu 7.12.2023 o 21:17, heby pisze:
>>> 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
>> 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ą.
>
> 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.

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".

do góry

io <i...@o...pl.invalid> napisał(a):
> Podpisywanie zapewnia spójność samego oprogramowania, ale Dooma da się
> wgrać :-)

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ę.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 08/12/2023 12:37, io wrote:
> 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"

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.

> 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".

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.

do góry