Nowe posty

xx Dystrybucja pod HP Omen (6)
2024-03-27, 23:30:08
xx [Poradnik] Wyszukiwanie Sterowników (2)
2024-03-27, 21:08:23
lamp Problem z Linux Lite po instalacji (0)
2024-03-27, 19:50:30
xx Ile pingwinów? (1)
2024-03-27, 08:59:24
xx konfiguracja pale moon (0)
2024-03-24, 21:53:42
xx Plasma 6 w Neonie ssie trochę mniej ... (10)
2024-03-23, 02:38:11
xx problem z instalacja sterowników do karty sieciowej (3)
2024-03-18, 18:10:16
xx Plik abc.001 (1)
2024-03-17, 17:48:27
xx Zlecę dopracowanie programu w MatLab (0)
2024-03-13, 15:28:40
xx Linux Mint 21.3 XFCE brak dźwieku po paru minutach (karta muzyczna zintegrowana) (5)
2024-03-12, 23:07:01

Autor Wątek: Backdoor'y FBI w stosie IPSEC.  (Przeczytany 4937 razy)

kamzor

  • Gość
Backdoor'y FBI w stosie IPSEC.
« dnia: 2010-12-19, 21:03:40 »
http://marc.info/?l=openbsd-tech&m=129236621626462&w=2
http://niebezpiecznik.pl/post/fbi-odpowiedzialne-za-backdoor-w-stosie-ipsec-openbsd/
http://www.chip.pl/news/wydarzenia/prawo-i-polityka/2010/12/fbi-implementowalo-backdoory-w-systemie-openbsd
http://www.hotfix.pl/fbi-zaplacilo-za-stworzenie-luk-w-systemie-openbsd-n4714.htm
http://thread.gmane.org/gmane.os.openbsd.tech/22557

No to nieźle. Co o tym myślicie?

Wygrzebałem ciekawy cytat ;)
Cytat: "Theo de Raadt"
Oh
right, let's hear some of that "many eyes" crap again.  My favorite
part of the "many eyes" argument is how few bugs were found by the two
eyes of Eric (the originator of the statement).  All the many eyes are
apparently attached to a lot of hands that type lots of words about
many eyes, and never actually audit code.

Offline

  • Users
  • Prawie jak Guru
  • ****
  • Wiadomości: 432
    • Zobacz profil
Backdoor'y FBI w stosie IPSEC.
« Odpowiedź #1 dnia: 2010-12-20, 09:49:22 »
Nie wiem, co o tym myśleć... chyba tego jeszcze nie potwierdzili? W każdym razie założę się, że w wiadomym systemie mają tego więcej...

kamzor

  • Gość
Backdoor'y FBI w stosie IPSEC.
« Odpowiedź #2 dnia: 2010-12-20, 12:43:13 »
Nie sądzę by mieli tego więcej, i nie sądzę by ten istniał. Nawet jeśli zamontowali go 10 lat temu to do tej pory kod przepisali praktycznie od nowa.

Offline roobal

  • Users
  • Guru
  • *****
  • Wiadomości: 2056
    • Zobacz profil
Backdoor'y FBI w stosie IPSEC.
« Odpowiedź #3 dnia: 2010-12-20, 14:33:32 »
Jeśli ktoś chciał ukryć jakiekolwiek backdoory, to prędzej zrobili to w kodzie binarnym, a z kodu źródłowego wszelkie furtki mogły zostać usunięte.

Pozdrawiam!

kamzor

  • Gość
Backdoor'y FBI w stosie IPSEC.
« Odpowiedź #4 dnia: 2010-12-23, 07:01:47 »
Chłopaki znaleźli już kilka bugów, w tym dwa w crypto ;-)

A dla ciekawskich:
Cytat: Theo de Raadt
At the moment my beliefs are somewhat along these lines:

    (a) NETSEC, as a company, was in that peculiar near-DC business
        of accepting contracts to do security and anti-security work
        from parts of the government.
    (b) For context: 1999-2001 was a period where lots of US govt
        departments pushed the boundaries, because crypto was moved
        from DOD to Commerce so that it could be exported "subject
        to some limits"; the result was that crypto use by private
   interests was set to explode, and thus many justifications, not
        just technologies, were being invented to let the US Govt
        continue wiretapping (they have always been addicted to it).
    (c) Gregory Perry did work at NETSEC, and interviewed and hired Jason
        just out of school; by the time Jason started working there
        Perry had been "evicted" from the company, for reasons unknown.
    (d) Jason did not work on cryptography specifically since he was
        mostly a device driver author, but did touch the ipsec layer
        because that layer does IPCOMP as well.  Meaning he touched the
        data-flow sides of this code, not the algorithms.
    (e) After Jason left, Angelos (who had been working on the ipsec stack
        already for 4 years or so, for he was the ARCHITECT and primary
        developer of the IPSEC stack) accepted a contract at NETSEC and
        (while travelling around the world) wrote the crypto layer that
        permits our ipsec stack to hand-off requests to the drivers that
        Jason worked on.  That crypto layer contained the half-assed
        insecure idea of half-IV that the US govt was pushing at that time.
        Soon after his contract was over this was ripped out.  Soon after
        this the CBC oracle problem became known as well in published
        papers, and ipsec/crypto moved towards random IV generation
        (probably not viable before this, since we had lacked a high-quality
        speedy PRNG... arc4random).  I do not believe that either of
        these two problems, or other problems not yet spotted, are a
        result of clear malice.  So far the issues we are digging up are
        a function of the time in history.
    (f) Both Jason and Angelos wrote much code in many areas that we all
        rely on.  Daily.  Outside the ipsec stack.  I forwarded the
        allegation which mentions them, but I will continue to find it
        hard to point my own fingers at them.  Go read my original mail
        for points (a) - (c).
    (g) I believe that NETSEC was probably contracted to write backdoors
        as alleged.
    (h) If those were written, I don't believe they made it into our
        tree.  They might have been deployed as their own product.
    (i) If such NETSEC projects exists, I don't know if Jason, Angelos or
        others knew or participated in such NETSEC projects.
    (j) If Jason and Angelos knew NETSEC was in that business, I wish
        they had told me.  The project and I might have adjusted ourself
        to the situation in some way; don't know exactly how.  With this
        view, I do not find Jason's mail to be fully transparent.
    (k) I am happy that people are taking the opportunity to audit an
        important part of the tree which many had assumed -- for far too
        long -- to be safe as it is.