Sebastian Biały <h...@p...onet.pl> writes:

> Robie code review *ogromnej* aplikacji od wielu lat jako normalna
> czynność związaną z wykonywanym zawodem. Daje Ci gwarancje że jesli
> chce mieć zle zamiary to przejdę i code review bo milion oczu nie
> oznacza milikon razy dokładniej. Co prawda zdarzają się przykłady
> pozytywne (i przypadkowo odkryte):
>
> https://freedom-to-tinker.com/blog/felten/the-linux-
backdoor-attempt-of-200/3

To akurat nie miało żadnego związku z code review, w tamtych czasach
Linus i sp. używali takiego narzędzia "BitKeeper", a dla osób, które nie
chciały tego używać (np. ze względu na brak źródeł, albo na
12-miesięczny zakaz pracy przy "konkurencyjnych projektach"), był
automatyczny mirror w CVSie. I do tego ostatniego ktoś się włamał.
Nikt, kto nie korzystał z tego serwera CVS, nie dostał tego backdoora.

Zostało to odkryte przez przypuszczalnie LMcV przez proste porównanie
zawartości bitmovera i cvsa.

Duuużo bardziej niebezpieczne było późniejsze włamanie do *.kernel.org,
w którym atakujący mieli dostęp do całego archiwum, a także chyba do
kluczy używanych do generowania podpisów .sig. Na szczęście to były
czasy gita i żadne numery z wstawieniem czegoś do repozytorium już nie
przechodziły.


Tak czy owak, code review taki jak tu daje szansę wykrycia backdoora,
ale jaka to jest szansa - taka sobie.

> Ale od tamtego czasu kernel jest znacznie większy a część kodu
> wychodzi poza kontrolę (sterowniki kart graficznych).

Binarne sterowniki kart graficznych do Linuksa były dużo wcześniej,
jeszcze w ubiegłym wieku. Sam się na nie nadziałem, więc pamiętam im to
aż za dobrze.

> Być może. Niestety zmartwie Cie: żadko ktore malware zajmuje się
> pierdołami typu lamanie roota. Do wykradzenia pieniędzy wystarczy byle
> gówno napisane przez imbecyla w VisualBasicu w postaci exe w mailu. W
> temacie problemów z tego watku kernel mode jest nieistotny.

To jest akurat prawda.
--
Krzysztof Hałasa

do góry

On Mon, 28 Mar 2016, Krzysztof Halasa wrote:

> Zakładamy, że bankowi możemy jednak ufać.

No ale to założenie nie jest niezbędne. Wystarczy przecież, że bank
opublikuje kody źródłowe aplikacji i (dla uproszczenia) binarki na tego
tokena. Wówczas klient może sobie tokena kupić w dowolnym miejscu i wgrać
samemu a klucz publiczny dostarczyć do biura banku z dowodem tożsamości.

do góry

Sebastian Biały <h...@p...onet.pl> writes:

> Problem jest w
> czyms innym: nikt nie wprowadza backdoorów i trojanów od *lat* do
> jadra linuxa, bsd.

Poważnie? A skąd ta wiedza?
Bo jeśli takiej nie masz (a wiemy że nie masz - bo nikt nie ma) to
jedyne bezpieczne założenie jest przeciwne.

> natomiast pociesze cie: istnieje spore
> prawdopodobieństwo że niektóre elementy związane z kryptofrafią w
> OSach (okolice ipv6) zostały dyskretnie skompromitowane w sposób
> matematyczny (np. poprzez oslabienie generatora liczb losowych lub
> samych algorytmów).

IPv6 to drobiazg. Czytasz niewłaściwe fragmenty. Zainteresuj się
np. FIPS, a nie jakimś superniszowym IPSEC w IPv6.
--
Krzysztof Hałasa

do góry

Sebastian Biały <h...@p...onet.pl> writes:

> Po drugie problem z firewire jest
> *poważny* ponieważ urzadzenia tego typu mają zmapowany cały ram.

Domyślnie, dostępne jest pierwsze 4 GB przestrzeni adresowej (modulo
sztuczki z IOMMU). W praktyce nie jest to obecnie żaden problem,
a w ogóle nowe komputery prawie nie mają FireWire.

BTW to bardzo fajne narzędzie.
--
Krzysztof Hałasa

do góry

Sebastian Biały <h...@p...onet.pl> writes:

>> Ale TPM to nie jest żadne panaceum, to tylko jeden z elementów
>> układanki, i nic on nie da, jeśli w systemie ogólnego przeznaczenia
>> będzie wiele dziur (a tak właśnie jest i będzie).
>
> Nie jest to prawda. Możesz mieć dowolna ilość dziur. Do momentu ataku
> fizycznie na chip bedzie on podpisywał w sposób bezpieczny i pewny (od
> początku zakładam wyświetlacz i pin). Jedyną forma ataku jest wtedy
> DoS czyli nic.

Niestety TPM nie ma wyświetlacza - a więc to co napisałem jest prawdą.
--
Krzysztof Hałasa

do góry

Rafal Jankowski <j...@o...wsisiz.edu.pl> writes:

>> Zakładamy, że bankowi możemy jednak ufać.
>
> No ale to założenie nie jest niezbędne. Wystarczy przecież, że bank
> opublikuje kody źródłowe aplikacji i (dla uproszczenia) binarki na
> tego tokena. Wówczas klient może sobie tokena kupić w dowolnym miejscu
> i wgrać samemu a klucz publiczny dostarczyć do biura banku z dowodem
> tożsamości.

To nie wystarczy. Przede wszystkim, nie wiadomo czy potrzebujemy w ogóle
kluczy asymetrycznych. Po drugie, "wgrywanie aplikacji" do tokena (bez
jego destrukcji) nie powinno być specjalnie łatwe, gdyż w przeciwnym
razie ktoś mający przez chwilę dostęp do tokena (niekoniecznie po
stronie klienta, może to być pracownik banku) mógłby go przeprogramować.
Jasne jest chyba, że 99%+ klientów nie będzie tam nic instalować.

Podpisywanie zleceń bankowych kluczem prywatnym to oczywiście nie SF
i jest to stosowane od lat, ale raczej nie w przypadku klientów
indywidualnych (poza ew. częścią private).
--
Krzysztof Hałasa

do góry

On Tue, 29 Mar 2016, Krzysztof Halasa wrote:

> To nie wystarczy. Przede wszystkim, nie wiadomo czy potrzebujemy w ogóle
> kluczy asymetrycznych. Po drugie, "wgrywanie aplikacji" do tokena (bez
> jego destrukcji) nie powinno być specjalnie łatwe, gdyż w przeciwnym
> razie ktoś mający przez chwilę dostęp do tokena (niekoniecznie po
> stronie klienta, może to być pracownik banku) mógłby go przeprogramować.
> Jasne jest chyba, że 99%+ klientów nie będzie tam nic instalować.

Ktoś mający przez chwilę dostęp do tokena jest w posiadaniu znajdującego
się w nim klucza (w sensie: może go użyć) jeśli nie mamy dodatkowych
zabezpieczeń które powiązują token z osobą. Jeżeli aplikację wgrywa bank
to:

- po pierwsze w dalszym ciągu można postawić mu zarzut "daliście mi token
z kluczem i aplikacją, a teraz mówicie, że transakcja była
uwierzytelniona bo tak wskazuje wasz system informatyczny". W przypadku
gdy klient sam generuje klucz i wgrywa aplikację taki zarzut pod adresem
banku już jest niemożliwy

- po drugie wyobrażam sobie że można wtedy dość skutecznie przeprowadzić
od strony banku atak ukierunkowany na konkretną osobę wysyłając coś co w
rzeczywistości bezpiecznym tokenem nie jest a klucz prywatny ma
atakujący. Jak dyrektor banku przeczyta, że ktoś go zwyzywał na niusach
od debili to ma pokusę aby to zrobić. Jeśli w token każdy zaopatruje się
indywidualnie i anonimowo tudzież w podobny sposób wgrywa aplikację to
taki atak jest właściwie wykluczony.

Piszesz, że nie koniecznie potrzebujemy kluczy asymetrycznych. Możesz
wyjaśnić jak to się odbywa bez takich kluczy? Wyobrażam sobiem, że taki
sam klucz symetryczny musiałby powstać jednocześnie w tokenie użytkownika
i infrastrukturze banku. Ale zakładając, że wogóle on nie powinien
opuszczać chipa jest to jakieś wyzwanie technologiczne. Rozumiem, że coś
na kształt takiej technologii istnieje? Chodzi o provisionowanie klucza na
zasadzie jakiegoś DRMa? Możesz podać jakieś hasło albo wyjaśnienie o co
chodzi?

do góry

On 2016-03-29 00:06, Krzysztof Halasa wrote:
>> Ma znaczenie. Pojawienie się jednego malware na Linuxa to sensacja na
>> skale madialna. W miedzyczasie powstaje setka malware dla windowsa w
>> kilkuset tysiącach mutacji. Skala ma znaczenie. Miedzy innymi obecnie
>> bezpieczniej jest wykonywać transakcje na Lin/OS X nie z powodu że są
>> bezpieczne, tylko z powodu że większe powodzenie przestępcy mają na
>> win i nie bedą zajmowali się hakowaniem tych kilku nerdów uwalonych
>> pizzą bo tam nie ma kasy a przede wszystkim jest mało idiotów.
> Mogę zgodzić się tylko z tym, że Linux jest bezpieczniejszy.

Ale ja tego nie powiedziałem, wręcz przeciwnie!

> Ale tu nie
> chodzi o to, by się pastwić nad Windows (które BTW podobno też jest
> coraz bezpieczniejsze), tylko o rozwiązanie _bezpieczne_. Nie tylko nie
> aż tak bardzo niebezpieczne.

Nie ma bezpiecznego rozwiązania. Jedynym jakie znam to odpalanie za
każdym razem systemu z LiveCD. Przy czym przy odpowiedniej dozie paranoi
można wtedy wlaśnie zapytać co z malware w UEFI, myszce i podkładce.

> Rozmaitego "softu" na Linuksa jest bardzo dużo. Myślisz że botnety to
> tylko na Windows działają?

Tam działają skutecznie. Na linuxa z powodu:
a) kłopotów z ABI
b) kłopotow z architekturami cpu
c) zainteresowaniem znikomym

... bedzie cięzko dostarczyć malware w wersji binarnej. Za dużo roboty.
Mozna natomiast albański malware "skompiluj mnie, ustaw roota i odpal".

Tak, wiem że może się skompilować sam, ale nie kązda distro ma
kompilator. Można tez napisać bootnet w bashu zapewne. Mozna. Tylko po ch...

>> Może jednak coś przeoczyłem w dyskusji, więc wyostrzę: rozmawiamy o
>> donglu dostarczanym przez bank, wpinanym w USB/Whatever.
> To może zainteresuj się tym, czym jest TPM ("Trusted Platform Module").
> To nie jest dowolne urządzenie kryptograficzne, TPM to jest
> ustandaryzowana konkretna implementacja, w szczególności pozbawiona
> interfejsu użytkownika.

TPM jest w tej dyskucji tylko *przykładem* zabezpieczeń w krzemie. Bodaj
nalepiej opisanym pod kątem reverse engeneering obok kart sim. Wlasciwe
scalaki uzywane w tym urzadzeniu bedą tak zabezpieczone, ale działać
beda w sposób ograniczony (nie jest potrzebna wydajnośc obliczeniowa).

> W tak zmienionych warunkach rzeczywiście można to zrobić bezpiecznie,
> co zresztą od początku pisałem. Z tym że proponuję skasować USB
> i zastosować małą kamerę - jest to bardzo dobre rozwiązanie, sprawdzone
> w praktyce.

Bardzo dobrze że sefie tak latwo wydrukować. Ja proponuje jeszcze
rozpoznawanie głosu póki nie wynaleziono magnetofonów.

http://www.computerworld.com/article/2531298/windows
-pcs/laptop-face-recognition-tech-easy-to-hack--warn
s-black-hat-researcher.html

Na marginesie: moc obliczeniowa jest zupełnie z innej półki jeśli chcesz
sobie detektować twarz w małym chipie. Prawidłowo klasyfikować
swój-inny. Bo jesli bedzie to klasyfikować komputer - nie będzie to już
bezpieczne.

> Oprócz poprawy bezpieczeństwa

W stosunku do panienki od nazwisk rodowych? No tak, w sumie tak.

do góry

On 2016-03-29 00:39, Krzysztof Halasa wrote:
>> Problem jest w
>> czyms innym: nikt nie wprowadza backdoorów i trojanów od *lat* do
>> jadra linuxa, bsd.
> Poważnie? A skąd ta wiedza?
> Bo jeśli takiej nie masz (a wiemy że nie masz - bo nikt nie ma) to
> jedyne bezpieczne założenie jest przeciwne.

Żeby udowodnić że trojany na linuxie się problemem w kernelu należy
podać przykłady takich prób bądź ich istnienia. Jesli nie ma takich
przykładów to hipoteza odrzucana jest z automatu. Jak napisałem istnieje
niewielka szansa że nsa/whatever majstrowała przy kryptografii ipsec.
Ale to nie jest dziura w kernelu tylko w specyfikacji protokołu.

Nie rozumiem dlaczego mialym udowaniać że nie ma czegoś czego nie
stwierdzono. Mam *udowadniać* że nie bylo wybuchów w wiadomym samolocie
czy też raczej mam *udowadniać* że były?

> IPv6 to drobiazg. Czytasz niewłaściwe fragmenty. Zainteresuj się
> np. FIPS, a nie jakimś superniszowym IPSEC w IPv6.

Przecież ipsec to tylko jeden przykład z wielu. Obecnie majstrowanie
przy kryptografii jest o tyle dobre że mało jest na świecie osob ktore
znajdą backdoor w wartwie matematycznej.

do góry

On 2016-03-29 00:45, Krzysztof Halasa wrote:
>>> Ale TPM to nie jest żadne panaceum, to tylko jeden z elementów
>>> układanki, i nic on nie da, jeśli w systemie ogólnego przeznaczenia
>>> będzie wiele dziur (a tak właśnie jest i będzie).
>> Nie jest to prawda. Możesz mieć dowolna ilość dziur. Do momentu ataku
>> fizycznie na chip bedzie on podpisywał w sposób bezpieczny i pewny (od
>> początku zakładam wyświetlacz i pin). Jedyną forma ataku jest wtedy
>> DoS czyli nic.
> Niestety TPM nie ma wyświetlacza - a więc to co napisałem jest prawdą.

TPM bedzie podpisywał bezpiecznie w każdych warunkach kiedy nie doszło
do kompromitacji fizycznej chipa. Ale my chcemy nie tylko wiedzieć że
chip istniał. Chcemy jeszcze wiedzieć że wlasciciel istniał i wiedział
co podpisuje. Do tego potrzebny jest wyświetlacz (pewnośc że to bank) +
klawiatura (pewnośc że to user).

do góry