12:41
24/4/2017

Opinię GIODO możecie znaleźć tutaj. Niezależna uważa, że to zły pomysł, bo Rosjanie ;) Nota bene, Niezależna jest na nie także w przypadku GPG (bo Niemcy ;). Zostawmy jednak spiski i zabawne, nieeksperckie opinie. W tym temacie pojawiła się też opinia kryptologa autorstwa Kamila Kaczyńskiego, słusznie punktująca problem wymiany klucza oraz weryfikacji tożsamości Alicji i Boba oraz mniej słusznie, w naszej opinii, brak zapewnienia integralności “kompreso-szyfrowanych” dokumentów oraz błędy w samej aplikacji 7zip:

W przypadku rekomendowanego przez GIODO 7-zip szerokim echem odbiły się wykryte w zeszłym roku luki bezpieczeństwa. Pozostawione w oprogramowaniu błędy pozwalały atakującym na zdalne wykonanie kodu, a także na wykonanie operacji mających na celu uszkodzenie stosu pamięci lub przepełnienie bufora. Co bardziej znaczące, 7-zip jako oprogramowanie Open Source jest składową wielu innych aplikacji. Wykorzystanie błędnego kodu spowodowało efekt lawinowy i wiele z tych aplikacji do dnia dzisiejszego posiada niezałatane podatności. Zgodnie z informacjami podanymi przez Talos, podatności te wynikały z błędnej weryfikacji wprowadzanych danych. Dane wprowadzone do aplikacji mogą zawsze pochodzić z potencjalnie niezaufanego źródła, dlatego odpowiednia ich weryfikacja jest kluczowa dla bezpieczeństwa każdej aplikacji. Należy zaznaczyć, iż nie była to jedyna wzmianka dotycząca problemów z rosyjskim oprogramowanie. Na temat 7-zip w wersji portable można także odnaleźć wzmiankę w najnowszym wycieku dokumentów opublikowanym przez WikiLeaks.

Tu dla Waszej wygody CVE dla 7zip, z czego cześć błędów została odkryta przez naszego rodaka, Marcina Nogę.

A jakie jest Wasze zdanie? Lepiej, żeby normalni ludzie (tj. tacy, którzy nie ogarną GPG), korzystali z 7zip, czy nie? Czy integralność przesyłanych dokumentów w tym use-case, które poruszyło GIODO jest najistotniejsze? Czy to, że w 7zip znaleziono błędy powinno mieć jakikolwiek wpływ na podejmowanie decyzji, czy ten program jest zły/dobry do szyfrowania (błędy przecież są znajdowane w każdym pakerze/oprogramowaniu, a nie każdy packer ma otwarty kod źródłowy).

Przeczytaj także:

Ten wpis pochodzi z naszego linkbloga *ptr, dlatego nie widać go na głównej.
*ptr możesz czytać przez RSS albo przez sidebar po prawej stronie serwisu.

51 komentarzy

Dodaj komentarz
  1. mnie osobiscie razi ze giodo jesli juz cos rekomenduje, to dlaczego nie promuje polskich rozwiazan!? wszak to urzad a nie jakis think tank

    • żartujesz prawda?
      Jeśli to nie żart to rozumiem, że sam używasz systemu operacyjnego Crook albo IPIX, tak?

    • Skoro państwo niszczyło polską gospodarkę za czasów PRL-u i dalej to robi w III RP, to nic dziwnego, że brakuje polskich rozwiązań do promowania.
      P.S. Właśnie wczoraj dowiedziałem się o CROOK-u :D https://www.minds.com/newsfeed/703367360676896773
      P.S.2. Dalej nie da się wstawiać komentarzy z wypełnionym polem URL :P

    • 1.Bo takich rozwiązań za bardzo nie ma
      2.Jak mają to być takie rozwiązania jak system od Nabino mający obsłużyć wybory,to klękajcie narody i módlcie się za nas.
      3.Po kiego grzyba wymyślać na nowo koło ? Póki co algorytmy typu AES świetnie działają.

    • @kez87 VMPC

    • Seba 2017.04.25 14:26
      Po wejściu do UE Polska nie isnieje . Przypominam że zgodnie z konstytucją polską prawo UE jest wyżej nad prawem Polskim. To znaczy tyle że rząd jest tylko wirtualny.

      Świat zmierza do globalizacji – 2 max. 3 korporacje dyktujące całemu światu własne zasady ,ale takie są skutki wolnorynkowości . GIODO powinno się zająć FB, MS, GOOGLE, USA i całym tym śmieciem wyciągajacym dane osobowe bo to chore się robi zamiast 7zip-ep.

  2. Ten giodo co to powiedział że tablice rejestracyjne to dane osobowe?
    Może lepiej niech akceptowalną formą będzie nazywanie katalogów – nie otwierać :>

    • Dobry pomysł. To naprawdę sprawdzona metoda – wiele stron zabezpiecza w ten sposób obrazki i filmy dla “dorosłych” przed dostępem dzieci :D

  3. Przy drugim wycieku shadowbroker był cały folder poświęcony 7zip’owi. Jaka jest wasza opinia w tym temacie?

  4. Tekst „Niezależnej” możnaby pominąć milczeniem z przyczyn oczywistych, ale nie daruję sobie: ciekawe, w czym napisali ten artykuł — zapewne rylcem na glinianej tabliczce, żeby nie używać oprogramowania „amerykańskiej korporacji”.

    Zdanie K.K. powtarza opinię GIODO, który sam wskazuje na problem wymiany klucza i traktuje to jako punkt wyjściowy do sugerowania GnuPG.

    W samej opinii GIODO nie dostrzegam nic niewłaściwego. Wręcz przeciwnie: dobrze zrobili swoją robotę, podając przykładowe rozwiązania i wskazując problemy związane z ich używaniem. Jako formę zabezpieczenia zalecają (przez odwołanie do MAC/SEC/1/15) użycie smartcardów i własnej, wewnętrznej struktury PKI. Ktoś ma lepszą opcję do zaoferowania?

    Podsumowując: nawet gdyby dokument faktycznie zalecał użycie 7z, to w obecnej sytuacji nadal poparłbym taką opinię. Sam, gdy przesyłam dane „szaremu ludkowi”, używam właśnie 7z z szyfrowaniem. Czemu? Bo w ten sposób gwarantuje jakiekolwiek, choćby podstawowe bezpieczeństwo. Żeby uniknąć „tajemniczego, rosyjskiego informatyka” mógłbym spakować tar-em i zaszyfrować np. GnuPG albo wprost OpenSSL, tylko co z tego, skoro odbiorca nie poradzi sobie z otwarciem? Co z tego, że ja zaszyfruje, skoro druga strona mnie wyśle wszystko gołe? Proste narzędzia, jak 7z, pozwalają osiągnąć chociaż to minimum, bo mam pewność, że odbiorca otworzy (więc mogę szyfrować) i wiem też, że jest spora szansza, że poradzi sobie z zaszyfrowaniem, gdy będzie słał do mnie. Rozwiązanie z wadami jest lepsze niż jego brak.

    A błędy? Jeżeli oprogramowanie nie zaliczyło jeszcze poważnych dziur, to oznacza tylko tyle, że nie zostały jeszcze opublikowane. Czy któreś ze wskazanych CVE dotyczy szyfrowania? Nie. 7z używa jakiegoś bzdurnego, autorskiego pseudoszyfrowania? Nie, zwykłego AES-CBC z — jako KDF — wielokrotnego SHA256. Coś nie gra? Nie. Czy zaimplementowano je poprawnie? Nic mi nie wiadomo, by zauważono jakieś problemy — w szczególności celowego osłabiania AES-a, co zapewne poszło na pierwszy ogień podczas jakichkolwiek analiz. Czy znalezione błędy sugerują stosowanie kiepskich praktyk programistycznych? Nie. Zatem o czym mowa? I co jako alternatywa?

    • Brawo, pięknie napisane.
      Jak zobaczyłem wykaz CVE dla 7zipa to nie wiedziałem czy śmiać się czy płakać. Dla wersji powyżej 16.02 nie wykryto jeszcze żadnych luk a z 4 znalezionych w różnych wersjach tylko jedna jest naprawdę poważna, gdyż umożliwia wykonanie kodu z uprawnieniami 7zipa i to w dość świeżej odsłonie 16.02. Jak pomyśle o serze szwajcarskim jak FlashPlayer, Adobe Reader i samo Windows to aż strach komputer uruchomić ;).

      O jednym krytycznym CVE z 2008 roku to chyba raczej możemy nie dyskutować. Czy jednak trzeba? ;)

    • Na (zasadne) pytania z ostatniego akapitu odpowiem: opisał to człowiek, który nie wiedział o czym pisze. Może zna się na kryptologii, ale na software, który potrafi szyfrować i na lukach w oprogramowaniu – wcale.

  5. Według mnie lepsze takie szyfrowanie niż żadne.

    • Wręcz przeciwnie. Fałszywe poczucie bezpieczeństwa i user przestaje być uważny.

    • @Marek
      O czym Ty piszesz? Jakie poczucie bezpieczeństwa? Przeważająca ilość użytkowników generujących JPK ma w tyle czy to jest szyfrowane, czy nie.

    • @Marek: sugerujesz zatem, że nie powinno się stosować szyfrowania, bo przez to traci się czujność?

      Gdyby szyfrowanie w 7-zipie było mitacją — jak „zabezpieczenie przed zapisem” w MS Office albo „szyfrowanie” w starych wersjach tego pakietu — to taką opinie mógłbym zrozumieć. Ale tak nie jest. Używa prawidłowo działającego szyfrowania. Wymaga zaufanego kanału do wymiany klucza i nie daje uwierzytelnienia, co GIODO wskazał, ale to nie czyni z niego „udawanki”.

  6. E tam, po co szyfrowanie – wystarczy przecież dodać dopisek że to informacje poufne i jak się nie jest adresatem to skasować proszę i załatwione, c`nie? ;)

    • To tylko prawnicy mogą ;)

    • Jak w jednej z krakowskich kancelarii zaszyfrowaliśmy dane przesłane do potentata z warszawy to wywołało to popłoch płacz i zgrzytanie zębów po drogiej stronie :D:D:D

      Trzeba było ich za rączkę prowadzić jak rozszyfrować bo nie potrafili a ich informatyk olał temat bo po co takie zadziwianie w tym krk wymyślają jak mogli przecież normalnie :D:D:D

      Bezpieczeństwo danych to taka radosna fikcja.
      Wdrożone procedury i pierdoły a pracownicy przesyłają sobie pliki mailem…. Nawet szyfrowania nie ma choć w sumie to i tak niewiele by zmieniało.
      Jak się ich pyta czy wszyscy sie dobrze czują to…

      A bo mieliśmy katalogi udostępnione ale zlikwidowali i dali program do obiegu.
      A program zły?
      No za trudny i skomplikowany i…. (to fakt że wiele z programów ułatwiających życie po prostu wszystko komplikuje)
      A nie możecie sobie udostępnić katalogu?
      Niewolno bo to niebezpieczne….

      :D A poza tym jak wszystko jest na skrzynce biuro@domena.??? to nie zginie :D
      Ot taki backup…. W chmurze…. :D

  7. Jeśli poprawiono te znalezione błędy, to nie widzę problemu.
    Chyba że ktoś przedstawi program o tej samej funkcjonalności, w pełni udowodniony jako poprawny (tylko kto by za taką analizę zapłacił).

  8. Podaliście opinię portalu Biznes Alert, a nie GIODO.
    Opinia GIODO od której zaczęła się cała burza znajduje się tutaj:
    http://giodo.gov.pl/222/id_art/9801/j/pl/

    Trzeba zauważyć, że GIODO wskazał 7-zip jako przykładowe oprogramowanie do szyfrowania plików. Jeżeli komuś sie 7-zip nie podoba, może użyć innego programu, WinRara, WinZipa, you name it. Ważne jest, żeby szyfrować dane, a nie słać je otwartym tekstem.

    • Racja. Dzięki za czujność – poprawione. Zły link w schowku :(

  9. Niezależna jako podstawa do dyskusji? Bądźmy poważni….

  10. Mnie niezbyt podoba się propagowanie przesyłania danych w zaszyfrowanych pakerem archiwach z jednego dokładnie powodu: dokładnie ta technika (archiwum zabezpieczone hasłem) jest używana do obchodzenia programów antywirusowych i nakłaniania userów do uruchomienia pliku wykonywalnego ze szkodliwym oprogramowaniem na swoim kompie.

    • +1

    • AV maja opcje zagladania do archiwum ktore nie ma hasła.
      Czyli jak masz hasło to się spodziewasz ze dostaniesz maila z zalacznikiem zaszyfrowanym. Jak sie zip otwiera bez hasla i nie znasz adresata – nie wypakowuj.
      Jak sie boisz 0day na 7zip – nie wypakowuj.
      A zipy bez hasla zostaw antywirusom.
      Zip w zipie – czerwona flaga – usuń.
      Niektore AV maja opcje rekursywnego przegladu zipów.

    • @mnmnc

      Zgadzam się z tym, i od dawna przekazuję te zasady w uproszczonej formie userom. Między innymi taką, że zahasłowany załącznik prawie na pewno zawiera “wirusa”. Kampanie takie jak ta: https://niebezpiecznik.pl/post/uwaga-prawnicy-e-mail-pelnomocnictwo-dla-kancelarii-zawieral-wirusa/ docierają do nich całkiem często w porównaniu do innych prób nakłonienia do uruchomienia na swoim urządzeniu niebezpiecznego kodu. Wygląda na to, że zahasłowane archiwa stanowią przeszkodę także i dla antywirusów u hostingodawców – i przez to nie są eliminowane “w drodze” do użytkownika.
      Na około 30 maili z zahasłowanymi załącznikami zgłaszanych mi przez różnych userów, ANI JEDEN nie był potrzebną przesyłką – wszystkie zawierały jakiś malware. Zagrożenie udało się zmniejszyć właśnie przez zakaz otwierania załączników z hasłami. Tą drogą dotychczas nie poinfekowali sobie komputerów ani razu (innymi drogami czasem tak, ale to osobne historie).

      Dlatego niezbyt podoba mi się zachęcanie do używania zahasłowanych archiwów w normalnej komunikacji.
      IMO jeśli użytkownik przyzwyczai się otwierać załączniki z hasłami, prędzej czy później otworzy także zainfekowany. Dla mnie prawdopodobieństwo takiego zdarzenia jest wielokrotnie większe niż wykorzystania potencjalnej luki w 7zip. Po co łamać zamek, jeśli wystarczy poprosić o jego otwarcie ;(

      Z 7zip nie mam problemu mentalnego, używam od dawna – ale nie do szyfrowania przesyłanych załączników.
      Oczywiście jeśli obaj użytkownicy są świadomi, i uzgodnili hasło drogą nie-mailową, to można się umówić na takie przesyłanie danych. Ale taka sytuacja wydaje się zdarzać rzadko.

    • Zasadniczo masz rację. Ale…
      Wszystkie te malwary w zahasłowanych plikach w tekście maila wyraźnie podają hasło – bo inaczej przecież ofiara zipa nie rozpakuje i “zipa dumna” a nie infekcja.
      A przecież jeśli wysyłam komuś zahasłowane dane to nie po to żeby w tym samym mailu słać klucz. Więc jeśli nie czekam na zahasłowany plik a taki otrzymuję – i to jeszcze z hasłem explicite w mailu zapisanym – wyczuję ściemę. Dobrze myślę?

    • @Romek

      Masz oczywiście rację, że jeśli używać zaszyfrowanych archiwów, to w sytuacji gdy hasło jest uzgodnione inną drogą. A hasło wysłane e-mailem powinno włączać czerwoną lampkę :)

      Z tym, że tę ściemę Ty wyczujesz, ja wyczuję, 90% czytelników niebezpiecznika itp portali wyczuje. Ale oprócz programistów, adminów, serwisantów i Świadomych Użytkowników jest też całe pełno użytkowników, cóż, zwykłych. Na przykład sekretarka, księgowa, urzędnik, ykhm szef małej firmy (to specjalny rodzaj), agent ubezpieczeniowy, radca prawny, architekt, grafik, bibliotekarz, nauczyciel, lekarz, i tak dalej. Muszący obsługiwać komputer w ramach swojej pracy niezwiązanej z informatyką. Czasem umiejący wyklikać tylko określoną sekwencję poleceń i gubiący się gdy np. przeglądarka się znienacka zaktualizuje. Mam do czynienia z takimi użytkownikami. Nie zawsze wyczuwają ściemę, i to niezależnie od swojego wieku. Dwa przykłady: 1) od jednego miałem kilka telefonów, że nie otwiera się mu awizo załączone do maila z dhl, bo pisze o jakimś trojanie, i czy ja mógłbym otworzyć to awizo. Przy czym mail był oznaczony w kliencie poczty jako “Zagrożenie”, miał czerwony baner ostrzegawczy, a załącznik podmieniony na przez antywirus na infected.txt, zawierający informację o wykrytym trojanie. Człowiek nie mógł uwierzyć, że to jest ściema. Dostawał takie maile kilka razy i za każdym razem musiałem tłumaczyć od nowa. W jednym przypadku antywirus zadziałał dopiero po otwarciu przez niego załącznika i nie wszystko zablokował, trochę drobiazgu się wbiło. Na szczęście nie ransomware, na konto użytkownika, i dało się wyczyścić. Przy czym ten gość nie jest głupi, w swoim zawodzie naprawdę dobry, a pod względem inteligencji ogólnej wyraźnie bystrzejszy ode mnie. Ale cierpliwość do komputera nie jest jego najmocniejszą stroną. 2) całkiem bystra osoba obsługująca korespondencję jednej firmy (nieinformatycznej) zgłosiła że nie da się pracować ponieważ antywirus ciągle zgłasza jakieś zagrożenie. Co się okazało – antywirus zgłaszał infekcję w TEMP (czyli po rozpakowaniu archiwum, tym razem nieszyfrowanego), osoba klikała “usuń”, antywirus usuwał plik, po czym osoba otwierała ponownie zainfekowany załącznik z poczty. I tak kilkanaście razy. Mimo, że mail był oznaczony w kliencie poczty jako “uwaga zagrożenie”. I mimo, że wcześniej prawidłowo wyłapała dziesiątki podejrzanych maili (Tak, filtry ich dostawcy poczty działają źle. Ale nie dają się przekonać do zmiany). Po prostu którymś sprytnym wybiegiem i ją podeszli.

      Może to z mojej strony brak myślenia biznesowego, ale serio wolę robić konstruktywniejsze rzeczy niż sprzątanie takim osobom kompów po kolejnym socjotechniczno-malware’owym ataku ;)

  11. Sugestia, ze GIODO dopuszcza, zaleca lub rekomenduje 7Z/GPG/PGP jest nadinterpretacja. W swojej opinii GIODO wskazuje tylko, ze takie rozwiazania sa stosowane. Jesli GIODO rekomenduje, to zaznacza to wyraznie np. rekomendacje zwiazane z PKI.

    Moze jestem purysta, ale od urzedu zajmujacego sie ochrona danych osobowych oczekiwalbym rowniez pewnej pieczolowitosci przy publikowaniu dokumentow. Zamiast tego z metadanych dokumentu mozemy dowiedziec sie, ze PDF przygotowano po MS OFFICE 2013, w dniu piatek 2017/03/10 o 10:30, a wykonano to wszystko z oprogramowania przypisanego do p. Doroty Skolimowskiej. Szybkie zapytania dostarczaja dodatkowych informacji, ktore wspieraja przypuszczenie, ze p. Dorota byla zaangazowania w przygotowanie tego dokumentu.

  12. Widać, że powstają dwie zwalczające się grupy: PiS Hat i PO Hat ;-)

    Jeżeli chcemy ukryć korespondencję w sprawie prezentu imieninowego dla żony (o ile nie jest nią to Joanna R., bo wtedy nawet TrueCrypt nie starczy, gdy przyjdzie sprzątaczka ;-), to wystarczy narzędzie na stronie http://www.rot13.com/.

    Jeżeli chcemy przesłać wrażliwe dane (np. dokumentację medyczną pacjenta z pobytu w psychiatryku), to 7zip w zupełności wystarczy pod warunkiem, że:

    1) Hasło będzie spełniało co najmniej wymagania z załącznika B VIII rozporządzenia wydanego na podstawie art. 39a ustawy OODO.

    2) Przy “szyfrowaniu” 7zipem zaznaczymy opcję “zaszyfruj nazwy plików”.

    3) Hasło przekażemy osobiście i nadawca oraz odbiorca nie ujawnią go świadomie lub nieświadomie.

    4) Zarówno komputer nadawcy, jak i komputer odbiorcy jest wolny od złośliwego oprogramowania (np. key loggerów, koni trojańskich, itp. ustrojstwa).

    5) Użyjemy aktualnie najnowszej wersji programu 7zip pobranej ze strony autora, a nie ze strony typu tiny.cc czy 7zip.com.

    6) Nie są to dane medyczne Prezesa lub Prezydenta, co zwiększyłoby determinację do nieuprawnionego ich ujawnienia (celowo napisałem ujawnienia, a nie odszyfrowania, bo przeważnie skuteczniej, szybciej i taniej jest zastosować socjotechnikę na pielęgniarce pracującej w szpitalu psychiatrycznym niż dogrzewać chałupę klastrem z kart GPU).

    Tu dochodzimy do sedna sprawy. Zabezpieczenie musi być adekwatne do skutków nieuprawnionego ujawnienia chronionych danych i determinacji osób, którym na tym zależy.

    Równie ważne (jeżeli nie ważniejsze) jest prawidłowe posługiwanie się danym narzędziem. Nawet jeżeli dysponując odpowiednią wiedzą sami napisaliśmy poprawną implementację programu do szyfrowania AES256, ale nasze tajne hasło jest zapisane na żółtej karteczce przyklejonej gdzieś na monitorze w rejestracji, to całe bezpieczeństwo szlag trafi.

    Śmieszą mnie artykuły wszelkiej maści o wyższości 7zip nad RAR, czy GPG nad PGP podczas gdy zdecydowana większość czytelników takich artykułów nie ma pojęcia, jak korzystać z tych narzędzi w sposób właściwy (autorzy niestety bardzo rzadko poruszają ten temat, bo jest mało “medialny”).

    I jeszcze jedno. Sam fakt, że autorzy programu udostępniają kod nie daje ŻADNEJ gwarancji, że jest on bezpieczny, a wręcz daje fałszywe poczucie bezpieczeństwa.
    Czy ktoś z Was kiedykolwiek analizował od początku do końca wszystkie źródła OpenSSL, albo choćby takiego 7zip i jest pewien, że nie ma w nim celowych lub przypadkowych podatności? Im większy kod, tym łatwiej coś ukryć, FreeBSD to tylko jeden ze znanych przykładów.

    • +10

      A co do ostatniego akapitu – kod źródłowy kodem, a jaka gwarancja że binarka jest z nim 100% zgodna? Czasem własne kompilacje ze źródeł pokazują, że plik wynikowy lubi się różnić od tego gotowego do pobrania.

    • @monter: zgodność binarki to kluczowe pytanie,to bardzo zależy od tego jakim kompilatorem i nie tylko zrobiono tą appkę, z jakimi opcjami i konfiguracją to kompilowano itd.

      “I jeszcze jedno. Sam fakt, że autorzy programu udostępniają kod nie daje ŻADNEJ gwarancji, że jest on bezpieczny, a wręcz daje fałszywe poczucie bezpieczeństwa.”

      @AlAraf: Zgoda,ale program otwartoźródłowy łatwiej sprawdzić. Do binarek są niby też dekompilatory próbujące sprowadzić program do kodu w jakimś języku więc to nie jest tak,że koniecznie trzeba czytać to w assemblerze – ale i tak ten kod wynikowy jest mało czytelny.
      Co za tym idzie: Zamknięty kod => dłuższe szukanie dziury i w zasadzie niewielkie możliwości samodzielnej jej korekty ot tak (można edytować hexedytorem itd,ale to już zmiany w asm)

    • Opcja nr 2 przez gmail nie przejdzie, odrzuca on e-maile z załącznikami 7z z zaszyfrowanymi nazwami plików. Chciałem tak dzisiaj sobie exe przesłać i po kolejnej próbie, gdzie użyłem mojego niesłownikowego hasła i ponownym odrzuceniu załącznika zacząłem panikować, że hasło mi w jakiś sposób wyciekło i zasiliło bazę słownikową googla.

    • @AlAraf
      Otwarty kod źródłowy nie daje gwarancji braku złośliwych intencji autora, ale kod zamknięty daje gwarancję, że autor może sobie zrobić, co chce. Argumentacją taką mógłbyś równie dobrze uzasadnić likwidację wymiaru sprawiedliwości i organów ścigania, twierdząc, że przecież złodziej nawet przy ich obecności może coś ukraść.

      Weryfikacja oprogramowania nie działa na zasadzie przeczytania całego kodu przez użytkownika. Pomijając rozmiar programu: użytkownik zwykle nie ma wiedzy i doświadczenia, by przeprowadzić taką analizę, a do tego jest omylny.

      Weryfikacja open source opiera się na starej, dobrej regule wielu oczu patrzących, czy wszystko gra. Jedną osobę, choćby miała najlepsze intencje i kompetencje, można łatwo wykiwać. Tysięce osób, nawet jeśli sprawdziły tylko fragmenty kodu, bardzo trudno.

      Właśnie to — ogromna liczba weryfikujących — stanowi podstawę „gwarancji” bezpieczeństwa otwartych rozwiązań.

    • @mpan87: Twoja teza, że “kod zamknięty daje gwarancję, że autor może sobie zrobić, co chce” jest błędna.
      Sam fakt, że kod źródłowy jest powszechnie dostępny oznacza jedynie, że taką aplikację przeważnie można szybciej przeanalizować. Tyle, że współczesne aplikacje to już nie epoka MS-DOS, gdzie była konieczna dekompilacja do niskopoziomowego assemblera. Weź np. binarki powstałe w technologi .NET Framework, które są niemal czystym kodem źródłowym MSIL o czytelności niewiele ustępującej językom wyższego poziomu, który można poprawić i rekompilować.
      Cała trudność analizy programów polega nie na trudności ich dekomilacji z nawet obskuryfikowanej binarki, tylko na zrozumieniu tego co się widzi, a to wymaga specjalistycznej wiedzy, która kosztuje. Udostępnienie czy nie kodu źródłowego nie ma tu nic do rzeczy.
      To właśnie powszechny slogan, który sam powtarzasz, że: “skoro kody źródłowe są powszechnie dostępne, to na pewno już ktoś je zbadał i są bezpieczne” powoduje stworzenie fałszywego poczucia bezpieczeństwa. Takie stwierdzenie daje równie fałszywe poczucie bezpieczeństwa jak to, że ryzyko napadu rabunkowego na przechodnia jest mniejsze w środku miasta, gdzie kręci się dużo ludzi i “ktoś” na pewno zareguje. Szczególnie, gdy kod jest duży i co chwila powstaje kolejna nowa wersja, a ludzie nie nadążają nawet z wgraniem aktualizacji, nie wspominając już o analizie każdej kolejnej wersji. Najlepszym tego przykładem był wspomniany już przeze mnie FreeBSD. Dlaczego skoro tyle osób miało dostęp do źródeł FreeBSD, to wykryli problem dopiero przypadkiem po wielu latach. Bogata korporacja może pozwolić sobie na kosztowną analizę aplikacji i powszechna dostępność lub brak dostępności do źródeł będzie wtedy najmniejszym zmartwieniem. Czy myślisz, że jak wydadzą na taką analizę kupę swojej kasy, to podzielą się jej wynikami ze wszystkimi?
      “Argumentacją taką mógłbyś równie dobrze uzasadnić likwidację wymiaru sprawiedliwości i organów ścigania, twierdząc, że przecież złodziej nawet przy ich obecności może coś ukraść.” – a co ma piernik do wiatraka?

      Jeszcze słowo odnośnie GIODO. Wymienienie konkretnego programu, nawet jako przykładu, nie było najlepszym pomysłem, bo przeciętny Kowalski zrozumie to jako rekomendację dla takiej aplikacji, o czym mieliśmy sposobność przekonać się czytając niektóre “fachowe” artykuły. Jeżeli jakiś organ administracji publicznej rekomenduje dany program do powszechnego użytku, to powinien najpierw zlecić jego gruntowną analizą (np. przez CERT i uznaną zewnętrzną firmę specjalizującą się w takiej analizie, niekoniecznie oferującą najniższą cenę). Dlatego właśnie w USA po analizach zabronili stosowania w instytucjach rządowych urządzeń telekomunikacyjnych kilku chińskich firm, tak powszechnie używanych w naszym kraju ze względu na niską cenę. Parę lat temu nawet MSWiA dostało w “darze” od takiego chińskiego producenta sprzęt do wideokonferencji (ciekawe dla czego :)

      Jedynym bezpiecznym rozwiązaniem byłoby stworzenie własnej technologii (software i hardware) w oparciu o rodzimych, dobrze opłaconych specjalistów. Tak robią wszystkie normalne kraje, które nie są republiką bananową. Niestety, u nas do tej pory było to bardzo trudne, o czym dotkliwie przekonali się twórcy Sylan.

    • @Mirek zmien rozszerzenie. 7zip moze nie przejdzie ale piz przejdzie. 8piz powinien. txt przejdzie przeciez.

    • @mpan: Twoja teza, że “kod zamknięty daje gwarancję, że autor może sobie zrobić, co chce” jest błędna.
      Sam fakt, że kod źródłowy jest powszechnie dostępny oznacza jedynie, że taką aplikację przeważnie można szybciej przeanalizować. Tyle, że współczesne aplikacje to już nie epoka MS-DOS, gdzie była konieczna dekompilacja do niskopoziomowego assemblera. Weź np. binarki powstałe w technologi .NET Framework, które są niemal czystym kodem źródłowym MSIL o czytelności niewiele ustępującej językom wyższego poziomu, który można poprawić i rekompilować.
      Cała trudność analizy programów polega nie na trudności ich dekomilacji z nawet obskuryfikowanej binarki, tylko na zrozumieniu tego co się widzi, a to wymaga specjalistycznej wiedzy, która kosztuje. Udostępnienie czy nie kodu źródłowego nie ma tu nic do rzeczy.
      To właśnie powszechny slogan, który sam powtarzasz, że: “skoro kody źródłowe są powszechnie dostępne, to na pewno już ktoś je zbadał i są bezpieczne” powoduje stworzenie fałszywego poczucia bezpieczeństwa. Takie stwierdzenie daje równie fałszywe poczucie bezpieczeństwa jak to, że ryzyko napadu rabunkowego na przechodnia jest mniejsze w środku miasta, gdzie kręci się dużo ludzi i “ktoś” na pewno zareaguje. Szczególnie, gdy kod jest duży i co chwila powstaje kolejna nowa wersja, a ludzie nie nadążają nawet z wgraniem aktualizacji, nie wspominając już o analizie każdej kolejnej wersji. Najlepszym tego przykładem był wspomniany już przeze mnie FreeBSD. Dlaczego skoro tyle osób miało dostęp do źródeł FreeBSD, to wykryli problem dopiero przypadkiem po wielu latach. Bogata korporacja może pozwolić sobie na kosztowną analizę aplikacji i powszechna dostępność lub brak dostępności do źródeł będzie wtedy najmniejszym zmartwieniem. Czy myślisz, że jak wydadzą na taką analizę kupę swojej kasy, to podzielą się jej wynikami ze wszystkimi?
      “Argumentacją taką mógłbyś równie dobrze uzasadnić likwidację wymiaru sprawiedliwości i organów ścigania, twierdząc, że przecież złodziej nawet przy ich obecności może coś ukraść.” – a co ma piernik do wiatraka?

      Jeszcze słowo odnośnie GIODO. Wymienienie konkretnego programu, nawet jako przykładu, nie było najlepszym pomysłem, bo przeciętny Kowalski zrozumie to jako rekomendację dla takiej aplikacji, o czym mieliśmy sposobność przekonać się czytając niektóre “fachowe” artykuły. Jeżeli jakiś organ administracji publicznej rekomenduje dany program do powszechnego użytku, to powinien najpierw zlecić jego gruntowną analizą (np. przez CERT i uznaną zewnętrzną firmę specjalizującą się w takiej analizie, niekoniecznie oferującą najniższą cenę). Dlatego właśnie w USA po analizach zabronili stosowania w instytucjach rządowych urządzeń telekomunikacyjnych kilku chińskich firm, tak powszechnie używanych w naszym kraju ze względu na niską cenę. Parę lat temu nawet MSWiA dostało w “darze” od takiego chińskiego producenta sprzęt do wideokonferencji (ciekawe dla czego :)

      Jedynym bezpiecznym rozwiązaniem byłoby stworzenie własnej technologii (software i hardware) w oparciu o rodzimych, dobrze opłaconych specjalistów. Tak robią wszystkie normalne kraje, które nie są republiką bananową. Niestety, u nas do tej pory było to bardzo trudne, o czym dotkliwie przekonali się twórcy Sylan.

  13. Inna sprawa, że już nie raz spotkałem się z akcją, że owszem, załącznik zaszyfrowany a hasło otwartym tekstem w treści maila…

    Tak jak ktoś piszę – zabezpieczenie powinny być adekwatne to ważności.

  14. W firmie używamy DESlocka+. Jeśli ktoś nie ma licencji musi skorzystać z darmowego “readera” DESlocka by odczytać zawartość maila/załącznika. Poczta MSZ nie przepuszcza zaszyfrowanych plików 7z/zip/rar więc tylko *.dlp (plik DESlocka) przeszło ale samo MSZ nie ogarnęło drag&drop do okna “readera” więc kazali wysłać wzory podpisów i pieczęci bez szyfrowania bo “inne firmy wysyłają bez szyfrowania i jest okej” (to cytat z wiadomości mail od MSZ).

    Spotkałem się również z Urzędami, które korzystają z TrueCrypta.

  15. Czym jest GIODO ?

    • WyDuckDuckGoUj sobie :P

    • @Seba FYI lmddgtfy (dot) net

    • Kolegą po fachu Satoshi Nakamoto.

  16. Z tą tylko różnicą, ze niezależna powtarza tę wtopę za http://www.fakt.pl/wydarzenia/polityka/giodo-poleca-uzywanie-programu-7zip-od-rosyjskiego-informatyka/jgvzeg4 (data publikacji fucktu 6 kwi, 07:43, na niezależnej Dodano: 07.04.2017 [14:23])

  17. A co ze standardem szyfrowania poczty (S/MIME)?

    • Co z S/MIME… S/MIME ma podobny problem co PGP z wymianą kluczy, ale większego kalibru. W PGP dość łatwo można rozdzielić co jest kluczem publicznym i prywatnym i je łatwo i szybko do plików exportować. Przy S/MIME masz do czynienia z systemowym keystore (na windowsie) i/lub keystore w konkretnym toolu (np Thunderbird). Pilnowanie i przenoszenie/backupowanie tych kluczy pomiędzy swoimi maszynami jest uciążliwe (bo nie są prostymi plikami w ~/.gnupg & mój ulubiony issue na windowsie – user przywrócił swój własny klucz na nowej maszynie i przy imporcie oznaczył go jako nieexportowalny), do tego dochodzi export kluczy publicznych, czego userzy już kompletnie nie ogarniają (bo obok są inne certy/klucze, np światowych CA). Trudne też jest zaszyfrowanie na inny klucz niż adres mailowy adresata, oraz programy pocztowe kompletnie się gubią przy forwardowaniu zaszyfrowanych maili. Nie poruszam nawet tematu weryfikacji czy klucz jest zaufany (AFAIK nie ma modelu web of trust dla S/MIME), bo to temat na osobny rant.

      Jako tako S/MIME działa w obrębie 1 organizacji jak mają pełną infrastrukturę microsoftową, z ad, exchange i msowym CA do generowania kluczy. W dzikim internecie łatwiej użyć PGP.

  18. Opinia pana Kamila Kaczyńskiego w kontekście luk w 7-zip pokazuje, że nie ma on pojęcia o czym pisze. Gdyby poprzestał na tym, na czym się zna, byłby bardziej wiarygodny. Zacytowane CVE donoszą o podatności w obsłudze HFS i UDF, a to chyba nie to samo co archiwa 7z czy zip… Trzeci błąd to DoS/crash, gdzie tu zdalne wykonanie kodu?

    No ale laicy spoza IT kupią te brednie, bo brzmią mądrze…

    PS. Polecam zerknąć na “7-Zip with support for ZStandard Compression” który wspiera szybkie algorytmy kompresji: LZ4, LZ5, ZStandard.

  19. Gazeta Wolska przedrukowała te bzdury. O ja nie mogę…

  20. A ja powiem tak – dla szarego użytkownika lepiej jest zastosować PGP/GPG. Dlaczego? Ponieważ pomęczą się z instalacją (albo i nie, zależy jaki program pocztowy, na Thunderbirdzie da się to ogarnąć w 15-20 minut), ale potem tylko klikają “zaszyfruj” i idzie zaszyfrowane. A jak ma być 7zip i pakowanie pliku z hasłem to znając nasze realia 99% emaili będzie się zaczynało od “hasło do pliku to: u78%43dfc#’. I tego żaden AES nie przeskoczy.

    • S/MIME każdy słabo rozgarnięty klient poczty już ogarnia, łącznie z wbudowanym w W10 (ale z jakichś nie$wia$do$mych przyczyn tylko dla kont MS/Exchange) :)

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.