Az FBI fejlesztőket fizetett azért, hogy azok hátsó kapukat építsenek az OpenBSD crypto keretrendszerébe?

Titkosítás, biztonság, privát szféra

Theo de Raadt, az OpenBSD projekt vezetője, egy érdekes levelet kapott a minap. Egy bizonyos Gregory Perry küldte neki a levelet, akivel Theo és az OpenBSD csapat több mint 10 évvel ezelőtt kapcsolatban állt. Perry annak a NETSEC-nek volt akkoriban a műszaki igazgatója, aki támogatásokat intézett az OpenBSD Crypto Framework (OCF) fejlesztéséhez. Abban az időben Perry az FBI-jal is kapcsolatban állt konzulensi minőségben. Az FBI "GSA Technical Support Center" divíziójával összefüggően adott tanácsokat. Ez a csoport Perry szerint egy crypto reverse engineering projekt volt, amely azzal a céllal működött, hogy hátsó kapukat (backdoor) építsen smart card és más hardver-alapú biztonsági eszközökbe.

Perry szerint az FBI-jal kötött titoktartási megállapodásának (NDA) időtartama nemrég lejárt, így figyelmeztetni akarja Theo-t, hogy az FBI több backdoor-t és adatszivárogtatást lehetővé tevő mechanizmust építtetett bele az OpenBSD Crypto Framework-be azzal a kifejezett céllal, hogy monitorozni tudja az EOUSA által implementált site-to-site VPN titkosítási rendszert.

Perry szerint Jason Wright és több más fejlesztő felelős ezen backdoor-ok implementálásáért. Perry azt javasolta Theo-nak, hogy vizsgáljanak felül minden Wright és a NETSEC-kel kapcsolatban állt fejlesztő által commit-olt kódot.

Perry azt is közölte Theo-val, hogy feltehetően ennek volt köszönhető az is, hogy elbukta annak idején a DARPA támogatást. Perry szerint a DARPA több mint valószínű, hogy megneszelte, ezek a backdoor-ok benne vannak az OCF-ben, így nem kellett neki az OpenBSD.

Perry szerint ez lehet az oka annak is, hogy néhány FBI közeli tag mostanában elkezdte azt nyomni, hogy virtuális környezetekben használjanak az emberek OpenBSD VPN-t és tűzfalazást. Perry szerint ilyen például a virtualizációs körökben elismert szerző, Scott Lowe is, aki rajta van az FBI bérlistáján és aki újabban több tutorial-t is készített arról, hogy hogyan használjunk OpenBSD virtuális gépeket vállalati VMware vSphere telepítésekben.

Theo de Raadt úgy érezte, hogy publikálnia kell a levelet, ezért elküldte az OpenBSD security-announce levelezési listájára. Megemlíti, hogy állítások történtek arra nézve, hogy néhány ex-OpenBSD fejlesztő (és a cég, amelynek dolgoztak) pénzt fogadott el az USA kormányától annak érdekében, hogy backdoor-t építsenek az OpenBSD hálózati rétegébe, pontosabban az IPSEC stack-be.

Mivel az OpenBSD IPSEC stack volt az első szabadon elérhető IPSEC stack, számos projektben és termékben fellelhető a kód jelentős része. Mivel az elmúlt 10 évben az OpenBSD IPSEC kódja jelentős változtatásokon esett át, Theo számára nem világos, hogy milyen (ki)hatása lehet a Perry által közölt állításoknak.

Theo de Raadt levele - benne Gregory Perry állításaival - itt. Az openbsd-tech listán diskurzus indult a témában itt.

( asm v | 2010. 12. 15., sze – 08:33 )

Ebbol vajon hany "remote hole" szarmazhat a default installban?

( dejo v | 2010. 12. 15., sze – 08:40 )

Ha valakinek üldözési mániája van, attól még lehet hogy tényleg üldözik.
Amíg a nemzetbiztonság, védelmi hivatal, stb. használja, addig nincs is ezzel gond. De sajnos ezeket a hivatalokat gyakran a politika felügyeli és irányítja.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba és kész!

( s3r3nity | 2010. 12. 15., sze – 08:48 )

Gondold el azokat a változóneveket ... :))
$REMOTE_HOLE0
$DOOR_FOR_FBI0

etc ... :))
--
When your mind is empty of prejudices you can see the Tao.
When your heart is empty of desires you can follow the Tao.

( ishida | 2010. 12. 15., sze – 08:54 )

Ez van amikor a teremtmény túlnő a mesterén. Gondolom most jó sokan ráuszulnak a kódra, hogy megtalálják, hogy valóban igaz-e a hír. Ha igen, akkor viszont Theo ideológiája alapjaiban rendül meg szvsz.

Theo konkrétan melyik ideológiája? A bináris blobok elleni? A nyílt forráskódé? Azé, hogy legalább egy picit próbált tenni azért, hogy szabadon (minden értelemben, lásd USA vs. Kanada) felhasználható eszközöket gyártsanak?
Alapjaiban inkább a céges/kormányzati/stb. hozzájárulásokkal kapcsolatban kell megrendülnie a bizalomnak, ez pedig még csak nem is az OpenBSD-ben a legnagyobb probléma, hanem...

suckIT szopás minden nap! WTF, FBI-backdoor az OpenBSD crypto frameworkben?!

( dejo v | 2010. 12. 15., sze – 08:58 )

Miért pont az OpenBSD-t szúrták ki e célra? A Többi BSD érintetlen a dologban. És a Linux, vagy a Windows, a MacOS? A mobil rendszerek?
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba és kész!

Várjuk ki, hogy igaz-e egyáltalán ez az egész. Majd ha az OpenBSD hivatalosan bejelenti, hogy valóban van alapja ennek az állításnak, akkor el lehet majd gondolkodni azon, hogy melyik OS-t nem sikerült az FBI-nak és a többi hivatalnak vagy titokban, vagy a gyártó/fejlesztő tudtával backdoor-oznia. Addig is egy kódaudit nem árt a nyílt forrású projekteknél.

Bár ha jobban belegondolok, újabban már nem is az OS gyártókat kellene megkörnyékeznie ezeknek a hivataloknak. Sokkal egyszerűbb lenne a hardvergyártókat megkennie.

--
trey @ gépház

Ez jutott eszembe 2005-ből.

"Firewire/1394 host adapters which comply to the OHCI specification
allow remote devices to initiate direct DMA based memory access to the
host computers main memory. This access takes place completely without
involvement of the operating system on the host computer.

[...]

This access can be used to read arbitrary memory from a system connected
via FireWire and also to modify arbitrary memory contents. Applications
of this capability include capture of screen
contents, modification of screen contents, induced system crashes,
escalation of process privileges and disabling of password queries."

Akkor ez problémát jelentett. Nem követettem, hogy tettek-e a gyártók valami az ellen, hogy ne lehessen így hozzáférni a gépek memóriához.

Ha most, ha a gyártó közreműködésével akarnak csinálni valami hasonló disznóságot, akkor akár működhet is. Persze ez csak tipp.

--
trey @ gépház

"Bár ha jobban belegondolok, újabban már nem is az OS gyártókat kellene megkörnyékeznie ezeknek a hivataloknak. Sokkal egyszerűbb lenne a hardvergyártókat megkennie."

Konkretan 2 db hardvergyartot: Intel, AMD.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Miért pont az OpenBSD-t szúrták ki e célra?

Pl. azért amit Theo is írt a levelében, hogy OpenBSD-ben volt először szabad IPSEC implementáció, így nagy valószínűséggel használhatták más projektek is referenciaként.

A Többi BSD érintetlen a dologban.

Ezt te mi alapján feltételezed?

Ez esetben a valasz egyertelmu nem. Mind a Net, mind a FreeBSD eleg sok OpenBSD kodot vett at, igy valoszinuleg ok is erintettek. Amiert az OpenBSD-t kornyekezte meg a srac, a mogott talan az is lehet, hogy ez a gyokerprojekt, mint ahogy tobben ramutattak. Ha itt megvannak a sechole-k, akkor a tobbi BSD is aggodhat, ha itt nincsenek meg, kar a tobbi BSD-t belengetni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( joco01 v | 2010. 12. 15., sze – 09:52 )

Ha csak hamarosan jár le, miért most szólt? 10 évet kibírt, de 2 héttel a lejárat előtt megszegi? WTF?

--
joco voltam szevasz

( Pontscho | 2010. 12. 15., sze – 10:27 )

Es ezek utan nem valik automatikusan gyanussa a selinux vagy a huawei (amit amugyis kinai frontend cegnek tartanak sokan) hozzajarulasa a dolgokhoz? :| Vagy azok a pletykak miszerint a google-hoz hozzaferese van adott kormanyszerveknek. Nagyon nem orulok ennek a hirnek, mert a vonzatai nagyon ronda kepet festenek le.

---
pontscho / fresh!mindworkz

Azert tevedes es tevedes kozott is van kulonbseg. Nem mindegy, hogy a hegynek vezeted a repulot, vagy a hegytol el. (mielott a trolltarsadalom kotozkodni kezdene: a pelda illusztralni szeretne, hogy a felelosseg merteke nagyban belejatszik a tevedes megiteleseben. Egy repulogep vezetese (hasonloan az openssl kodjanak maintainelesehez) igen nagy felelosseg, es jol meg kell gondolni minden lepest).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Megint felmerül a kérdés, hogy ki ellen akarunk titkosítani.

Egyrészt ha ezek komoly fenyegetést jelentenek a személyes szabadságunkra nézve és tarthatunk tőle hogy olyanok kezébe kerül nagyobb hatalom ez által, aki vagy akiknek nem szeretnénk, akkor az ez ellen való fellépést nem forrás kód auditálással kell kezdeni imho, hanem támogatni az olyan szervezeteket és demonstrációkat, amelyek célja a privát szféránk védelme.

Részemről elgondolkodtató, hogy ha egyre jobban elkezdünk titkosítani mindent minél alacsonyabb szoftver rétegektől kezdve, akkor a kizárólagos hatalom egyre jobban monopolizálódik és egyre jobban tolódik kevesebbek kezébe. Kérdés hogy ez jobb-e? Mert azért hiszem hogy ha egyre bonyolultabb a technológia, és a megértése, továbbfejlesztése vagy innovációja egyre nagyobb szellemi és anyagi tőkét kíván, akkor a szoftver is megint csak a még gazdagabbak felé hajtja az információ által hordozott hasznot és hatalmat.

Persze minden másnál is ez a helyzet, csak most a szoftver szemszögéből nézve kérdezem, hogy jót fog-e hozni az egyre szélesebb körű titkosítás? Az eddigi jobban elosztott torta nem tartott-e valamivel jobb / rosszabb egyensúlyt? Melyik jobb nekünk átlag embereknek? A hatalom központosítása, vagy felosztása? A központosított hatalomnál hihető-e hogy a nagyobb és erősebb tesó majd jobban meg tudja védeni a kicsiket? Ha igen akkor nem jobb a backdoor az állam részéről?

"Megint felmerül a kérdés, hogy ki ellen akarunk titkosítani."

Te is rsh-t használsz a szervereken bejelentkezésre, vagy már áttértél a telnet-re?

"Melyik jobb nekünk átlag embereknek? A hatalom központosítása, vagy felosztása?"

... hetenként mindig más gyakorolja a végrehajtó hatalmat.
De csak azok a döntések jogerősek, amelyet a kéthetente összeülő különleges bizottság...

A "ki ellen titkosítást" úgy értem, hogy persze használjuk a lehetőségeink adta maximális védelmet, de ezen felül van-e értelme törekedni állami méretű hatalom ellenében megpróbálni titkosítással védekezni, amikor egyrészről meg van a hatalmuk ennek megkerülésével is elérni minket, másrészről meg abban sem lehetünk biztosak, hogy a kifejlesztett technológiának nem találtak-e már régen gyenge pontját, meg éppen a hatalmuk miatt több és jobb fejlesztőt és tudóst alkalmazhatnak.

Szerintem alapvetően ez téves logika. Egy rossz megoldás is jobb a semminél.
Egyébként a wikileaks ügy jól teszteli az alatta levő infrastruktúra biztonságát: Debian, nginx, Apache, Freenet, Tor, PGP, Mediawiki. Ebből a nemzetközi (főleg amcsi) titkosszolgálatok mostani "stress-test-je alatt csak a mediawiki hullott ki. Tehát paranoia-logikával is Assange és az egész Wikileaks egy CIA megtévesztő akció része, vagy ezek a rendszerek valóban megbízhatónak tekinthetőek. Hozzáteszem értő kezekben(!!) az kritikus kódrészek személyes ellenőrzése és újrafordítása és a szerverek megfelelő "elrendezése" mellett.

Epp elegge ki lett targyalva az, h miert nem erdemes egy eso utan koponyeg tipusu akcioval szorakozni mikor gyakorlatilag ennek megtortente inkabb megerositi az emberekben azt, h a kiszivargott infok valosak es erdemes rajuk figyelni. Az emberek 99%-a magasrol leszarja a wikileaks mukodeset mert nem ertik vagy nem erdeklik. Es azok utan, h az eddig biztonsagosnak hitt openbsd-be beletolt a szerv egy ilyen backdoort (ha igazak a hirek) siman jelentheti azt, h a tobbiben is vagy talalt, vagy elhelyezett egyet-kettot. Sajnos ilyenrol hazai peldat is ismerek, mindenkinek megvan az ara. Egy debian/nginx/akarmi szoftverben is bosegesen van hely eldugni ilyesmit. Plane mint koztudott, h a tor halozat is kompromitalva van mindenfele cegek altal.

---
pontscho / fresh!mindworkz

Néha maga a wikileaks team is figyeli a tor-t: One of the WikiLeaks activists owned a server that was being used as a node for the Tor network. Millions of secret transmissions passed through it. The activist noticed that hackers from China were using the network to gather foreign governments’ information, and began to record this traffic.

Mindezek ellenére a tor is Sokkal több, mint a közvetlen ráadásul titkosítatlan adatkapcsolat. A cablegate ügy kiszivárogtatója, a forrás ezerszer fontosabb szereplő ebben az ügyben mint maga Assange. Mégsem sikerült a mai napig beazonosítani. Sőt Amerikai szervek nem is kommunikálják, hogy keresik 'hajtóvadászatot folytatnak ellene' mert jól tudják valószínűleg soha nem találják meg és akkor az egészből csak újabb újabb arcvesztés lenne a végén.
Nem létezik olyan, hogy 100% biztonság, pláne nem az digitális kommunikáció világában. De ettől még lényeges különbségek vannak az egyes technológiák között és a 'lebukás' esélyénél ezek nagyságrendi eltéréseket jelentenek.

Semmilyen titkosítás esetén ki vagy téve a script-kiddie hülye gyerekek támadásának is. Ellenük még egy rossz titkosítás is általában védelmet jelent.
Régen amikor még csak nagyon kevesen titkosítottak még felmerült az a dilemma, hogy például titkosított adatforgalommal "megjelölöd" magad, mint 'valamit csináló valaki'. Ma amikor már tömegek torrenteznek, pletyka-chatelnek, titkosított csatornákon, ez a veszély már nem fenyeget. A titkosítás hiánya viszont egyértelműen jelentősen növeli a kockázatot. Bízni pedig semmilyen technológiában sem lehet.
Annyiban igazad van, hogy a mindenféle technikai eszközt elvből elutasító Osama Bin Laden a mai napig szívatja a világot, a legszuperebb high-tech-el sem tudnak a nyomára bukkanni.

Most direkt megnéztem, hogy milyen úton megy a TCP csomag a BME-s szerveremig. Én a T-Home-nál vagyok ügyfél, a szerver az EIK-ban van. Onnan, hogy a lakásból kiment a jel, csak a T-Home/T-online, HBONE és a BME hálózatán ment át csomag, manage-elt switch-eken és router-eken, gyakorlatilag csak a gerinchálózaton. Melyik "script kiddy" fér így hozzá a folyamhoz? Ha normális szolgáltatónál vagy, akkor akár telnet-ezhetsz is, senki nem fogja lehallgatni a folyamodat. IMHO.

Azért használok SSH-t, mert néha használok nyílt wifi-t is és nem ellenőrzöm mindenhol a hálózatot. De otthonról simán elég lenne akár a telnet is.
--
http://www.naszta.hu

Azért az NBH, mint "script kiddy", vicces. :)

De ilyenkor mindig látom magam előtt, hogy a napi cirka 20 perc, text alapú kapcsolatot az NBH véletlenszerűen ellenőriz az 50 GBps-os folyamból... már ha nem direkt rám vadásznak. Persze. :) Ha meg rám állnak valamiért, annak oka van. De akkor én sem telnet-tel bohóckodnék, nyilván. Ha meg alaptalan, hogy rám áltak, akkor gyorsabban végeznének, ha telnet-ezem. :)
--
http://www.naszta.hu

Volt már arra példa, hogy a nemzetbiztonság lehallgató berendezésének "szolgáltatásait" külsős arcok is igénybe vették magánhasználatra. Az ő gépükön sem törhetetlen ultimate-os fut.
De egyébként lehallgatható az ethernet kábel, a wep vagy wpa1 wifi kapcsolat, az egyetemek falain belül pedig gombamód szaporodnak a 'vicces' és unatkozó rendszergazdák. A telnet-el pedig csak óvatosan egy évtizede az L&R-t is annak a segítségével nyomták fel. Használ még valaki Elender internetet? :-)

Nem kell meggyőzni engem, SSH van, mert nem akarok erre (sem) figyelni. :)

Szerintem sok helyen túlzásba viszik a biztonsággal kapcsolatos köröket, vagy még jobban fogalmazva: nem jó helyekre súlyoznak, összpontosítanak. Nyilván vannak olyan helyek, ahol nem lehetsz elég óvatos az adatforgalommal kapcsolatban sem (kollégiumi ethernet, nyílt wifi stb.), de én sokkal jobban odafigyelek ma arra (normális szervertermekkel), hogy a nyitott szolgáltatások verzióiban minimális legyen az exploit esélye. Az én környezetemben - jelenleg - a lehallgatás és az ezzel való visszaélés esélye minimális, miközben például az Apache-ot, az SSH-t vagy éppen az SMTP-t folyamatosan érik támadások.

Külön gyöngyszem, hogy nem egy webhost szolgáltató SSL-lel titkosítva üzemelteti az admin felületét, de az admin oldalnak nincs cert-je és az Apache meg lukas, mint az ementáli. (Mindezt egy olyan teremből, ahol csak a Gb-es felágon találkozik csak a többi gép forgalmával az adatfolyam, tehát a lehallgatás esélye csekély.)
--
http://www.naszta.hu

Hat, attol fugg. Peldaul egy self-signed SSL tanusitvany ugye nem a legjobb megoldas, megis titkositas, tehat a jelszavad adott esetben nem nyilszovegkent fut a halon, vagyis ha valaki melletted elenged egy tcpdump/wireshark-ot, akkor sem lathatja kozvetlenul a jelszavadat, hanem kuzdenie kell vele (sokat).
Igy ertelmezve az "egy rossz megoldas is jobb a semminel" mondatot az egesz mas megvilagitasba kerul.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Az komolyan bárkit meglep, hogy a Google-hoz, Facebook-hoz, satöbbihez hozzáférése van az (amerikai) kormányszerveknek?

Mint tudjuk, itt, Magyarországon is minden nagyobb telco/IT cégnél van egy államszerv által pénzelt alvó ügynök, aki bizonyos telefonhívásra minden tudásával (hozzáférésével) rendelkezésre áll, ez a nemzetbiztonság. Az viszont, hogy mi nemzetbiztonsági érdek, erősen függ az épp aktuális hatalomtól, illetve a korrupciótól. Szóval ha nálunk így mennek a dolgok, akkor Amerikában, a terror elleni harc kaptárában méginkább.

A kérdés itt csak az, hogy a nyílt forrású szoftverekbe be tudták-e juttatni a backdoort, minden más nyilvánvaló.

A magyar nemzetbiztonság annyira ostoba volt, hogy minden piti ügyre 'aktiválta' ezeket a forrásait. Így ma már a kezdő script-kiddie-k, anarchisták és amatőr net-forradalmárok is nagy ívben elkerülik a magyar szolgáltatásokat. Sőt még az egyszeri net-ezők is. Lehet írogatni leveleket az amerikai irattároknak.

( uid_16313 | 2010. 12. 15., sze – 10:30 )

"Only two remote holes in the default install, in a heck of a long time!"

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

( lipilee | 2010. 12. 15., sze – 10:46 )

remélem nem valósítottak meg emlékezetcsorgást ezek a magbetyárok a hátsó kapuk építése közben!

--
speak no evil - lipilee.hu

( Maxim | 2010. 12. 15., sze – 11:23 )

Ezek után:

"Állok a pusztában, gatyám lobog.
Seggem kilóg, gyomrom korog.
Nézek a magosba, gondolok nagyot!
Magyar égre magyar csillagot!
Nyugati szél fú, délibáb ragyog.
Magyar vagyok, szittya vagyok!
Nem vágyok sokra, de egyet akarok:
Magyar nemzeti BSD-t!
Magyar nemzeti BSD-t!
Magyar nemzeti BSD-t!
Magyar nemzeti BSD-t!"
:-D

( ang | 2010. 12. 15., sze – 13:08 )

szerintem az operacios rendszer szintu hole-k meg rendben vannak. valahol...

de ki garantalja, hogy hardverbe (firmware) meg ilyesmik nincs beepitve (gyarilag) valami hasonlo genyasag? ez ellen eleg nehez vedekezni, kiveve ha van sajat gyartosorod...

Ismered a mondást: Ami nem kínai az nem is igazi.
Szóval a múltkori Dell szervereket érintő problem is jelzi, hogy az amcsiknál (is) nem csak gazdasági, de nemzetbiztonsági problémákat is felvet, hogy (legalábbis papíron) egy ellenséges országban gyárt(at)ják a legfontosabb technológiáikat.

( Dacr (nem ellenőrzött) | 2010. 12. 15., sze – 16:37 )

Nya most nem azért a két fillérért, de (hozzáteszem, nem vagyok BSD tudor, így nem biztos, hogy minden feltételezésem helytálló):

- ha ez egy nyílt forrású rendszer, akkor 10 évig miért nem vette észre senki, hogy büdös a torta?
- ha észrevette, akkor meg lett kenve?
- ezek után felmerül a kérdés: az OpenBSD élén állók vajon tiszták az ügyben?

Szerintem eleg szakmai nyelven tette fel a kerdest. A "tobb szem tobbet lat" effektus ugye csak akkor mukodik, ha az a tobb szem eppen jo helyre nez. Mennel nagyobb egy kod, annal kisebb az eselye, hogy egy parsoros backdoor/bug kibukik, foleg akkor, ha jol el van rejtve. Senki nem fog egy (jonak latszo) fuggvenyhivast beture lekovetni, ha az epp az o problemajaval nem fugg ossze.

Neha en is nekifutok ketszer egy commentnek, de sikerul megertenem, mit akar a masik mondani.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

> Szerintem eleg szakmai nyelven tette fel a kerdest.

OK, akkor te nyilván meg tudod mondani, hogy a szakmaiság elvárásainak eleget tevő pontossággal _mit_ "nem vett észre senki 10 évig?" Mer ez a "büdös torta" ez csak arra jó hogy nyelvtanilag befoltozza a szövegben lévő hiányt.

No picit az asszonnyal foglalkozok, máris elszabadul a pokol, mint látom a szálat :D

Megpróbálom átfogalmazni a kedvedért, bár fentebb kaptam választ, bár szerintem azon linkelt fórumrészlet sem mutat mást, mint hogy biztonság fellegvára sem teljesen az, aminek hirdeti magát.

Tehát az átfogalmazás:
adott egy nyílt forráskódú rendszer (eddig szakmai?). Az elmélet szerint több száz, vagy ezer külsős programozó dolgozik rajta. Legtöbbjük debugol, nem fejleszt. Bekerült egy "hiba" a kódba 10 évvel ezelőtt. 10 évig úgy fejlesztette tovább mindenki, hogy nem tűnt fel. 10 év! Nem 4-6 hónapos "bug"-ról beszélünk! Hogyan lehetséges ez?
Továbbmegyek: gyakorlatilag bárki adhat hozzá commitot úgy, hogy a kutya nem nézi át, mit hákolt bele (jajj, a hákol szó nem szakmai, bocsánat!).

Most úgy őszintén! Mi a fenét lehetne ezen szakmaibban megfogalmazni, mint hogy sz*rt sem ér ezek szerint a sokat hangoztatott reklámszövegük? Elnézést, ha nem volt érthető megjegyzésem, szakmaiasítom neked:

büdös a torta == kódot fertőz

Te elolvastad a cikket??? Olvasd már el még egyszer lassan és tagoltan. Hátha leesik, miről szól...

Segítek:
Perry és az OpenBSD fejlesztők 10 éve kapcsolatban álltak. Feladatuk volt a háttérben, titokbana backdoor beépítése úgy, hogy lehetőleg ne tűnjön fel. Tehát a szövegértelmezés szabályai szerint ha 10 évvel ezelőtt álltak kapcsolatban, akkor 10 éve történt az ominózus kódbeültetés.

Ez így már vili? Vagy van még valami, amit nem értesz?
De nagyon szívesen venném, ha Te is leírnád a véleményed, mert eddig csak visszakérdeztél, és (ahogy fentebb írták) fröcsögtél. Van _szakmai_ véleményed (ha már tőlem is ezt várod)?

Namégegyszer: honnan veszed, hogy a "több backdoor és adatszivárogtatást lehetővé tevő mechanizmus" ténylegesen be lett építve?

Mert ha sehonnan, akkor ezt ki kéne fejezned a mondanivalód megfogalmazásában. Ha meg biztos vagy benne, akkor fröcsögd elő a bizonyítékokat.

Személyeskedj tovább nyugodtan, nem zavar.

No végre, eljutottunk idáig is! Igazad van, mondattani problémát vétettem, miszerint nem tettem feltételes módba mondanivalómat (mit kapok ezért kisbetu-től). Viszont ismerd el, hogy Te magad is ugyanebbe a hibába estél, mert nem a problémás részre világítottál rá egyértelműen, csupán párszavas kérdéseket tettél fel.
Igen, hibásan fogalmaztam meg mondanivaló, ezt belátom. S természetesen ezért elnézésedet is kérem.

Úgy lehetséges, hogy ez a szoftver meglehetősen bonyolult. Ha valami nem okoz galibát, akkor keveset foglalkoznak vele. Nem ez lenne az első eset, hogy egy galibat nem okozó bug éveken át fennmarad és nem is az utolsó.

A OSS értékéből ez semmit nem von le. Aki azt hitte, hogy a nyílt szoftverek bugmentesek, az valszeg még nem használt számítógépet. :) A manyeyeballs most lép akcióba, működik, ahogy meg van írva.

Ha kiderül, hogy melyk kódrészletről van szó, akkor lehet szakmai vitát folytatni az esetről.

Addig nem, amíg nem olvassák el az RFC-t, hogy hogy kell paddingelni. De vannak olyanok, akik elolvasták, ha nem lennének, akkor ma nem lenne pl IPsec Linuxba.

manyeyeballs alatt nem a világ összes programozója értendő beleértve az indiaiakat, hanem azok, akik érdekeltek és specializálódtak a témában. Ők is vannak, nem kevesen. Ha a programozóknak mondjuk a 0.01% -a mozdul erre, már akkor nyert ügy.

amit mar fent is irtak: a randomgeneralo kod milyensege. azon all, vagy bukik az egesz. crypto szempontbol veletlent generalni nem trivialis szoftverbol.

userland fele eszembe jutott mar modszer, de itt most halozati sniff eseten szeretnenk visszafejteni, ott meg csak a csomagok jatszanak.
HA a padding adott, a header adott, akkor:
- csak a payloadba lehet elrejteni (ha megjosolhato X minta alapjan az egesz, akar statisztikailag)
- ha enged a protokoll opcionalis header-elemeket, akkor azoknak az implementaciojaba

hova lehet meg?

> a tobb szem sosem veszi eszre, ha en keyt leakelek paddingbe,

Nekem az is elég jó, ha a fogadó oldalon futó kód veszi észre:

http://download.oracle.com/javase/1.4.2/docs/api/javax/crypto/BadPaddin…

"This exception is thrown when a particular padding mechanism is expected for the input data but the data is not padded properly."

A crypto kód nem olyan bonyolult, mivel azok csak az algoritmusok implementációi, ami sokkal könyebben megérthető mint az algoritmus maga, amihez valóban nem árt egy PhD. Az implementációk többnyire rövidebbek mint 200 kódsor. Itt pedig az implementációban rejthették el a backdoort, nem magába az algoritmusban vagy méginkább az "általános" kódban, amiből az IPsec kapcsán van mondjuk 30.000.

Ha le van írva, hogy fogj két bájtot és xor -old el őket, akkor az implementátor fogja és megteszi, akár anélkül, hogy értené a matematikai bizonyítását annak, hogy az úgy miért biztonságos, mégis tökéletes lesz az implementáció.

200 sor is lehet bonyolult, de az mégsem ugyanaz mint 20.000 bonyolult kódsor.

Igaz, de széles körben ismert, hogy hogy kell implementálni egy RSA-t vagy DSA-t, nem kevés project megcsinálta már. Egyszerűen nem hiszem el, hogy abba el tudnák rejteni a backdoort, ha mégis, akkor sem kell rakétatudós a lebuktatáshoz, mert ezek az algoritmusok jól ismertek.

Sokkal triviálisabb valami klasszikus nem crypto kódba elrejteni valamit, amit aztán pl egy injektált pakettel aktiválódik és kileakeli (pl paddingban) az aktuális kulcsokat vagy ilyesmi. Ehhez se rakétatudós kell, csak sok sok idő.

Az a baj, hogy ezt mindenki ugy kepzeli el, hogy van egy leak_crypto_key(datafd, key) fuggveny, es ezt konnyu megtalalni. A valosag azert ennel bonyolultabb szokott lenni. Nem veletlen, hogy a viruskodokat sem Mr. Manyeyeball, hanem jol felkeszult szakembercsapat elemzi.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

széles körben ismert, hogy hogy kell implementálni egy RSA-t vagy DSA-t, nem kevés project megcsinálta már. Egyszerűen nem hiszem el, hogy abba el tudnák rejteni a backdoort

Nem is kell és nem is érdemes. Minek rakjon az ember kiskaput egy adott crypto kódba, amikor egyszerűbb a véletlenszám-generátort elrontani annyira, hogy alacsony legyen az entrópiája - ezáltal triviálissá téve a kriptoanalízist -, így minden rng-alapú védelem támadhatóvá válik, nem csak az az egy implementáció.

Na, megtalálod a linkelt diffben a kiskaput? ;)

Ez így igaz és ez a kód bizony kemény dió, mert nem egy "sima" implementáció, inkább improvizáció! :)

Mondjuk az rng-be se triviális backdoorozni, mert az rng generátorba -gondolom- nem commitolhat minden "jöttment", meg kell indokolni a változtatást, az alrendszer karbantartója többnyire azért leauditálja, stb. Új kóddal sokkal könyebb lenyeletni a békát, ott nem kell indokolni és nehezebb auditálni is (több kód). Nekem továbbra is az lenne gyanús, ami nem gyanús, a "mezei" kód.

Amúgy ez az? :)

( sbela | 2010. 12. 15., sze – 17:54 )

Nem lehet hogy fejlesztőket/tesztelőket akar így szerezni az OBSD-nek ? Ravasz ez a Teo.

( 4fonya | 2010. 12. 15., sze – 19:18 )

Azt hiszem hogy ezek után Gregory Perry nem fog sokáig élni. :-(

( nikin v | 2010. 12. 15., sze – 22:40 )

Ezt én nem értem.. de majd valaki remélem felvilágosít

Ugye vannak titkosítási algoritmusok. Ezeknek a működése jellemzően matematikailag
levezetett. Amikor egy ilyet valaki beépít egy titkosító szoftverbe, akkor annak is megvan a menete.
Legegyszerűbb forgatókönyv szerint így néz ki:
-A fogom az adatot. és x mennyiséget betöltök a memóriába.
-Fogok némi random számot (legtöbb titkosításnál kell)
-Fogom a kulcsot, ill. annak valamilyen módosított változatát. És az algoritmus használatával titkosítom az adatot. Ekkor van egy új adatom ami a raw titkosított forma.
Egészen eddig a szoftveren belül maradok. A hálókártya mit sem tud erről. Ha nem valamilyen hardveresen támogatott titkosítást használok akkor a rendszer többi részegysége sem. Azok csak "matekoznak".
-Az így létrejött adatot előkészítem (titkosítástól független tevékenység) és beletolom a csőbe a hálókártyának, hogy HUSS.
Amikor a kártya először látja az adatot, akkor már titkosítva van. Tehát az én logikám szerint ha maga az algoritmus nem tartalmaz backdoor-t akkor akárhány helyre is küldi el a kártya a csomagot. Minden fogadó fél szembesül a titkosítással. És ha feltételezzük hogy az algoritmus és az implementáció tiszta, akkor csak az ismeri meg az üzenetünk tartalmát, akinek birtokában van a kulcs.

Ugye ha csak az FBI nem tanult meg k gyorsan faktorálni integereket. Akkor az egyetlen út, hogy valahogy kisunnyogja a kód a kulcsot.
Na mármost a kulcs ebben az esetben ugye egy változóban van benne. Szélesebb nézőpontból egy memóriacímen csücsül.
Ahhoz, hogy leakelhető legyen a kulcs. valakinek, valahol valamikor
A) Ki kell olvasnia adatot a megadott memóriacímről.
B) Ki kell adnia a memóriacímet egy másik program részére aki megkerüli a memóriavédelmet és kiolvassa azt onnan. DMA?
Az A) esetben ugye elvben a kulcshoz csak magának a titkosító eljárásnak, és a bekérő eljárásnak van köze.
Egy egyszerűbb RSA implementáció C++ ban kevesebb mint 200 sor. És egy ismert, jól leírt matematikai feladatot hajt végre. (viszonylag könnyen auditálható).
Ha bárki más hozzányúl az adott címhez, na az gond. És avval komolyan foglalkozni kell.
Mindkét esetben igaz, hogy amire figyelni kell az annak a változónak a viszontagságos élete, amiben a kulcsot tároljuk.
Illetve fontos lehet megfigyelni még bármilyen kifelé menő kommunikációt. IPC, IO.
Továbbá a kulcsfájl életét. (aszimmetrikus titkosítás (RSA pl.) esetén nem játszik... ill mégis mivel az általában csak a kommunikáció előkészítésénél használatos. utána azon keresztül megegyeznek egy szimmetrikus kulcsban. Ami ha fájlként nem is de a memóriában ott van, és az adat evvel kerül titkosításra. Továbbá fogadó félként itt is van kulcsfájl)

Ez lehet ugye egy audit célja.

Példának okáért feltesszük az OS-t egy olyan gépre, ahol minden memória-hozzáférés naplózható (paraszt megoldásként egy olyan virtuális gép ami memória helyett is csak diszket használ. Ott az írás olvasás tutira megfigyelhető)

Kicsit más.

Logikailag érthető, hogy olyan intézmények akiknek a feladata, hogy mindenről tudjanak, megpróbálják ezt ellátni. De a backdoor-okkal jellemző probléma, hogy előbb-utóbb nem csak az használja őket aki berakta őket.

Amennyiben paranoid nézőpontból közelítünk egy ilyen problémához, úgy az egyetlen járható út az egyszerűség. Olyan alkalmazásokat kell készíteni aminek minden rétege ugye jól elkülönül egymástól. És csak egy adott API-n keresztül kommunikálnak. Továbbá az adatok áramlása nyomonkövethető. Egy ilyen rendszer természetesen komoly teljesítménybeli hátrányokkal küzdhet. De ez a biztonság ára.
Adott esetben saját hardware-t kell építeni. Pl egy olyan eszközt ami USB-re dugva működik. Azon az elven, hogy amit az egyik portba beleböfögök. az a másikon egy mondjuk SD kártyán / lyukszalagon tárolt kulccsal titkosítódva jön vissza. Ha az algoritmus bizonyítottan nem érzékeny a known plain text típusú támadásokra akkor máris megvagyunk. Egy ilyen eszköz OpenSource megvalósítása valószínűleg nem is lenne vészesen drága. és mivel egy megfigyelhető interfészen keresztül kommunikál csupán. így egy referencia eszközzel validálva máris garantáltan leak mentes.
Ennek az eszközben egyszerűnek kell lennie mint a satu. Nem tudhat semmi többet mint amit muszáj. Az alap feladaton kívül csak három dolga van.
1: logoljon minden tranzakciót.
2: legyen benne valamilyen strict self check
3: Amikor csinál valamit akkor ezt kommunikálja a user felé.
Na kb. ennyi. Várom a javításokat, ilyesmiket. El lehet engem küldeni jó messzire :P

### ()__))____________)~~~ ################
#"Ha én veletek, ki ellenetek?"#N210/Xubu

Gőzöm sincs.... nincs semmilyen kalapom :)
De ha a rendszerbe van beleturkálva, akkor a memória szabad préda nem?
direktbe talán azt tudom elképzelni, hogy a csomag valami más részébe (header?) tolja bele a keyt. Akár bitenként. És akkor n db egymásutáni csomag kell a kulcshoz.

Akkor a Random generáló kód van megbizgetve... de szerintem ott még feltűnőbb lenne.

Az OpenBSD szerint a következőkre vagyon használva random ebben a kontextusban:

* random padding in IPsec esp_old packets.
* To generate salts for the various password algorithms.

IPsec-ben ezek vannak:
* HMAC-SHA1 for integrity protection and authenticity.
* TripleDES-CBC for confidentiality
* AES-CBC for confidentiality.

### ()__))____________)~~~ ################
#"Ha én veletek, ki ellenetek?"#N210/Xubu

( ssikiss | 2010. 12. 16., cs – 00:04 )

Remélem volt annyira "ronda" ez a bizonyos kód, hogy a KAME projekt/netbsdsek átírták, mielőtt (3x) beolvasztották volna. :D
(it doesn't work unless it's right)

( pinyo_villany | 2010. 12. 16., cs – 10:32 )


HISTORY
     The original IPsec implementation appeared in the WIDE/KAME IPv6/IPsec
     stack.

     For FreeBSD 5.0 a fully locked IPsec implementation called fast_ipsec was
     brought in.  The protocols drew heavily on the OpenBSD implementation of
     the IPsec protocols.  The policy management code was derived from the
     KAME implementation found in their IPsec protocols.  The fast_ipsec
     implementation lacked ip6(4) support but made use of the crypto(4) sub-
     system.

     For FreeBSD 7.0 ip6(4) support was added to fast_ipsec.  After this the
     old KAME IPsec implementation was dropped and fast_ipsec became what now
     is the only IPsec implementation in FreeBSD.

___
info

Hogy ki Manyeyeballs? Újabban azt hiszem, hogy azok a szerencsétlen "biztonsági szakértők", akik szemkigúvadva lesik a nyílt forrású projektek CVS, git vagy akármi logjait, azért, hogy lássák, hogy éppen mit javítottak ki a fejlesztők. Majd ha találnak valami érdekeset, akkor arra írnak egy exploit-ot és telekürtölik a világot azzal, hogy mekkora sztárok. Persze sokkal nagyobb sztárok lennének, ha a hibát ők maguk találták volna meg, de ahhoz kevesek, mint árvaházban a szülői értekezlet. Azt hiszem, hogy ez a manyeyeballs újabban. :)

--
trey @ gépház