"22 éves sebezhetőséget foltoztak be az X Window Systemben"

X, Wayland, Mir

"Régóta megbúvó, jogosultságkiterjesztésre lehetőséget adó biztonsági hibát foltozott be az X.Org. Az X Window System túlcsordulásos sebezhetőségén keresztül korlátlan hozzáférés szerezhető a megtámadott rendszerhez. [...] A projekt weboldalán olvasható információk szerint a hibát már az 1991-ben kiadott RCS 1.1 verzió is tartalmazza, és azóta minden X11 szerverben megtalálható, az X11R5-től kezdve a libXfont 1.4.6-os verziójáig."

A teljes cikk itt olvasható.

Nem volt meg (jelzem ez a HWSW cikkéből se derül ki, csak az angolból), mindazonáltal én ezt a tényt nem érzem a fenti sejtés cáfolatának. Ha jól veszem ki, most is csupán egy céleszköz segítségével találtak rá egy rakat ilyen jellegű hibára, ez az eszköz viszont bizonyára nem létezett az elmúlt 22 évben.

Szerintem ez pont olyan, mint hogy manapság is találnak II. világháborús bombákat, pedig 45 után bizonyára mindent elkövettek annak érdekében, hogy összeszedjék őket.

Aztán persze lehet, hogy csak tudatlan vagyok. És boldog. :-)

---
Science for fun...

Semmiféle céleszközről nincs szó, csak egy whitehatről, aki vette a fáradtságot és közismert programozási hibákat kezdett el keresni az X kódjában, amiről eddig is lehetett tudni, hogy katasztrófális, de most megmutatta, hogy még annál is rosszabb, mint amilyennek kinéz (ez lett az alcíme az előadásának is végül btw, mivel több száz hibát talált, pedig a tizedét se nézte át a teljes kódbázisnak).

Abban hinni, hogy más ezt nem tette meg korábban, őrületes nagy naívság. Világháborús bombákat is ásnak ki és tartanak titokban egyes emberek, ha már a béna hasonlatnál akarunk maradni.

Elvileg igen, gyakorlatilag talán, de inkább nem.
Ilyen, és ehhez hasonló appokban ilyen jellegű hibát kevesen keresnek forráskód alapján.
Ha ez valami hálózatos, távolról kihasználható exploit lenne, akkor nagyobb esélye lenne annak, hogy forráskód szinten hamarabb kiderülhessenek gyengeségek, mint használat közben.
--
PtY - www.onlinedemo.hu

Egy nyílt forráskódú rendszer nem fog a hátunk mögött, a tudtunk nélkül információkat szivárogtatni. Mivel a forráskódja nyílt, sok-sok hozzáértő észrevenné, és kiszúrná ezeket, mint ahogyan a sérülékenységek kapcsán ezt meg is teszik.Még 22 évesekkel is!!4!44!(m_g)[...]És sokkal megynugtatóbb úgy élni, hogy mindennek tudatában van az ember, és ennek megfelelően ésszerűen cselekedik, mint sem homokba dugott fejjel létezve, és majd jól meglepődve azon, hogy átvertek...Így van, linugzra nem kell vírusirtó!!44!!(m_g)©Pty

:)

Ha értelmezed a leírtakat, akkor talán kiderül a Számodra is (persze mindez csak kikapcsolt troll-mód mellett), hogy itt szándékosan a kódba épített szivárogtatásról esik szó, nem arról, amikor programozási vagy fordítási hiba miatt marad benne sérülékenység.

A két dolgot ne mosd össze, mert feliratkozol a troll listára - bár a felkiáltójel-használatod alapján már ott lenne a helyed rég.
--
PtY - www.onlinedemo.hu

Hogy lehet egy hasonlatot fordítva értelmezni?
Meséld el, mi az az eszköz a zárt forrású bináris elemzésére, ami a nyílt forrású bináris esetén nem használható (nincs ilyen, de ha van, elárulod).
Majd mondd meg, hogy nyílt forrás esetén milyen lehetőségek vannak, ami zárt forrásnál nem áll a rendelkezésedre (a forráskód mindenképp).
Vesd össze a kettőt.
--
PtY - www.onlinedemo.hu

Meséld el, mi az az eszköz a zárt forrású bináris elemzésére, ami a nyílt forrású bináris esetén nem használható

És ilyen eszközről mégis ki beszélt? Mert én biztosan nem: "A legtöbb fémdetektor szénabálával (= zárt forrás) ___is___ működik.". Csak annyit mondtam, hogy ha az egyetlen elemzési módszer a forráskódolvasás, akkor 22 év lesz egy sechole-t találni. Az IT-ben pedig a 22 év és a "soha" majdnem szinonimák.

Senki sem beszélt arról, hogy mi az egyetlen detektálási módszer.
Az állítás annyi volt, hogy nyílt forrás esetén több lehetőség van az ilyenek észrevételére, mert ott a forráskód.
Ezt cáfold érvekkel, ne olyan módszerek említésével, amik OSS esetén is használhatóak.
--
PtY - www.onlinedemo.hu

Erre annyit mondanék, hogy az ilyen típusú (buffer, stack overflow, inicializáltlan pointer dereferencing stb) alacsonyszintű hibák nem biztos, hogy lényegesen jobban látszanak C forrásban, mint assemblyben. Aki képes asm-et olvasni (mert mondjuk napi szinten ezzel foglalkozik), az kiszúrja ezt ott is.

Vannak persze olyan fajta hibák is, ahol sok munka az asm kódot visszakövetni annyira, hogy ugyanolyan jól látszódjon, mintha az eredeti forráskódot néznéd. Viszont a decompiling-ra is elég komoly toolkészlet áll rendelkezésre, amivel elég kulturáltan lehet vizualizálni assembly kódot is.
---
Régóta vágyok én, az androidok mezonkincsére már!

Oh wait! Szóval a Nyílt Forráskódú Rendszerek szándékosan nem "szivárogtatnak", csak véletlenül (és honnan tudod, hogy egy hiba most véletlenül van benn, vagy egy szofisztikált szándékos backdoor része?). Hát, ez is valami. Ha pedig értelmezed a leírtakat, akkor kiderül számodra is (persze csak kikapcsolt freetard mód mellett), hogy mi volt a felkiáltójel-használat célja.
Arra a nonszensz elképzelésre, hogy root jog megszerzésével csak az encrypted homeodat törlik le, inkább nem írok semmit.

Ilyen, és ehhez hasonló appokban ilyen jellegű hibát kevesen keresnek forráskód alapján.

Mint amikor az ios 4.3-as szeriajat egy FreeType buffer overflow segitsegevel jailbreakeltek ?

Ha ez valami hálózatos, távolról kihasználható exploit lenne, akkor nagyobb esélye lenne annak, hogy forráskód szinten hamarabb kiderülhessenek gyengeségek, mint használat közben.

Mint a ma mar klasszikusnak szamito IPSec, ill. OpenSSL fiasko eseten ?

Nem az szamit hanyan nezik, hanem az aki nezi erti is azt amit lat es utana mire hasznalja fel.

---
pontscho / fresh!mindworkz

"Az X.Org oldalon megjelent biztonsági értesítő szerint a BDF fontfájlban egy vártnál hosszabb karakterlánc túlcsordíthatja a puffert a stacken - a Stack Protectorral fordított X szerverek azonnal összeomlottak, amikor egy speciálisan előkészített fontfájl olvasását kísérelték meg."

Evvel mit fog sikerülni elérni? Root leszel a laptopomon? És? Letörlöd az enrypted home-omat? Júj.

Az igaz, hogy nem a szemek száma, hanem a szemek mögött lévő szakértelem a döntő, de aki azt állítja, hogy a closedsource szoftverben pont akkora eséllyel fedezhető fel hiba, mint az opensource-ban, az nem mond igazat. :)
--
PtY - www.onlinedemo.hu

Evvel mit fog sikerülni elérni? Root leszel a laptopomon? És? Letörlöd az enrypted home-omat? Júj.

Ha mar ballagunk az ovis szint fele, kit erdekel onmagaban a te laptopod, de ha megis azon szovogeted a vilagmegvalto vagy legyalulo terveid, akkor egy masik, remote sechole-lal megtamogatva siman telepitheto igy root joggal egy sniffer, rootkit, vagy akarmi mas ugy, h ebbol annyit latsz, h "bakker, megint lerohadt az X". Vagy hasznalhatjak a geped ugrodeszkanak egy kovetkezo allomasra. Es ez ne csak legbol kapott pelda legyen, igy loptak ki a Valve-tol is a HL srct.

Az igaz, hogy nem a szemek száma, hanem a szemek mögött lévő szakértelem a döntő, de aki azt állítja, hogy a closedsource szoftverben pont akkora eséllyel fedezhető fel hiba, mint az opensource-ban, az nem mond igazat. :)

Te sem tudod mi az az Hex-Rays/Zynamics, mi ? :) Milliok hasznalnak ki mobil fronton ilyen hibakat (akar nyilt, akar zart forrasu) mindenfele rendszereken jailbreakre nap, mint nap.

---
pontscho / fresh!mindworkz

Az első részhez: vannak rootkit észlelésére alkalmas alkalmazások - nem véletlenül. Az meg, hogy X-től hogyan loptak, nem érv. Valakivel meg lehet csinálni, hogy "Jé, egy elefánt", és amíg oda néz, kivenni a kezéből a mobilt, valakivel meg nem. Sőt, akivel meg lehet, jó esetben avval is csak egyszer.

A másodikhoz: nem mintha tudnom kéne, hogy mi az, de azokkal az eszközökkel egyaránt lehet találni a binárisban hibát függetlenül attól, hogy zárt vagy nyílt a forrás. Nyílt forráskódban meg ezek nélkül is lehet. Ezt az apró tényt felejted csak el.
--
PtY - www.onlinedemo.hu

Inkább így:

Hibás kódrészlet: 

000ffdf0  61 59 ed 1c a0 f3 92 33  1a 9a 60 5b bd e3 ed bd  |aY.....3..`[....|
000ffe00  aa 52 4f 1e 3b b2 85 a5  fe b2 fc 23 ab 2f fc 00  |.RO.;......#./..|
000ffe10  3d e1 eb ce 5b 3e 36 d2  3a e3 de 6a 0e 0c f0 98  |=...[>6.:..j....|
000ffe20  9f 98 1c 29 21 cf b5 9a  41 0e 66 a5 58 19 1c 1e  |...)!...A.f.X...|
000ffe30  86 a6 21 4c dc fd 8e 7a  12 fd 19 2b bf b8 71 b2  |..!L...z...+..q.|
000ffe40  e1 9f 6d c8 bf cb 6a c6  1b 70 cf 94 5c 6f 89 5c  |..m...j..p..\o.\|
000ffe50  b8 f7 b4 b4 ba a4 f8 bc  79 bb 82 6c 35 17 09 41  |........y..l5..A|
000ffe60  80 da 4d 2d b3 99 78 ce  d1 31 ed e7 64 b4 aa 73  |..M-..x..1..d..s|
000ffe70  8f 4b 3b fc bb b1 4e 04  0e 59 8e f6 3f 76 f4 ba  |.K;...N..Y..?v..|
000ffe80  b2 30 e0 c9 42 a1 55 8b  d9 49 a1 09 e7 d4 b1 3a  |.0..B.U..I.....:|
000ffe90  a5 52 90 88 73 62 a7 2f  0c 1c 62 d5 40 c9 31 9f  |.R..sb./..b.@.1.|
000ffea0  18 83 b0 10 7d 9a 32 b7  c6 c2 f2 c7 28 21 5e a2  |....}.2.....(!^.|
000ffeb0  dd b1 48 ed 37 05 c8 5d  32 bc 8d 88 4b ba b2 dc  |..H.7..]2...K...|

;)

Nyilván használnak mindenféle toolokat (sparcra, ia64-re, x86-ra, x64-re, stb.) külön-külön, mert túl egyszerű, ha ott a forrás.

/Ha már trollkodunk, trollkodjunk rendesen/
--
PtY - www.onlinedemo.hu

Az meg, hogy X-től hogyan loptak, nem érv. Ki lop az X-től? Senkinek sincs szüksége a fontfájljaira :D Eddig az volt az ultimate freetard érv, hogy root jog nélkül nem megy semmire az egyszeri támadó, de úgy néz ki, hogy linux alatt már a privilégiumszint sem számít, csak "az X-től lehet lopni".

Valakivel meg lehet csinálni, hogy "Jé, egy elefánt", és amíg oda néz, kivenni a kezéből a mobilt, valakivel meg nem. Sőt, akivel meg lehet, jó esetben avval is csak egyszer. Szegény Svindlerek hogy tudtak így 7 évadot összehozni...

"Ki lop az X-től?"
Amit idéztél tőlem, az adatszivárgásról szólt - segítsek értelmezni a jelentését, vagy megtartod a trollmaszkot?
A privilégiumszint számít. Csak nehogy már ez a 22 éves exploit legyen erre apropó! Ha van egy Linuxos gép a közeledben, hogy ezt kihasználd, egyszerűbb, ha már az init=/bin/bash kernelparaméterrel bootolod, és exploit sem kell a privilégiumszinthez - és ehez még trollnak sem kell lenni.
De csináld még, egyre jobban tetszik :D
--
PtY - www.onlinedemo.hu

( uid_16313 | 2014. 01. 09., cs – 15:48 )

Lehet anno az NSA kérésére írták a kódot.

--
robyboy

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

( Huncraft v | 2014. 01. 09., cs – 18:12 )

Van egy tippem, hogy ehhez lesz köze a dolognak: http://www.youtube.com/watch?v=2l7ixRE3OCw
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nekem is ez jutott eszembe. Az a furcsa, hogy jött egy security-s csóka, aki teljesen "triviális" hibákat kezdett keresni az xorg kódban, és talált belőle rögtön egy pár tucatot. Miért csak most vette valaki ezt elő? Több szem többet lát: na persze. Én hiába nézem, nem látom ezeket a hibákat, mert nem vagyok szagértője a témának.

Annyi hozzáfűzni valóm van, hogyha nem lenne nyílt forráskód, akkor a csóka sem látott volna semmit... hisz nem lett volna rá lehetősége.

Hátránya a nyílt forrásnak valójában ugyan az is egyben... pl amit Pontscho is írt, hogy nem mindegy, hogy aki érti és olvassa az mire használja fel...

"pl amit Pontscho is írt, hogy nem mindegy, hogy aki érti és olvassa az mire használja fel..."
Ebben igaza is van.
De ez a konkrét eset most úgy kerül bemutatásra, mint ahogy anno őseink hordozták a véres kardot körbe. Holott humbug az egész. Igen, befordítható a xorg, és igen akkor a currentuser root jogokat szerez. Napuff. Ha már ott a kezemben a konzol, nem kellenek ilyen fondorlatos módon kijátszható exploitok ahhoz, hogy root jogai legyenek az embernek, sőt, még X sem kell. Ez csak egy lufi. Erre utaltam akkor, amikor a távolról kihasználható exploitokat említettem, mint igazi veszélyforrást. Erre jön X db troll, és root jog, root jog kiáltással tücsköt bogarat összehord.
Holott ha értene egy kicsit is hozzá, akkor tudná, hogy ha a konzol elérhető, akkor nem kell exploit a root joghoz.
--
PtY - www.onlinedemo.hu

Nem feltetlen kell installalni, a 4.3-as ios-hoz tartozo jailbreak egy megfeleloen preparalt, egy ttf-et tartalmazo pdf allomanyt toltott csak le ami triggerelt egy regota a freetype-ban (opensource :-)) levo BoF-ot. Es csa'. Egy linkre kellett csak kattintani, de csak azert, h az user interakcio kizarja a "veletlen" jailbreaket es a felhasznalo felelossege legyen a buli.

---
pontscho / fresh!mindworkz

tl;dr: Retard debian maintainer úgy gondolta, hogy ért a C-hez és elkezdett okoskodni az openssl levlistán, hogy szarazegész. Ott elhajtották a francba, hogy tanuljon meg C-ül meg security-ül. Utána úgy gondolta, hogy de hát ő mégiscsak jobban tudja, hogy nem kellenek oda azok a warningok és megpatkolta a debissl-t. Ezzel gyakorlatilag kipatchelt mindent, ami frissítette a entropy poolt és egyedül a Process ID alapján hozta létre a kulcsokat, így max 64K féle lehetett. A neccesebb ez mondjuk egy openssh-nál, ami valszeg az első párszáz processben benne lesz.

Az igazán ironikus az, hogy még mindig ugyanaz a maintainere a csomagoknak...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Retard debian maintainer

Nevezzük csak a nevén: Kurt Roecx

És pár apró korrekció: nem elhajtották a francba, hanem Kurt eredetileg valami olyasmiről hablatyolt, hogy openssl libhez linkelő programok debugolásakor zavarja a warning, ezért okés-e kikommentezni azt a sort. Szót nem szólt arról, hogy ezt a patchet ő most be kívánja rakni production kódba is, így az openssl fejlesztők nem kezdtek el tiltakozni (azt leszámítva, hogy felhívták a figyelmét arra, hogy a problémájának megoldására már készen van egy build flag, nem is kell semmit kikommentezni).

http://marc.info/?l=openssl-dev&m=114651085826293&w=2
---
Régóta vágyok én, az androidok mezonkincsére már!

A legszebb az egeszben, hogy o is tisztaban volt a hatasaval:
(kiemelesek tolem)

> What I currently see as best option is to actually comment out
> those 2 lines of code. But I have no idea what effect this
> really has on the RNG. The only effect I see is that the pool
> might receive less entropy.

forras: itt.

Szoval tudta, mit csinal, vagy legalabbis erosen sejtette,
mivel le is irta.

Azert ahhoz nem kell programozonak lenni, hogy az ember tudja, hogy
egy "security software" erosen epit az "entropy"-ra, es nem csak elmeleti szinten.
Igazabol barhol ahol kulcs generalodik, vagy valamit is titkositani akarunk,
mindig elojon az entropy.

Szerintem a legrosszabb az egeszben, hogy ugy csinalta,
hogy tisztaban volt bele, hogy labon lovi sajat magat....

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Szerintem ő még óvatos volt, de a válasz rá már kevésbé:


but I have no idea what effect this
> really has on the RNG. The only effect I see is that the pool
> might receive less entropy. But on the other hand, I'm not even
> sure how much entropy some unitialised data has.
>
Not much. If it helps with debugging, I'm in favor of removing them.

Ahhoz nem. Csak a hanyattesett xorg-on el kéne kapni a sessiont is, az meg önmagában evvel az exploittal kicsit nehezen kivitelezhető a világ másik feléről.
Tehát igen, megborítani az adott hibával meg lehet, de ki is használni ezt önmagában még kevés.
--
PtY - www.onlinedemo.hu

Erről az exploitról beszélünk, a 22 évesről. Persze, csomó mást még lehet csinálni, sőt, el is lehet kérni a root jelszót emailben, van olyan is, aki meg is adja. Mindent lehet, csak épp nem erről van szó, hanem a tárgybéli konkrét exploitról.
--
PtY - www.onlinedemo.hu

Exploit a sechole kihasználása.
A sechole egészen addig nem cinkes, amíg ki nem használják.
Ezzel a sechole-lal önmagában csak akkor érhet valamit egy támadó, ha ott van a gép mellett. Terelheted más irányba a beszélgetés menetét, csak nem érdemes.
--
PtY - www.onlinedemo.hu

"Ezzel a sechole-lal önmagában csak akkor érhet valamit egy támadó, ha ott van a gép mellett. Terelheted más irányba a beszélgetés menetét, csak nem érdemes."

^- Ismét bemutatkozik a "magyar IT krémje".

hup.hu <3

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Holott ha értene egy kicsit is hozzá, akkor tudná, hogy ha a konzol elérhető, akkor nem kell exploit a root joghoz.

Taníts, Mester! A notimon a teljes diszk titkosított. Vázolnád 3-4 számomra is érthető lépésben, hogy ha hozzáférsz, hogyan szerzel root jogot?

ps: az alsónadrág gnóm megoldás nem ér.

A boot szektor is? Mert ha a bootoláskor a memóriába csempész valamit, attól kezdve cseszheted a kódolt vinyót.
De továbbmegyek: ha hozzáfér a konzolhoz és el tud indítani rajta külső eszközről valamit, akkor _elvileg_ védtelen vagy, mert akár a BIOS-ba is berakhat valami disznóságot -> ott már a jelszóvédett diszk - nem fájlrendszer! - sem segít.

azt hiszem félreértettétek amit írtam... én a _csókára_ írtam, hogy nem hinném, hogy képes lett volna találni bármit is forráskód nélkül... és azért van előnye a nyílt forráskódnak mert akár _középszerű_ programozók bele tudnak látni, kódot jobbá tenni...

de sajnos a világ gonosz és a hátránya ezért többszörös, hisz olyan személyek is belelátnak, akik még ha szintén középszerűek akkor is érthetnek belőle annyit, hogy visszaéljenek vele.
(pl egy változó kezelési hiba egyik nyílt forrású programba, amit javítanak... s a gonosz Pistike gyorsan keres hasonlót egy másik nyílt forráskódú szoftverben -még ész sem kell sok hozzá -sajnos-)

( mynheer_gabor | 2014. 01. 09., cs – 18:50 )

Lehet hogy jövedelemkiegészítésképp elkezdek "Fiatalabb vagyok a CVE-xxxx-xxxx X secholenál" pólókat gyártani.
Igényedet név, cím, linux kernel és X verziószám feltüntetésével ebben a szálban jelezd!

( uid_7086 | 2014. 01. 09., cs – 23:44 )

Valamit azért nem értek. Linuxokat, egyéb Xorg-ot használó rendszereket üzemeltetnek olyan helyeken is, ahol rendszeresnek mondhatók a szoftver auditok, nem?
Függetlenül attól, hogy van forrás vagy sem, hogy a fenébe lehet, hogy ennyi ideig nem tűnt fel sehol, senkinek pl. ez a hiba? (meg gondolom, még jó sok)

Az auditorok op.rendszereket nem szoktak ellenőrizni?

ui: jól láttam, hogy debianon máris jött rá frissítés?

Az auditor az oprendszert úgy ellenőrzi (jobb esetben), hogy lekéri a gyártótól sebezhetőséget tartalmazó csomagok listáját, majd ezt összeveti az installált csomagok listájával. Ha talál valamit, ami a gyártó szerint sebezhető, akkor megindokoltatja, hogy miért van az fenn (pl. mert az SAP a csomag azon verziójára adott pecsétet). Ekkor vagy elfogadja, hogy ez egy ismert és az üzlet / üzemeltetés által vállalt kockázat, vagy még kötekedik egy kicsit, és megkérdezi, hogy milyen kiegészítő kontrollt használnak, hogy a sebezhetőséget mégse lehessen kihasználni. Ilyenkor az üzemeltetés azt mondja, hogy logolnak, tűzfalaznak, meg van IDS/IPS is. És ekkor az auditor békés álomra szenderül, ami a következő fél éves kötelező felülvizsgálatnál ér véget.

Ez nem csak hazai metodika?
Nem írtam, de az egész azért kezdte piszkálni a fantáziámat, mert úgy tudom, az érintett X van "nagy" unixokban is (HPUX, talán AIX, néhai Tru64).
És hát RHEL-t is használnak bankok, kormányhivatalok, biztosítók stb.
Hogy itthon nincs kapacitás ilyen mélységű ellenőrzésre, azt még megértem, de hogy világszerte nem volt senki, aki kiszúrja ennyi időn át... (el kell fogadnom, hogy nem vették észre - vagy ha mégis, gondosan elhallgatták)

Nem, ez a normális nemzetközi metodika. Persze jobb esetben automatizálva + összeszedve a "veszélyes" beállításokat a /etc alatt, a kóbór suides programokat, mindenki által írható könyvtárakat, gyenge jelszavú felhasználókat, nyitott portokat stb. Igazából az auditor se nem pen tester, se nem programozó, neki el kell hinnie, hogy a drága pénzen vett RHEL supportért cserébe a gyártó tudja, hogy mivel van baj, és elég gyorsan javítja.

Erről vannak konkrét tapasztalataim is.
- Az audit No.1 végeredménye: A rendszergazda fáradt és túlterhelt.
- A kb. 300 oldalas hibalista hatására bejelentkeztünk a biztonsági főnöknél: Miaszarez? A lista abból áll, hogy az audit szoftver nem ismeri az AIX-et. Jó, jó, de a rendszereden nem találtak más hibát - ezt tőled el is vártam - a többieknél meg hűha!

- És jő a második audit! Szagértő: Itt van egy csomag, ami nem biztonságos. Én: Ok, mindjárt leveszem, mert múltkor csak azért raktam fel, hogy a fostalicska audit szoftver lefuthasson. :))

- Jön a sebezhetőségi lista. Megbízott felelős üvöltöz velem, hogy frissítsek. Ellenállok, mert a befagyasztott rendszerben hiszek. A végén a kb. 20 elemű listából 2 volt fenn, amik csak "alcsomagok" voltak. Ezeket levettem. Bár megnézném azt is, hogy az elindítatlan subsystem kódját miként törik fel! :)

A hűha hibák java része úgy is kiküszöbölhető, ha csak azokat a szoftvereket rakod fel, ami tényleg kell. Így hiába van X az adott AIX rendszeren - mégsincs. No, meg a vindózápdét is gyorsabban fut rajta. ;)

"Az X Window System túlcsordulásos sebezhetőségén keresztül korlátlan hozzáférés szerezhető..."
A túlcsordulás az nem épp a szabályos működésre vall. És az ilyen dolgok a stabilitást is veszélyeztethetik. Nem feltétlenül csak biztonsági kockázatokat rejt magában.

A stabilitást nem fenyegeti, amíg a disztribúció nem szállít olyan fontot, amiben az érintett mező hosszabb, mint az X által kezelt.

ps: Ha stabilitási problémát okozna több felhasználónál, akkor valószínűleg hamarabb megtalálják, mert összeomlik párszáz user X-e, amiből születik pár hibajegy.

Lehet, az is kiderült, hogy az informatika, mint szakma, min. 22 éve fel van higulva, mint állat, és az informatikusok x százaléka csak eljátsza a szerepét adott helyzetnek megfelelően jó(?) fizetségért.

--
robyboy

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

Régen az volt a helyzet, hogy nem nagyon foglalkoztak a security-vel. A világ legnagyobb szoftvercége is csak 2002-ben kezdte komolyan venni, Bill Gates Trustworthy Computing memo-ja után. Ez a nagy securitysdi a mainstream-ben elmúlt 10 évben terjedt el.

Az elmúlt 10 évben megszaporodtak a biztonsági konferenciák, a biztonsági versenyek. A security emberek régen underground helyeket találkoztak, ma ünnepelt celebritások. Showműsorok keretében, csillogás-villogás, Las Vegas, díjátadók.

Az egész megváltozott. Most el lehet egy karriert indítani azzal, ha valaki talál néhány komolyabb hibát. A nagy cégek azonnal munkát ajánlanak neki. Persze, hogy egyre többen bújják a kódot, futtatják az ellenőrzőprogramokat...

--
trey @ gépház

"Régen az volt a helyzet, hogy nem nagyon foglalkoztak a security-vel."

Ma meg a helyzet egy kicsit vicces:
"Microsoft has all significant mitigations fully integrated and enabled!!

Linux has code for all the mitigations. Most vendors enable them very
sparingly (sshd), and in general support is disabled... :-(

Apple has ASLR (but not the other methods?)

Most Cell-phone platforms use these features, but less protection
benefit (thread-intensive environments)"

Idezet innen

A probléma inkább az, hogy a első lépésként a programozókat kéne oktatni arra, hogy hogyan kellene programozni biztonságosan. A Microsoft-nál is ezzel kezdték. Kíváncsi lennék egy programozók körében végzett, biztonsági kérdésekből összeállított teszt eredményére.

A "mitigation" az meg annyit ér, amennyit. Láthatjuk. Minden rendszerben vannak ordas hibák és ki is használják őket. A Microsoft operációs rendszerei sem kivételek. Aki abba a hiú ábrándba ringatja magát, hogy az "all significant mitigations" mellett biztonságban van, az óriásit téved.

Ráadásul ez a security téma a NSA sztorik fényében egy kicsit elhalványul. Pl. engem érdekelne, hogy security cuccokat áruló vagy telepítő ember hogyan tud 100%-ban megbízni abban, amit árul vagy telepít. Ha meg nem tud, akkor vajon milyen érzése van ezekkel kapcsolatban?

--
trey @ gépház

Szerintem ezt a temakort hunger es paxteam eleg jol kivesezte. Nem hiszem, hogy neked kene itt magyarazni.
Amiert belinkeltem az, hogy Theo szerint ki, mennyire torodik(torodott) a security-vel. Kesobb ott lesz a FreeBSD is.
Erdemes elolvasni es Linux oldalrol levonni a kovetkezteteseket. Aztan gondolkodjunk el azon, hogy az X.org team mennyire is erdekli a security.

Ezt ugye nem gondolod komolyan? 1992-ben már B2 besorolású rendszeren dolgoztam. A DEC VAX is elég jó volt a banki rendszerekhez security szempontjából.
Inkább úgy lehetne megfogalmazni, hogy amióta banki rendszereket készítenek windows alapon, vagy az USA-ban energiaelosztó rendszert vezérelenek windowssal, azóta egyre több a botrány.

Persze, ha csak a showra gondoltál - az is a vindóztól van!

( numen v | 2014. 01. 10., p – 00:43 )

Ahha. Tehát, összefoglalva, az X azért biztonságos, mert eddig mindenki lusta volt / nem volt gusztusa megnézni a kódját… ☺

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

Ezt akár a Linuxra is elmondhatod, mert az is tuti fix, hogy a Linux alatt található kódok nagyját a büdös életben nem nézte át hozzáértő ember, max 1-2 alap security check progot futtattak a kódra, oszt csók.
Amúgy meg már rég rájöttek az emberek arra, hogy egy rendszer nem attól lesz biztonságos, hogy az összes rendszer alatt lévő programot agyon auditálják, hanem inkább próbálnak olyan gátat rakni a támadók elé, ami akkor is megfogja az esetleges exploitot, ha a kód amúgy sérülékeny (emlegetett grSecurity pl), miközben a már fent lévő kódot nem akadályozza futásában (OpenBSD-s példából azért látszik, hogy azért ez se fedhető le 100%-osan anélkül hogy a kódot helyenként ne pofozgassák át) A gáz az, hogy a Linux a mai napig nem jutott el addig, hogy ezeket a security gátakat használható formában beépítse (próbálkozhatsz 1-2 hardened rendszerrel, de ott is erős megszorítások vannak hogy mit és hogy lehet csinálni ) ami amúgy Linus hozzáállása miatt is alakult így.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( willy v | 2014. 01. 10., p – 06:25 )

Megy a vihar a biliben, IT bulvár. Jók ezek az esetek arra, hogy figyelmeztessék az embereket jó ébernek maradni. Azt '9x óta széles körben ismert, hogy az X egy unsecure bughalmaz, ezért ha lehetséges más eszközökkel kell védeni és ha lehet semmilyen hálózati hozzáférést nem szabad neki adni.
Természetesen ez is elment a troll irányba már az első hozzászólás is azt ostorozza, hogy jah de hát manyeyeball és hogy akkor ezt hogy..
Az azért talán bevállalható, hogy forráskóddal könnyebb ilyen hibát találni mint nélküle. Az hogy erre rászánja e valaki magát, az egy másik kérdés.
Az pedig elvitathatatlan, hogy nem kell a gyártóra várni a hiba kijavításához, lehetősége van javításra a felhasználónak.
Szóval jelen esetben, ha az xorg zárt forráskódú, mennyivel lennénk jobb helyzetben?
Minden sebezhetőséget annyira érdemes kutatni, amennyi eredményt elérhet vele a támadó. Nem hiszem hogy ettől holnaptól eljönne a hibátlan kódok kora.

ezért ha lehetséges más eszközökkel kell védeni és ha lehet semmilyen hálózati hozzáférést nem szabad neki adni

akkor ezek szerint te is úgy gondolod, hogy X-alapú rendszerek desktop felhasználásra alkalmatlanok, hiszen hálózati hozzáférés nélkül elég nehéz manapság internetezni... :)

Természetesen ez is elment a troll irányba

"troll irányba"(?) a zárt forráskód emlegetésével megy el, hogy "mennyivel lennénk jobb helyzetben?", holott a kérdés nem ez, hanem, hogy meddig tudja tartani magát még a manyeyeballs dogma, amikor példák sokasága bizonyítja az egyébként józan ésszel is könnyen belátható tényt, hogy a nyílt forrású közösség nem képes önmagában biztonsági hibák felderítésére és javítására, hiába nyílt az a fránya forráskód, hanem biztonsági szakértőkre van szükség, akik egyébként zárt kódban is képesek megtalálni a hibákat, ezért azzal érvelni, hogy a nyílt forrású szoftverek már csupán attól biztonságosabbak, hogy a forráskódjuk szabadon elérhető és bárki számára megnézhető, semmi más, mint szemfényvesztés és fals ideológia terjesztése.

"...ezért ha lehetséges más eszközökkel kell védeni és ha lehet semmilyen hálózati hozzáférést nem szabad neki adni...."

akkor ezek szerint te is úgy gondolod, hogy X-alapú rendszerek desktop felhasználásra alkalmatlanok, hiszen hálózati hozzáférés nélkül elég nehéz manapság internetezni... :)

Nem, pontosan azt gondolom ami oda van írva. Önállóan, csak attól hogy Xorg sem kliensként sem szerverként nem szabad megbízni benne, ellenben megfelelő szállítóval, felelős ráépülő felhasználói program megválasztásával, az operációs rendszerben lévő biztonsági lehetőségek kihasználásával alkalmas használatra. Mint bármi más hasonló rendszer is.

"troll irányba"(?) a zárt forráskód emlegetésével megy el, hogy "mennyivel lennénk jobb helyzetben?", holott a kérdés nem ez, hanem, hogy meddig tudja tartani magát még a manyeyeballs dogma, amikor példák sokasága bizonyítja az egyébként józan ésszel is könnyen belátható tényt, hogy a nyílt forrású közösség nem képes önmagában biztonsági hibák felderítésére és javítására, hiába nyílt az a fránya forráskód, hanem biztonsági szakértőkre van szükség, akik egyébként zárt kódban is képesek megtalálni a hibákat, ezért azzal érvelni, hogy a nyílt forrású szoftverek már csupán attól biztonságosabbak, hogy a forráskódjuk szabadon elérhető és bárki számára megnézhető, semmi más, mint szemfényvesztés és fals ideológia terjesztése.

Elsősorban az első hozzászólóra céloztam, meg a 100+ hozzászólásszámra. A manyeyeballs dogmát jórészt a biztonsági szakemberek felhúzott orra tartja fenn. Van jelentősége az OSS-nek. A kód publikálása megköveteli, hogy legalább a program írója vállalhatónak tartsa a kódot, vagy már eleve ő közli, hogy vállalhatatlan, és át kéne nézni. Míg persze zárt forráskód esetén (és most itt rögtön nem több milliós felhasználó számú szoftverekre gondolok persze) bőven van olyan, hogy a forrás kódjának szimpla megosztásától fél az írója, de a programot terjeszti.
Nagyobb szoftverek esetén, pláne több (3+) fejlesztő esetén a nyílt forráskód csak lehetőséget ad másnak a hozzájárulásra, és ezáltal _akár_ biztonságosabb is lehet, de ettől magában biztonságos nem lesz, bár ezeknél a fókuszban lévő szoftvereknél (bocs eleve a fenti hivatkozásod miatt) a kódolásra mivel publikálva lesz még jobban odafigyel, és legalább megpróbálja elrejteni azt a buta backdoort.
A hülyeség ellen meg semmi nem véd. Hibátlan program elég kevés létezik a világon, és nem fog holnaptól sem jelentősen változni a számuk, a kódsorok számával pedig fordítottan arányosan csökken a lehetősége annak hogy adott időintervallumban ne létezzen benne hiba.
Ezen felül a lehetőség a személyes beavatkozásra azért mégis kiemeli az OSS-t. Mert az általánosan ismert hiba akár gyorsabban is javítható. Pláne ha nincs is fejlesztője az adott szoftvernek már.
Azt pedig, hogy a biztonsági szakember ilyenkor arra hivatkozik: lámcsak hiába OSS mégsem találták meg benne a hibát és be kéne látni hogy, nem _jobb_ az OSS biztonsági téren az nonszensz. Jobb, de csak minimálisan, és aki ebben a minimális védelemben bízik azt komoly meglepetések érhetik.

Mindenesetre a fejlesztés (itt értem a szoftver képességeinek létrehozása) és a biztonsági szint mindig egymás ellenfelei lesznek, és ezért van értelme ilyen fejlesztéseknél fenntartani fejlesztő és programellenőrző gárdát.

Vizsgálandó még, hogy az Xorg-nak nem lett széles körben elfogadott alternatívája/forkja amivel a hulladék kódbázis problémát meg lehetne oldani, ilyenkor az is érdekes kérdés, miért.

ellenben megfelelő szállítóval

pl.?

felelős ráépülő felhasználói program megválasztásával

Sem tudsz. A felhasználói program nem implementálja saját maga az X alszolgáltatásait, mint pl. a kép, vagy fontkezeléssel kapcsolatos függvénykönyvtárakat (libXfont, amelyről ugye jelenleg is szó van). Márpedig ha azokban hiba van, akkor akár egy böngészőn keresztül is kihasználhatóvá válhatnak, vagy bármely más felhasználói programon keresztül, amely szintén használja...

operációs rendszerben lévő biztonsági lehetőségek kihasználásával

Grsecurity/PaX proaktív biztonsági megoldásai megnehezítik az ilyen jellegű hibák kihasználását, de nem sok szállítót tudok, aki ilyen desktop rendszereket kínál. A tipikusan elterjedt SELinux, AppArmor és társaik viszont X-ben lévő hibák kihasználása ellen jelenleg nem sok mindent tudnak tenni...

Pusztán Wiki/leírásokra alapozva:
* Nem függ az X-től, pl. az OpenGL-ből is azért csak az ES-t használják és nem a teljest, mert a libGL behúzná a GLX-et (és így az X-et)
* Pont ez a lényege a Wayland-nek, hogy a tonnányi kódot kidobhatják a francba(1), mert csupa olyan cucc, amit senki nem használ (2) (najó, ami programok közvetlenül X-et kommunikálnak, bármilyen UI toolkit nélkül).

(1): pontosabban egy darabig kénytelenek egy X11 kompatibilitási réteget (xwayland) csinálni, amivel a régi szutykok tudnak beszélgetni
(2): a legtöbb UI toolkit eddig is saját bufferbe dolgozott, amit aztán 1-1-ben átadott az X-nek:

What’s different now is that a lot of infrastructure has moved from the X server into the kernel (memory management, command scheduling, mode setting) or libraries (cairo, pixman, freetype, fontconfig, pango, etc.), and there is very little left that has to happen in a central server process. ... [An X server has] a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this. ... This includes code tables, glyph rasterization and caching, XLFDs (seriously, XLFDs!), and the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. For many things we've been able to keep the X.org server modern by adding extension such as XRandR, XRender and COMPOSITE ... With Wayland we can move the X server and all its legacy technology to an optional code path. Getting to a point where the X server is a compatibility option instead of the core rendering system will take a while, but we'll never get there if [we] don’t plan for it.

BlackY

Szépen és jól hangzik (meg is veszem, ha megjelenik CD-n és kazettán :), de ugye a probléma az, hogy egy rakás dolog ettől még ugyanúgy a Waylanden kívül hozzányúlhat az Xlib-hez. Ott van a már korábban említett GTK+/GDK, de szintén ilyen az SDL is, amelyik bizonyos dolgokhoz szintén az Xlibet (illetve egész pontosan az XCB-t) használja.

Szóval nem olyan egyszerű ez, de a törekvés persze dícsérendő. Az mondjuk más kérdés, hogy nyilván a Wayland és a többi alternatíva se lesz 100% bugfree...

SDL-ből már van olyan verzió, ami nem wayland-dal együttműködik, ott szerintem már nincs X dependencia..

Itt van egyébként egy lista, GTK3, QT5, SDL támogatja a wayland-et.

https://wiki.archlinux.org/index.php/Wayland

A lényeg az, hogy az X réteget, a maga 20+ éves kódjával ki lehessen hajítani a francba, használja az, aki valami ősrégi legacy rendszert kell supportáljon, a többiek
meg had menjenek előre...

Értem én, csak ez egyelőre meglehetősen megbízhatatlan jövendőmondás. :)

Az a helyzet, hogy ez egy olyan szoftver, amely még erősen fejlesztés alatt áll és vagy lesz belőle valami, vagy nem, vagy elterjed, vagy nem, hiszen vannak más irányvonalak is, más érdekeltségekkel és más támogatással, mint pl. a Mir. Ráadásul az az érzésem, hogy Ilja sem csupán hobbiból auditálta az X kódját több mint egy éven keresztül, hanem valaki fizetett érte. Akkor pedig vagy hosszútávú tervei vannak valakiknek az X.org kódjával (Oracle?), vagy valakinek szüksége volt néhány X-et érintő sebezhetőségre... ;)

Wayland és mir lényegében használható, és van egy x redirect rétegük az olyan appoknak, amik közvetlen használnak xet. Az egy másik kérdés hogy ez disztókban mikor fog megjelenni, de mir szerintem max egy éven belül az ubuntuban lesz, gondolom előtte végig kell nézniük az alkalmazásokat, illetve még az amd/nvidianak kell egy kis módosítást tenni a bináris drivereikbe, persze lehet h ezt már meg is tették, nem követtem...

( atomjani | 2014. 01. 11., szo – 18:26 )

Ha nem lennének ilyen bonyolult rendszerek, akkor biztonsági hibák se nagyon lennének. Mivel egyre bonyolultabbak lesznek a rendszerek, tuti hogy lesz egy jó pár biztonsági hiba is.