SECURITY FIX: All Architectures (revision 2)

OpenBSD

Úgy tűnik, hogy nem sikerült elsőre tökéletesen javítani az OpenBSD nemrég napvilágra került mbuf sebezhetőségét, mert Henning Brauer tegnap bejelentette a patch-ek második revízióját.

( Hunger | 2007. 03. 18., v – 20:31 )

Nem kis cirkusz volt a misc-en is a bug kapcsán... :)

Hát, a második alapján nekem nem úgy tűnik, hogy a szart kavarja, inkább a bizonyítványt magyarázza. :) Az meg kifejezetten mókás, hogy a felhasználóikra mérges, bár tudjuk, hogy "OpenBSD is a developer culture". :))

Bár minden elismerésem az eddigi eredményeikért, de azért ebből a gyerekes hozzáállásból már ideje lenne kinőni. :(

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

> Bár minden elismerésem az eddigi eredményeikért, de azért ebből a gyerekes hozzáállásból már ideje lenne kinőni. :(

Ez szerintem csak egy beepitett szuro, vegul is talan nem az alapjan kellene rendszert valasztani, hogy a fejlesztoiknek milyen a szemelyiseguk.

Amugy csak nehanyszor jartam a #openbsd csatornan, ott meg nagyobb arcok vannak, a kozosseg kemeny magja ugyanezt a hozzaallast koveti.

Igazából szerintem a tanulság az, hogy nem röhögne rajtuk a fél világ, ha a sebezhetőségekkel kapcsolatos statisztikájukat nem próbálnák folyamatosan szépíteni mindenféle mondvacsinált szabályokkal (pl. SECURITY FIX helyett RELIABILITY FIX címkézés az Errata-ban a rendszerösszeomlásoknál és hasonlók).

szerintem security fixkent van

010: SECURITY FIX: March 7, 2007 All architectures
2nd revision, March 17, 2007
Incorrect mbuf handling for ICMP6 packets.
Using pf(4) to avoid the problem packets is an effective workaround until the patch can be installed.
Use "block in inet6" in /etc/pf.conf
A source code patch exists which remedies this problem.

vagy vagy dumbass?

Jah, most már igen (mióta a CoreSec bebizonyította, hogy távoli kódfuttatás lehetséges kernel szinten a hibának köszönhetően :), de ezt az egész RELIABILITY vs. SECURITY dolgot egyébként sem csak a mostanira értettem, hanem általánosságban. Ha "csak" remote DoS, az is security probléma... Egyébként alatta az Errata-n van egy ilyen pont (008: RELIABILITY FIX: January 16, 2007 - Under some circumstances, processing an ICMP6 echo request would cause the kernel to enter an infinite loop), ezekre gondolok.

az miert lenne biztonsagi hiba? magyarazd meg. szerintem attol hogy a rendszerem osszeomlik meg semmilyen biztonsagi kockazat nem lesz. vagy de? omlaszd ossze a rendszered aztan tavolrol probalkozhatsz, mikozben a gep ddb> ben csucsul, esetleg mikozben szarra van fagyva... amit mondasz az a baromsag.

Egy általam nagyra becsült ember az alábbi példát hozta erre:

Ha van egy feature, amelyhez csak hitelesített, speciális privilégiumokkal rendelkező felhasználó férhet hozzá (pl. shutdown/reboot) és egy bug lehetővé teszi, hogy egy ilyen hitelesítést és magasabb privilégiumot igénylő funkció elérhetővé váljon mások számára is, akkor az egy security bug... és szerintem teljesen igaza van, bármennyire is próbáljátok szépíteni a dolgot.

Egyébként Dave Goldsmith a Matasano-tól is úgy vélekedett a blogjában, hogy ez csak egy játék a sebezhetőségi statisztikával. Olyan, mint legalizálni a drogokat és a prostitúciót, majd arról értekezni, hogy mennyivel csökkentek a bűnesetek.

Te nem érted. Nem "file" hozzáférésről van szó, hanem arról az egyszerű tényről, hogy a szerverek leállítása is egy bizonyos jogosultsághoz kötött (nem hajthat végre bárki shutdown-t a rendszerben), amely ezáltal sérül, hisz enélkül a privilégium nélkül is leállíthatja _bárki_ a szervert (ráadásul akár távolról is), tehát _biztonsági_ problémát jelent, hisz hitelesítés és megfelelő jogosítvány nélkül teheti ezt meg.

Ennél jobban nem tudom elmagyarázni...

Ja meg azt, hogy _found_ :D Mint kiderült pl firefox esetében is: mihelyt mérhető a használók száma rögtön megugrott a hibák száma is. :D Persze ettől még lehet jó, mint ahogy a firefox is jó.

Software is like sex, it's better with a penguin. :D (r)(tm)(c)

Thug, az a baj, hogy nem vagyok benne biztos, hogy a "biztonsagi hiba" kifejezes altalad/altalatok vett "definicioja" nem feltetlenul egyezik meg a vilag sok mas helyen hasznalt definiciojaval.
Nem csak az szamit biztonsagi hibanak, ha en - jogosultsag nelkul - hozzaferek olyan "adathoz" amihez nem lenne szabad, de az is, ha en jogosultsaggal egyutt sem tudom ezt megtenni. (Bar Hunger peldaja meg a Te definicioddal egyutt is mukodik, kovetkezeskeppen akar el is lehetne fogadni. De ez itt semmi egyeb, mint egy statisztika szepitese, regi kifejezessel elve: "szerecsenmosdatas".)

Itt azért némileg definiciós problémábába kavarodtunk bele..
Ha feltörésnek azt tekinted, hogy a cracker olyan szolgáltatáshoz/adathoz fér hozzá, amihez nem lett volna semmiképp se joga akkor az, hogy a rendszert összecrasheli valóban nem feltörés.
Viszont ilyen szempontbóűl a DDOS-t se tekintheted törésnek, holott hasonló következményekkel járhat egy DDOS is, tekintve hogy ugyan olyan ( ha nem nagyobb ) anyagi kiesést eredményezhet azzal, hogy az adott szolgáltatást/információt más se éri el, ami meg presztizs kérdés.
És itt még nem is vettük figyelembe, hogy mi van akkor, ha egy ilyen támadással épp a naplózást, vagy magát a tűzfalat crashelteti el, és nem a komplett rendszer? Lényegében csak egy full védtelen gépet hagy maga után, ami meg onnantól szabad préda..

____________________________________
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: -"Üllj le és kuss legyen!"..

Nem tudom ez a "feltörés" folyamatos emlegetése nálad meg a turulnál valami fiatalkori perverzió-e, de ha nem tűnt volna fel én nem használtam sehol ezt a szót. :)

Főleg mivel az egész nem erről szól, hanem arról, hogy biztonsági problémaként kell-e kezelni a tárgyalt dolgot vagy sem. Márpedig ezt annak kell, hiszen egy olyan funkciót ér el vele a nem-hitelesített "user", amelyhez csak bizonyos privilégiummal rendelkezők férhetnek hozzá eredetileg. Hogy a szerver elérhetetlenné válása a hagyományos shutdown parancsnak köszönhető vagy egy programhibának, az az eredmény szempontjából érdektelen.

Ha feltörésnek azt tekinted, hogy a cracker olyan szolgáltatáshoz/adathoz fér hozzá, amihez nem lett volna semmiképp se joga akkor az, hogy a rendszert összecrasheli valóban nem feltörés.

Egyébként saját magadat cáfolod ebben a mondatban, hisz a szerver leállítsa egyfajta kiemelt szolgáltatásnak tekintendő, hisz csak az arra jogosult személy végezheti el. Ha pedig nem csak az teheti meg, akkor az egy biztonsági probléma...

Persze igazából felesleges itt elméletről és definíciókról eszmefuttatni, amikor a szakszavak nálatok a "feltörni" és az "összecrashelni". :P

Tudom, hogy offtopic, de máskor is hasonló nyelvezettel és gondolkodásmóddal tálalt hozzászólásokat lenne jó olvasni Tőled.
Nem vagy Te hülyegyerek (ezt most is bizonyítottad), csak szarul tálalod, mint még pár ember.
Teljesen korrekt volt ezt az egész thread -ot végigolvasni, legalábbis eddig... köszönöm.

--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven

> amit mondasz az a baromsag.

kemeny szavak am ezek egy ilyen sokat bizonyitott security expert-tol ;-). akkor most en kerdezek: mi tortenik akkor, ha a tavolrol meghalasztott gep tortenetesen a ceg NIDS-et futtatta (security expert leven gondolom tudod mi az)? talan megkerjuk a hacker urakat, hogy akkor most legyenek szivesek nem probalkozni, amig ujra nem indul a gep?

> szerintem attol hogy a rendszerem osszeomlik meg semmilyen biztonsagi kockazat nem lesz. vagy de?

de. de ezt majd akkor fogod megerteni, ha kikerulsz az eletbe, lesz rendes munkad es latod, hogy a szobadban elterulo LAN-tol letezik komolyabb halozat is a vilagon.

akkor nezzuk a CORE szerint hogyan tortent:

. 2007-03-05: Core develops proof of concept code that demonstrates
remote code execution in the kernel context by exploiting the mbuf
overflow.
. 2007-03-05: OpenBSD team notified of PoC availability.
. 2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source
tree branches and releases a "reliability fix" notice on the project's
website.

tehat ket teljes nappal azutan, hogy megtudtatok, hogy bizonyitott a remote code execution, kepesek voltatok reliability fix-kent feltuntetni? es meg ujabb ket napig tartott, mire Theo osszekaparta magat az asztal alol es security fix-sze valtoztatta? na persze mit varjon az ember ennyi dumbass-tol, nem igaz? ;-)