Újabb X biztonsági hibákat fedezett fel Ilja van Sprundel

 ( trey | 2014. május 13., kedd - 20:24 )

Alan Coopersmith ma bejelentette, hogy az IOActive-os Ilja van Sprundel (korábbi cikkünk) segítségével az X.Org security team több libXfont library-vel kapcsolatos súlyos biztonsági problémát is javított. A bejelentésben az olvasható, hogy az X.Org csapat úgy hiszi, hogy a sebezhetőségek a nevezett library összes korábbi verzióját érintik. A library az X11R5-ben mutatkozott be 1991-ben.

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

manyeyeballs! :)

Igen. Ilja egy a many közül.

nem
_____________________________
Powered by 1,3,7-trimetilxantin

Kivéve, ha félszemű.
--
Fight / For The Freedom / Fighting With Steel

Es azonos a sajat szemlabdajaval.

és ha a szorgos méhecskeként bugokat kereső FLOSS kommuna egy tagja
_____________________________
Powered by 1,3,7-trimetilxantin

de

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Most azon akadunk fel, hogy fizetést kap érte?

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Akkor ezentúl úgy ideologizáljuk meg, hogy a manyeyeballs fizetésért találja meg a biztonsági hibákat? Mert akkor lám ez a zárt forrású szoftvereknél is pontosan ugyanígy van... :))

Hja, kivéve, hogy zárt forrású szoftvereknél nehezebb nézni a forrást. És általában zárt forrású projectek nem adják oda a forrást puszira harmadik félnek még auditra sem...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Valami zavar van az erőben. Nem puszira adják oda a forrást, hanem auditálásra, ezért hívják forráskód auditálásnak. Azt hiszed Ilja van Sprundel és a többi biztonsági szakértő csak nyílt forráskódú szoftvereket auditálnak?!

Szerintem az a nem mindegy, hogy zárt forrás esetén csak akkor tud az auditáló cég auditálni, ha a forrás tulajdonosa kéri. Nyílt forrásnál viszont akárki, akinek ez fontos. Jelen esetben pl gondolom nem a Linux Fundation fizeti az auditot...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

> És általában zárt forrású projectek nem adják oda a forrást puszira harmadik félnek még auditra sem...

Puszira valóban nem.

Fúúú amúgy olyan helyen dolgozom (mondjuk nem ebben az üzletágban), ahol ezek a cégek fizetnek (!) nekünk, hogy a zárt (!) forrású szoftverüket odaadhassák auditra!

szerk: Lazán kapcsolódik - nyílt forráskódú projekt szerintem kb. sosem, vagy max egy-két esetben járt nálunk. Kíváncsi lennék, hogy melyik a hatékonyabb:
- manyeyeballs
- egy független, szakértői audit, amibe beletartozik az, hogy a kész terméket odaadjuk a ruszki etikus hacker csapatnak, akik eljátszanak vele, és a végeredmény egy elég részletes audit report a szoftver biztonsági réseiről, tervezési hiányosságairól, vagy ami éppen az ügyfelet érdekli

Most azon túlmenően, hogy ezek a cégek nyilván megélnek belőle (lám te se haltál éhen, mert ugye úgy nem tudnál itt kommentelni) mégis mennyire általános ez a fentebb kifejtett gyakorlat? Szóval a zárt forráskódú szoftverek hány százalékát ellenőrzik ezek a komoly cégek? Csak mert - szigorúan elvi alapon - a nyílt forráskódúak esetén 100% a manyeyballs *lehetősége*, ezzel szemben a zártaknál:
- vagy nem 100%,
- vagy ha 100%, akkor iszonyat szarul dolgoznak a pénzért a szakértők és az etikus orosz hekkerek (már a zárt szoftverekben előforduló hibák megjelenő száma alapján)

Vagy valamit nem értek.

Nyilván nem 100% a lefedettség. Valószínűleg közelebb van a nullához, mint a százhoz. Sőt, azt sem állítom, hogy ez valami csodaszer lenne: a sebezhetőségek nagy részét ki lehet szűrni, és el lehet juttatni arra a szintre a szoftvert, hogy már ne legyen triviális megtörni, de biztos védelmet ez sem ad.

Inkább az a baj az auditokkal, hogy nagyobb projekteknél nem kifejezetten olcsó. :) Mondjuk nagyobb projekteknél a manyeyeballs sem annyira működik, hiszen kb. tűt kell keresni egymillió szénakazalban, úgy, hogy nem tudod, hogy néz ki egy tű. Azaz rá lehet ugyan hibázni néha, de ettől nem lesz biztonságos a cucc.

Tulajdonképpen igen.

Ha magamra hívok egy auditort, és az talál valamit, azt nem a közösség találta, mert ahogy eggyel feljebb is írták, ezt megteheti megteszi a Microsoft is, vagy a többi "közellenség".

Érdekes, ezen most nem megy a pörgés, hogy milyen szar, tákhalom az X11, amikor bezzeg a Windowsban volt hasonló jellegű, akkor ment a hupákolás fénysebességgel! :)

Talán mert mindenki tudja, hogy az X11 "szar, tákhalom", és senki nem állította vehemensen az ellenkezőjét.
Nem viccből fejlesztik a Wayland-et...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Dehogynem, itt rendszeresen olvasni olyan véleményeket, miszerint a Linux, mint desktop megbízhatóbb, biztonságosabb, és stabilabb, mint a kereskedelmi OS-ek, mindenféle okok miatt.

A Wayland fejlesztésének szükségességéről nem lehet vitázni, ami viszont biztos az az, hogy annak a kódját sem fogják csak úgy átnézegetni a manyeyeballék, lesznek szép, friss bugok a régiek helyett.

Dehogynem, itt rendszeresen olvasni olyan véleményeket, miszerint a Linux, mint desktop megbízhatóbb, biztonságosabb, és stabilabb, mint a kereskedelmi OS-ek, mindenféle okok miatt.

Gyorsan jött is egy cikk rá, hogy alá legyen támasztva! :))

Hú, ebből a gyöngyszemből kimaradtam. :)

Viszont a lényeget is leírja:
"Linuxon kevesebb malware-t lát. Hogy ennek mi az oka, az nem érdekli." :DDD Jajj, még mindig nincs korrekt, technikai magyarázat, csak bugok, secholeok hosszú sorokban, minden áldott nap... :)

mélykonzol a megoldás!

Ja, aminek a kódjához tegnap volt local root exploit! :)

http://hup.hu/cikkek/20140513/cve-2014-0196_linux_kernel

Tegnap lett volna május 6-a? Fedorán akkor javították, azóta nem érint.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Láttam :)

Rohaggyon meg, nem mén (sled11).