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

 ( trey | 2010. december 15., szerda - 8:23 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

Amikor én utoljára OpenBSD default install-t láttam (évekkel ezelőtt), akkor gyakorlatilag semmi sem volt alapértelmezetten engedélyezve. Nem hinném, hogy ez azóta változott volna.

--
trey @ gépház

Kernel csak volt rajta, az pedig egy elég szép darab alkalmazás...


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

Az operációs rendszer és az alkalmazás fogalmát ne keverd össze.

Na meg itt "remote hole"-ról volt szó. Ha egy oprendszert távolról "meg lehet dönteni" hálózati szolgáltatások nélkül, akkor az már tényleg a legalja.

Az meg van, hogy az "only two remote holes in the default install"-ból az egyik remote hole pont a kernelben lévő IPv6 kódban volt, így tökéletesen mindegy, hogy milyen userland daemon végez vagy nem végez hálózati szolgáltatást?

Miért ne téveszthetné!?!

Három fajta megközelítés van az operációs rendszer meghatározása esetén. Az egyik éppen az, hogy csak a kernel az operációs rendszer.

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!

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.

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?!

+1

A linux kapott Darpa támogatást. Akkor abban nincs beépített backdoor vagy van csak Darpa saját backdoor-a van benne??
Nagyon szórakoztató, ahogy az amerikai katonai-rendfenntartó-titkosszolgálati szervek 'üldözik' egymást és keresztbe tesznek egymásnak. :-)

Akkor ezért volt 9/11 meg az egész....

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!

Lehet, hogy még csak nem derült ki...

+1

Tipp: valószínűleg pont amiatt, amit állít magáról: "OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there)."

--
A gyors gondolat többet ér, mint a gyors mozdulat.

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

Erre céloznak a threadben lévő további levelek egyikében is...


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

Ha jol tudom a firmwaret nem a CPU futtatja, hanem az adott device "processzoran" hajtodik vegre, aminek nem szabadna hogy szabadon hozzaferjen a gep memoriajahoz. Vagy a DMA ezt megengedi?

De a tudtod nelkul kuldhet masolotatot a halokartya.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A VPN-en menő titkosított adatokról. Azokról az internetszolgáltató is.

Sry, felrement

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

http://en.wikipedia.org/wiki/IOMMU
"Some units also provide memory protection from misbehaving devices." (Ezt az eszkoz is tratalmazhat gyarilag beepitett FBI/NSA/.. whatever backdoor-t)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ha le tudja korlátozni a host, hogy hova nyúlkálhat DMA-val az adott device processor, akkor egy fokkal jobb a helyzet (pl. virtualizált I/O).

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

ezek a hw-es rootkit dolgok elég ijesztőek. ki tudja, mit rejteget a vas?

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

a Cyrix még tiszta lehet :)))

Ki is szorították a piacról:D

ha nagyon túrok, találok a fiókban még néhányat, ami garantáltan backdoor-mentes :)

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?

A szövegkörnyezetet elnézve szerintem kérdőjelet akart a mondat végére :)

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

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

Meg kene tanulni kedves treznek forditani, neked meg olvasni a forrast;)
--
Peace, Love, Unity, Respect

Simán csak (nagyon) elcseszte a fordító...
"My NDA with the FBI has recently expired"

Javítva.

--
trey @ gépház

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

+1

Az SELinux pont nem valik gyanussa.

--
Fedora, RHEL, CentOS, virtualizáció, SELinux: http://sys-admin.hu

Az pont miért nem?


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

Mert még senki nem értette meg a működését. :)

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

Ezek szerint Földönkívüli backdoor van benne.
:-)

Asgard kód.
Nem backdoor van benne, hanem (back)stargate...

:DDD

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Gondolom amiatt, h az a hirhedt debian openssl maintainer sem kaphatott egy zsiros csekket azert a kikommentezett sorert. :)

---
pontscho / fresh!mindworkz

Na egen, a problema az, hogy nehez ezeket bizonyitani, egyszerubb ugyeknel az is kerdeses lehet, hogy typo, vagy valoban backdoor-t akart vki csinalni. Persze nyilvan egy "kevesbe feltuno" megoldas bonyolultabb, azt meg azert nehezebb is "veletlenul" elkovetni ...

Nem is kell bizonyítani. Az illető megbízhatósága szempontjából tök mindegy, hogy gonosz vagy éppen csak hülye mint a segg. Innentől kezdve nem lehet megbízni egyik munkájában sem.

Nem mind1, mert szerintem olyan ember nincs aki _SOHA_ nem teved. Nem hinnem, hogy letezik olyan progarmozo a vilagon, aki nem vetett meg hibat, legyen az typo vagy mas jellegu. Megis mas kicsit a helyzet, ha az egy "szandekos" hiba, vagy hivjuk inkabb backdoor-nak ...

Nem hinnem, hogy letezik olyan progarmozo a vilagon, aki nem vetett meg hibat

Már hogyne lenne... Úgy hívják, hogy "nobody actually creates perfect code the first time around, except me" Linus Torvalds :D

kinek mi a hiba ugye..

Akkor Linus ott kovette el a hibat, hogy nem kovette el :) vagy mi van ... Bar ez vegulis lenyegtelen, itt - szerintem valoszinusithetoen - nem olyan jellegu backdoor-rol van szo, ami egy typo jellegu hibaval is osszetevesztheto.

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

Az SELinux az önmagában mér eleve gyanús...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

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.

Nem értem. Egy (szoftveres) titkosítás mitől központosítja a hatalmat?

úgy, hogy idővel talán egyre nehezebben érthető, ill. nagyobb kutatást igényel a hiba felfedezése vagy beépítése, ezért a nagyobb hatalom hamarabb és többet tud kutatni.

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.

... Debian ...

--
Don't be an Ubuntard!

Én inkább ezt linkeltem volna, sokkal relevánsabb. Melyik idióta használna exim-et egy 'háborús szerveren'?? :-)
" ...Hozzáteszem értő kezekben(!!)... "
Nyilván nem script-zolika default telepítése az, ami kibír egy ilyen támadássorozatot.

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.

Jó de az nem 5 napos hír...

--
Don't be an Ubuntard!

"Egy rossz megoldás is jobb a semminél."

öö nem. semmilyen megoldásnál nem vagy abban a tudatban, hogy az adataid biztonságban vannak, így nem is bízol rá olyat, ami bizalmas (kivéve, ha teljesen hülye vagy).

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.

látom, nem sikerült értelmezni a post-omat. persze nem vagyok meglepve.

Ezt most éppen rád érvényes.

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

"Melyik "script kiddy" fér így hozzá a folyamhoz?"

Ha az a T-Home konkretan kabeles (DOCSIS) szolgaltatas, akkor pl. az, amelyik a szomszedban lakik. :)

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

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

"Ebből a nemzetközi (főleg amcsi) titkosszolgálatok mostani "stress-test-je alatt csak a mediawiki hullott ki."

Honnan tudod? :)

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

Egymás fölött kell amerikai és kínai biztonsági réteget használni, csak nincs olyan backdoor, amihez mindkét kormánynak hozzáférése van. :)

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 kérdés inkább az, hogy van-e szükség backdoorra egyáltalán a mai bugos szoftvereknél ;)

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.

"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

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

LOL

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

Igen!
TurulBSD-t a magyar népnek!

Belga FTW! :D

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

amihez a vezérlőszoftvert a másik céged szállítja :-)

mondjuk ha csak az érdekeltségeket nézzük, akkor érdemes úgy összeválogatni a kritikus hardvereket, hogy aki ellen védekezni akarsz, annak érdekeltségi köréből még véletlenül se vásárolj és akkor talán van esélyed :D

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.

+1, és oda igen nehezen ügyeskednek be mindenféle imperialista backdoor-t a kis kíváncsiak :)

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?

Köszönöm!

> - ha ez egy nyílt forrású rendszer, akkor 10 évig miért nem vette észre senki, hogy büdös a torta?

Fogalmazd át szak(mai) nyelvezetűre a kérdésedet, és akkor majd fogsz tudni válaszolni magadnak.

"Avagy hogyan mentegessuk a manyeyeballs dogmat mielott teljesen arcat nem veszti." :)

---
pontscho / fresh!mindworkz

Akkor fogalmazd át te a kérdést.

Szerintem erre Neked lenne szukseged.

---
pontscho / fresh!mindworkz

A rossz fogalmazás megzavarja a felületes (nem)gondolkodókat. Mint ahogy a kérdés feltevőjét is megzavarta.

zenboriz "Utam a megvilágosodás felé" - Megrendelhető hamarosan az alexandra online-on!

:)


No rainbow, no sugar

Aha. Csak nem csapja felre a szemellenzod egy pillanatra sem. :)

---
pontscho / fresh!mindworkz

Nekem mindegy, akkor maradjunk annyiban, hogy büdös a BSD torta.

Inkabb a "manyeyeballs mindent eszrevesz" mantra.

---
pontscho / fresh!mindworkz

Jó választás. :-)

Birom benned, h mindig szandekosan ugy erted felre a postokat, h ugy gondold, h neked van igazad akkor is mikor abszolute nincs. Felelmetesen tudsz terelni es mellebeszelni. :-)

---
pontscho / fresh!mindworkz

Aki B-t ír amikor C-t gondol, az magát hibáztassa.

Csodálatos könyv lesz. :)


No rainbow, no sugar

Régi cikk de részben releváns a témában: http://www.wired.com/software/coolapps/news/2004/12/66022

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.

1. Felgorget az oldal tetejere
2. Vastaggal szedett szoveget elolvas
3. Rajon, hogy ez a cikk cime
4. Elvonul a sarokba gondolkodni.
5. Rajon, hogy nem tud olvasni.

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

Látom, te sem vagy képes rendesen megfogalmazni.

Nem, te nem akarod erteni, es minket csesztetsz. Inkabb vonulj el a sarokba hallgatni. Remelem ez eleg ertheto volt.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

lol, indulatos báránybégetés

nem kellett volna átszerkeszteni. közben rájöttél, hogy nem ő pofázott bele ok nélkül, hanem te? :)

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

ne foglalkozz vele, csak fröcsög.

> Bekerült egy "hiba" a kódba 10 évvel ezelőtt.

Ezt honnan veszed?

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.

> Viszont ismerd el, hogy Te magad is ugyanebbe a hibába estél,

Elismerem, én is kommunikálhattam volna jobban.

Rendben, részemről lezárva :)

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

nem is mondom, hogy bugmentes. A bug itt amúgy is idézőjeles kifejezés volt :)

szerk.: kíváncsian várom az eredményt a sok szem elemzése után :) Most tényleg megmutathatja a közösség, hogy értik a dolgukat.

A sec.hole és a backdoor fejlesztői szemmel egy natúr bug. Csak a felhasználóknál van különbség.

igen, végül is hiba, hiszen nem az elvárt viselkedést eredményezi.

a slashdoton volt egy jo komment, most nem keresem ki. a lenyeg, hogy Mr. Manyeyeballs lehet, hogy nagyon jol tudna auditalni a kodok 99.99% -at, ha odafigyelne, de hogy a crypto kod az nem ilyen, az tuti. normalis crypto kodhoz egy matek PhD nemart. :)

ráadásul nem csak ott szerintem.

Butaság. A "több szem többet lát" a bonyolult dolgokra ugyanúgy igaz, mint az egyszerűkre. Legfeljebb az arányok lesznek mások.

te mirol beszelsz?

a tobb szem sosem veszi eszre, ha en keyt leakelek paddingbe, mert egyszeruen nem tudja eldonteni, hogy most a key alapjan kell paddinget generalnom, mert ettol jo az algoritmus, vagy leakelek.

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.

a padding egy pelda volt. ezer millio modszerrel lehet informaciot leakelni, szerintem.

> a padding egy pelda volt. ezer millio modszerrel lehet informaciot leakelni, szerintem.

Bőven elég ha egyet említesz. Egy olyat, ami nem feltűnő.

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/BadPaddingException.html

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

ez epp egy pelda volt, hogy akar oda is lehet rejteni.

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.

LOL.

az implementációban nincs algoritmus? a hossz az mióta arányos a bonyolultsággal? stb?

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.

ha ilyen triviális példákat veszel, azokat valóban egyszerű megérteni, igen. a rossz hír az, hogy a valós életben nem csak triviális dolgok vannak.

Viszont a jó hír, hogy a szimmetrikus titkosító algoritmusok többnyire ilyenek. Ha bonyolult lebegőpontos számítások kellenének, akkor egyszerűen lassúak lennének a mai processzorokon.

ki beszélt lebegőpontosságról? ennek semmi köze ahhoz, hogy egy spec és egy implementáció kombóról kicsikét se egyszerű eldönteni, hogy ekvivalens-e.

Ebben nem fogunk egyetérteni, szerintem relative egyszerű, ennyi. Akár egy masszív stressz-tesztel is, összevetve más implementációkkal.

Ha az algoritmus erősségét kéne matematikai bizonyítani, ahhoz nekem talán egy élet kevés lenne, az más kérdés.

tök jó, hogy neked ez ilyen egyszerű. az openbsd code audit-tal kész vagy már?

Nem vagyok érdekelt + szerintem kizárt, hogy itt van backdoor. A többi 30.000 sor auditjára pedig nem mondtam hogy egyszerű.

javits ki ha tevedek, siman lehet, de az asszimetrikus esetek azert ennel bonyibbak :)

lebegopontos cuccok meg nem kellenek, mai napig a primfaktorizacio nehezsegere epul a biznic.

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? ;)

A kiskapu itt van, nem a diff-ben. :D
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Sajnos csak volt. Ez már csak a szelleme.

azokert a Javas forditasokert annyira nem kar...

Első HUP-os helyes megfejtőnk: Arilius. Ezúton is gratulálok neki. :)

Nem HUP-os megfejtő: ggergely, aki azóta már csak mreyeball néven szólítható... :P

Mindkettőjük megkapta a Certified FBI Cyber Agent's Backdoor Hunter Expert kitüntető címet. :D

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? :)

nem ;)

eheh
http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-allegations.html

egyébként ez elég komoly vád, imho nem kéne ennek ilyenkor az http://www.openbsd.org/ fő oldalon megjelennie hogy izé vizsgálódunk mert szitu van...


No rainbow, no sugar

A főoldalon nincsenek hírek

a security-announce listán pedig 2010-12-14 21:18:27 kor kint volt.
Az eredeti üzenettel együtt.

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

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

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

Mennyivel drámaibb lett volna a Wikileaks-en keresztül nyilvánosságra hozni.

A kérdés az, hogy ez csak "véletlen" vagy ügyes időzítés.. elég sok minden van itt porondon, akár a Wikileaks-re, akár a Koreai problémára gondolunk.

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

Itt milyen covert channelt lehet csinalni szerinted? Mi van ha megsem olyan random lesz az a szam...
"Fogok némi random számot (legtöbb titkosításnál kell)"

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

akkor mar a paddingbe inkabb, a headerek altalaban nagyon fixek, nem ertem, oda hogy szeretnel elbujtatni barmit is :-)

:P Mondom nem területem az ilyesmi.
De csak bele lehet dugdosni valahova.
Mondjuk az ESP header-be. a Security Paramter Index egyik bitjére. vagy a Sequence number megmókolásával.

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

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)

a NetBSD -s implementaciot mar fel eve rendbe kene rakni... :)

Jovo evi GSOC? :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

meg akar az is lehet. de szerintem egy user-friendly installer lesz az. most karacsonykor meg beolvasztom a http bootot, csak azzal nagyon vigyazni kell... :-)

\o/

Szerintem az installer most is egesz user-friendly, elso komolyabb BSD telepiteskent secc-pecc alatt megertettem a logikajat.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

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

Humppa :)

Ez eszembe juttatta, hogy annó 2003-ban valaki megpróbált észrevétlenül backdoort rakni a Linux kernelbe. Akkor, ott működött a many eyes, pedig a hiba mindössze egy karakterből állt (C-beli '=' és '==' közötti különbség).

Vagy egy tegnapi hir egy ujabb backdoor-rol. Csupa sikersztori ez a het. :|

---
pontscho / fresh!mindworkz

és a legjobb, hogy egyik esetben sem manyeyeballs fedezte fel a backdoort :)

de nem is a lényeg :)

> és a legjobb, hogy egyik esetben sem manyeyeballs fedezte fel a backdoort :)

Hanem?

Egy szoftverben találhat hibát a fejlesztője, a felhasználója vagy bárki más == manyeyeballs.

Gondoltam hogy te egyedül nem fogod érteni, ezért csak számodra átfogalmazom:

nem egy random közösségi tag találta meg, hanem egy ezért fizetett szakértő.

> nem egy random közösségi tag találta meg, hanem egy ezért fizetett szakértő.

Arra gondolsz, hogy a "manyeyeballs" jelentése: "random közösségi tag"?

Hova kéne sorolni a "fizetett szakértőket"? A fejlesztők közé, mert ezek tulajdonképpen alvállalkozók?

direkt ertetlenkedsz, vagy tenyleg ennyire nehez a felfogasod?

Gondoltam megszorongatom kicsit, mert fogalom nélkül "manyeyeballs"-ozik :-)))

Persze te is kifejtheted, hogy kit kéne besorolni a "manyeyeballs" alá, és kit nem; ha már ennyire tudod hogy én nem értem. :-)))

omg

Gyertek csak, gyertek csak, szép magyar vitézek!

[ http://www.youtube.com/watch?v=aHXgDoCW55A :-))) ]

fogyatekos vagy?

--
NetBSD - Simplicity is prerequisite for reliability

Mert röhögök az agyatlan trollokon? :-)))

+1

én is, de hol a többi? csak egyet látok ;)

vak vagy?
("fogyatékos vagy" kategória)

jöttél megvédeni apukádat? :)

:DDD

lül

Esetleg tudok ajánlani jó optikust. Ja, ezen lehet hogy ő se segít.

epic

-

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

Persze sokkal kevésbé lehetnének sztárok, ha a nyílt forrású projektek rendesen kezelnék a biztonsági hibákat és mindegyikről lenne alapból normális bejelentés és nem csak egy apró fejlesztői megjegyzés a CVS, git vagy akármi logjában, hogy ilyet javítottak csendben.

+1.
Biztonsági szakemberek legalábbis nálunk Magyarországon általában az egyetemi oktatásból kiesett programozókból lettek.

LOL, ezt meg honnan vetted? Soroljál már fel akkor néhány ilyen előadót a hazai itsec konferenciákról. :)

Úgy érted, manyeyeballs vonatkozik mindenkire, akinek legalább 2 szeme van?

--
Don't be an Ubuntard!