"Súlyos hibát találtak az egyik legfontosabb Linux-könyvtárban"

 ( trey | 2016. február 17., szerda - 12:01 )

Idézet:
Súlyos és nagyon széles kört érintő Linux-sérülékenységre (CVE-2015-7547) hívta fel a figyelmet a Google két biztonsági szakembere. Fermin J. Serna és Kevin Stadmeyer blogbejegyzése szerint a vállalat egyik mérnöke egy SSH klienssel kapcsolatban gyanított alacsony szintű memóriahozzáférési hibát (segfault) vizsgált, és az ennek kapcsán indított mélyebb elemzés derített fényt a rendellenes viselkedés valódi okára.

Kiderült, hogy a hiba nem az SSH kliensben, hanem a GNU C könyvtár (glibc) egyik komponensében, a kliensoldali névfeloldóban van: a getaddrinfo() függvény használata puffertúlcsorduláshoz vezethet, így egy megfelelően formázott DNS válasszal és az operációs rendszer egyéb védelmi mechanizmusainak kijátszásával távoli kódfuttatás érhető el.

A teljes cikk 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ő.

Ubuntu tegnapi figyelmeztetője:

USN-2900-1: GNU C Library vulnerability

Debian tegnapi figyelmeztetője:

DSA-3481-1 glibc -- security update

--
trey @ gépház

bemutatjuk a bugmentes tökéletes Linux operációs rendszert, most röhöghet az egesz világ. úgy látszik itt allandoan akadnak biztonsági hibák. :)

Ki állította bármelyik operációs rendszerről, hogy bugmentes? Mennyire lenne életszerű ez? Ha jól emlékszem, a Fedora 9 volt 204 millió kódsor, azóta rengeteget fejlődött, jelenleg Fedora 23-at írunk. Ekkora kódbázison mennyire értelmes dolog arról beszélni, hogy az hibátlan?


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

Nézd már meg kinek válaszolsz!


Normális HUP-ot használok!

ovi...

+1

+1

FYI:

Senki sem ezeken nevetett:

https://support.apple.com/en-us/HT205635

--
trey @ gépház

bazz, ebben több igen durva van...

Rendszeresen. Persze erről annyi szó nem esik.

--
trey @ gépház

Nem is baj, úgyis azt gondolják néhányan, hogy itt csak az apple-t szokás fikázni :)

"úgy látszik itt allandoan akadnak biztonsági hibák."
Melyik OS-nél nincsenek folyamatosan biztonsági hibák? Nem győzik patchelni a Windowst, OS X-et, iOS-t, BSD-t, Androidot, ...

Mégis csak a Windowsról él a köztudatban az, hogy mennyire sok biztonsági hiba van benne, és a Linux milyen kurvabiztonságos.

a lunix mindennél biztonságosabb, főleg az uborka, nem tudtad?

mitől vagy ilyen keserű?

ma nem öntöttem magamra cukormázt

kár, anélkül olyan Gabucinó kinézeted van :)

inkább olyan legyen mint trey

Ha személyes problémátok van akkor azt ne itt! Menjetek ki a hóra, vagy öntsétek ki egymás pálinkáját, de engem nem érdekel!

--
Where do you want to go today?
[nobody@salcay:~]$_

Plzdelete

Ráömlött az alma magja.

:)

És nem is hiába. Tegnap hozták nyilvánosságra a hibát ha jól értem, és ma már érkezik is a javítás

Fedorára tegnap fordították le a javítást, és még csak nem is a nap végén készült el:

Completed Tue, 16 Feb 2016 15:58:39 UTC


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

Jó, akkor még hamarabb :) a lényeg, hogy nem a következő vagy a jövő ilyenkor patch kedden :)

Tulajdonképpen magam is azt igyekeztem mondani, amit te: nagyon gyorsan reagáltak a javítással.


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

Tegnapig volt embargó alatt a bug. Már több mint fél éve ismerte a hibát a vendor, és készítette a javítást.

lásd: https://sourceware.org/bugzilla/show_bug.cgi?id=18665

Ez mondjuk nem hangzik túl jól, hogy egy ilyen sérülékenységgel fél évet vacakoltak. Nem néztem meg a részleteket, de indokolt volt ez a hosszú idő? És nem lenne jobb a biztonsági hibákat előbb javítani (ál-indokkal, de utólag nyomonkövethetően), és utána nyilvánosságra hozni? Nem azért mondom, mert savanyú a szőlő. Mert ez így is egészen impresszív teljesítmény, de azért lehetne még gondolkodni a folyamaton.

"(ál-indokkal, de utólag nyomonkövethetően),"

ezzel azt érnéd el, hogy aki érdekelt a gonoszkodásban, az jobban nyalja át a sima updateket olyanok után amik igazából sec fixek (és mivel utólag nyomon követhetőnek kell lennie, ezért gondolom annyira nehéz dolguk nem lenne a pattern matchinggal), ellenben az üzemeltetők tömege meg nem tudná, hogy ez most fontos, minél előbb ki kéne mennie. Szóval a gyakorlatban szerintem plusz attack windowt adnál.

Ez is igaz. Valahogy úgy kellene megoldani, hogy a security fixek lényegében azonnal érvényre tudjanak jutni. Az oprendszert mondjuk be lehet úgy állítani, hogy automatikusan telepítse őket, de az még így is idő, amíg az upstream eljut a disztróba.

Ez nem jelenti azt, hogy tegnap lett ismert. Akkor hozták nyilvánosságra, amikor a vendor (a GNU projekt) javította. Így persze, hogy egyből jön a javítás.

nembaj, lényeg hogy a linukk userek ettől azt hiszik hogy gyorsabban jött a javítás mint az applenel

Ennyire sokba azért nem kerül egy Apple-cucc, hogy így fájjon.

Az Apple bug jópár napja ismert. Mikor jön a javítás?

--
trey @ gépház

Ha a GNU projekt gyorsaságát nézem, az Apple ráér fél évet dolgozni ezen.

Ahogy az Apple sikerességét nézem az idő patchelését illetően, több éves csúszásban van.

--
trey @ gépház

Az ido relativ :D

--

"You can hide a semi truck in 300 lines of code"

Arra tippelek, hogy nem fog nekik sikerulni elsore tokeletesen fixalni.

vö: publikus, ismert bug vs. csak a vendor által ismert bug. Az első esetben nem biztos, hogy van rá fél év...
Nyilván utóbbi esetben sincs rá garancia, hogy más időközben nem fedezi fel és csinál rá exploitot. Csak lényegesen kisebb :)

Ès tényleg, a Linux a Windows-hoz képest tényleg kurvabiztonságosabb. Csak pár példa:

1. kevesebb idióta használja, akik minden szarra rákattintanak, hogy ömöljön az adware/ransomware/trojan/stb... ebböl következik, hogy ezek a szarok min. 75%-ban Windows binárisok, amik Linux alatt el Sem indulnak.
2. az ssh hibája nem érinti azokat a rendszereket, amiken nincs is ssh. Szóval ez egy olyan sérülékenység, amit a sok klikkhuszár ki ´sem tud használni, mire megtalálja hozzá a kész exploitot be is van foltozva. A szakmai továbbképzési idöt nem számítottam bele.
3. Linux alatt nincs telemetria, ami még a levegövételeid számát is gyüjti és közli a fél világgal.

Ès még sorolhatnám.

--
robyboy

http://arstechnica.com/information-technology/2012/12/richard-stallman-calls-ubuntu-spyware-because-it-tracks-searches/

Igaz nem ugyanaz a ketto, de azert na. Win10 alatt hiaba kapcsolja ki az ember, ahol egy ahogyan csak lehet, attol meg mukodik a telemetria.

Van Ubuntu-n kívül is Linux, én pl. Debian-t használok, mert jobb mindenféle szempontból.
Az Ubuntu-nak nem jósolok nagy jövöt.

Windows-ból csak egy van, ott még választási lehetöséged sincs, ez a 4. pontom.

--
robyboy

Ehhez képest már 2004 vége óta, kb. 12 éve, van Ubuntu. :) Egy kis történelem: https://en.wikipedia.org/wiki/List_of_Ubuntu_releases

Múltja van, jövője nincs. Kb. mint kishazánknak.

--
robyboy

Tényleg kíváncsiságból kérdem: Ezt az állítást mire alapozod? Cloudban és Server fronton is nagyon nyomják mostanában az Ubuntut. Elég csak itt a hup.hu-n visszakeresni. Én inkább azt látom, hogy egyre komolyabb szereplő lesz ezeken a területeken. Ellenben, hogy ebben mekkora szerepet játszik a pénz és a marketing az már más kérdés. :)

Csak egy megérzés, igaz, én a desktop verzióra gondoltam, talán abban a leggyengébb.
Amúgy ne legyen igazam, drukkolok nekik.

--
robyboy

+1, mi most váltottunk szerver oldalon sles-ről ubuntu server-re (illetve párhuzamosan van még redhat)

A linux nem egyenlő az ubuntuval, még ha sokan az ubuntu révén is ismerik vagy hallottak róla, ne mossuk össze.

1. Nem kell ehhez Windows binárist futtatni, elég a böngésző sebezhetőségét kihasználni (Linux alatt is).
2. Itt el tudod olvasni, hogy mi sérülékeny. Itt pedig a patchet. A sebezhetőség pedig régebb óta létezett.
3. Ubuntu?
4. Sorold.

1. Nem keverném a böngésző sérülékenységét az op.rendszerével. Bár, ha belegondolok, a Windows-ba már régen beleégették az Internet Explorer-t.
2. Ja, Glibc, oké, nem ssh - az, hogy milyen régóta létezik egy biztonsági rés, nem számít, mert csak azután lehet kihasználni tömegesen, miután napvilágra kerül
3. Az Ubuntu csak egy disztro a SOK közül, nem A linux.
4. a negyedik pontot lejjebb definiáltam
Bonusz pont: működő linux-ot tudsz telepíteni 0-ról, tetszés szerint. Nálam jellemző a 200 MB körüli memóriahasználat alapjáraton. Ugyanez Windows alatt 600 MB-nál kezdődik. Több kód, több hibalehetőség, több felesleges ballaszt

--
robyboy

Bocs tévedtem, most csekkoltam egy Windows 10-es gépet, 1.7GB RAM-ot zabál úgy, hogy nem fut applikáció rajta, csak háttérszolgáltatások.

--
robyboy

abbol mennyi a filecache?
megy egyéb cache, ami bármikor eldobhato?

A részletek nem érdekelnek, nem a fájlkest dobtam el, hanem a windowst.

--
robyboy

köszönjük emese....

+1

Pedig Windows nélkül is van ám élet!

--
robyboy

ez egyébként valami ilyen furcsa fetisizmus, hogy ugyan van ram, de nehogy a rendszer használni merje, mert még a végén megromlanak benne a szilícium kristályok, vagy?

egyébként meg valakitől, aki szerint a linux a fasza elég vicces a "részletek nem érdekelnek" mondat. Hát hova lesz így a totál kontrol a géped felett...?

Nem. Hanem a memóriát szeretnénk a saját programjainknak adni, az OS meg legyen csak az alapszolgáltatás. Nehogymár azért kelljen az erős gép, sok memória, hogy az OS (ami önmagában semmire nem elég) fusson rajta...

Lásd lent. A windows filecache-ként használja a nem használt memóriát. Ha az alkalmazásnak kell, kap.

El ne áruld nekik, hogy a Linux is. ;) Helyesebben szólva disk cache-nek. Viszont szükség esetén az alkalmazáshoz allokálja.


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

Egyrészt az, hogy az os önmagában semmire sem elég, az szerintem eléggé idejemúlt nézőpont, egy rakás olyan szolgáltatás van, ami kell ahhoz, hogy érdemben tudj dolgozni, másrészt meg az már prioritizálás dolga, hogy az legyen ott, amit épp használsz. Ha nem dobja ki mondjuk a cache page-it, mikor a futó programnak kell a hely, az baj. Az, hogy a rendelkezésre álló memóriát megpróbálja használni valamire, amitől lehet, hogy jobb lesz, az szerintem nem hogy nem baj, de egyenesen kívánatos. (Ironikus módon hallottam én már ezt az érvelést visszafele, amikor épp a windows takarított fölöslegesen dolgokat ki a pagefileba, csak mert)

Ne tereljünk. Ez nálam egy egyszerü döntés volt, amit meghoztam. Nem akartam Windows-t használni.
Eszembe sem jutott, mint opció, hogy Windows alapokon tudjam kontrollálni a gépemet, értsd: Mission Impossible

--
robyboy

Nem ezzel van a baj, magam is így teszek. Az érvelésed nem volt igazán helyénvaló.


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

Melyik része?

Az, hogy van egy Windows rendszer, ami alaphangon giga felett használja a memóriát? Persze sok ram kell, és elmondhatjuk, hogy legalább valami használja. De ez baromság.

Adatot gyüjt, küldi franc tudja hova? Kémkedik? Telemetria? Kinek kell ez valójában?

Nagyobb kód, több hiba. Ne gyüjtsön adatot az engedélyem nélkül semmiröl.

Mivel jobb a Windows 10 a Windows 7-nél, azon kívül, hogy más? Mivel nyújt többet nekem, mint egyszerü végfelhasználónak? Csak azzal ne gyertek, hogy gyorsabb, mert az sokszor csak vizuális élmény - lehet ezért kell a giga Cache, hogy beleférjen a rendszer... SSD-nél tökmindegy.

Ha csak ezeket a pontokat nézem is, a Linux a nyerö, persze nem az ubuntu, ha valakit ez zavar.
Ne mondja nekem senki, hogy egy bloatware-re van szüksége valójában. Tizedéböl ki lehet hozni egy müködö rendszert.

Aztán még beszélhetnénk a Microsoft stratégiáiról is - frissítés komplett rendszercserével, alkalmazások kérdés nélküli törlésével, eröszakos installálásával, stb... Kinek jó ez?

stb... stb...

Folytathatnám estig.

--
robyboy

A következtetéseddel egyetértek, írtam, magam is Linuxot használok, azon belül Fedorát. Az érveléseddel érzek problémát. A kémkedést magam is felháborítónak tartom, bármennyire is az eufemisztikus megfogalmazás, hogy a termék fejlesztése miatt „kell”.

A memóriahasználatos érved hülyeség. A memória akkor is eszi a villanyt, ha nincs benne semmi, lévén, a 0-s bit is, meg az 1-es bit is valami, frissíteni kell, ha már egyszer DRAM a szerencsétlen. Egyedül az a kérdés, a kernel saját nyilvántartásában azt alkalmazáshoz allokálta vagy disk cache-hez, netán bejegyezte szabadként.

Kapaszkodj meg, a Linux kernel is hasonlóan kezeli a memóriát, mint ami ellen prüszkölsz. Amikor az alkalmazás kér RAM-ot például a glibc malloc() függvényével, a kernel optimistán ad, visszatér azzal, hogy sikerült a művelet, ad egy pointert, amitől kezdve használhatsz annyi memóriát, amennyit kértél. Érdekesség, hogy akár többet is kérhetsz, mint amennyi van a gépben, legalább is így emlékszem. Akkor is sikerülni fog.

Ezt úgy oldja meg, hogy a címtartományt megkapod, de memóriát bizony nem kapsz hozzá. Amikor az alkalmazásod írni kezd a kapott címtartományon belülre, kivétel keletkezik, s a kernel gyorsan az alkalmazás alá lapoz egy 4 kB-os (vagy 16 kB-os?, nem tudom) lapot, így ténylegesen lesz alatta RAM. Sok memóriát disk cache-nek használ a Linux, ha már ott van, legalább gyorsabb lesz a file elérés, sőt, ha kiírsz egy kis file-t, majd visszaolvasod, nem is kell, hogy a winchesterig eljusson a dolog.

Nézd csak, mi a helyzet a gépemen:

free -h
              total        used        free      shared  buff/cache   available
Mem:           3.9G        752M        1.1G        336M        2.0G        2.7G
Swap:          8.1G          0B        8.1G

4 GB RAM-om van, de ebből 2 GB-ot disk cache-nek használ a kernel. Ez nem gond, mert ha kell az alkalmazások számára, akkor ebből a disk cache-ből felszabadít helyet. Megteheti, hiszen a disk felé flush-öli a tartalmat, felszabadítja a helyet, aztán odaadja a memóriára ácsingózó alkalmazásnak.

Ahogy mások is írták, annak nem sok értelme, hogy van egy rakás memóriád, majd ott áll kihasználatlanul, de legalább lassúak a file műveletek, mert minden azonnal fizikailag megy a HDD-re, illetve olvasódik onnan minden alkalommal.

Ha korlátozni szeretnéd az alkalmazás memóriahasználatának lehetőségét, erre ott a cgroups. Biztos lehet ezt szépen is csinálni - talán systemd.scope, systemd.slice, de eddig nem jutottam a megértésben -, mindenesetre egy lehetséges eljárásról írtam a blogomban.


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

Köszönöm.

--
robyboy

Ha tenyleg erdekel, akkor ez a cikk jo kiindulasi alap lehet: Windows Process Memory Usage Demystified.

nem terelek. Közölted, hogy mert a windows memóriakezelése szar, mert sok a foglalt memória. Erről kérdeztem.

Ha jol emlekszem, a filecache-t a win automatikusan a free-hez szamolja.

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

Szerintem azt elérhetőnek hívja.

:)

1. Te nem :) De ha már oprendszer sérülékenység, arról a kernelről beszélünk, aminek szinte az összes verziójához van publikus root exploit?
2. Tehát el se olvastad, mihez szólsz hozzá?
"csak azután lehet kihasználni tömegesen, miután napvilágra kerül" - rossz hírem van.
3. A Win10 meg csak egy Windows verzió. És?
4. Biztonságról volt szó, a memóriahasználatot nem tudom minek kevered ide.
"Több kód, több hibalehetőség" - ez igaz, a linux kernel 15 millió sor felett van, és hol van még az X, a böngésződ, meg a többi vacak.
edit: root

1. Amihez van exploit, arra van security patch is. Linux alatt gyorsabban, mint Windows-hoz. Ès jellemzöen nem 100-megás peccs-szörnyek, vagy pl. a 1511-es Winupdate, ami lecseréli az EGÈSZ op.renszert. Bazz.
2. a "tömegesen" szó átment?
3. Nincs választási lehetöséged
4. A memóriafelhasználás ott függ össze a biztonsággal, hogy mennyi a hibalehetöségek valószínüsége. Több kód, több lehetöség.
Windows forráskód hány soros szerinted? Szerintem a Microsoft sem tudja...

--
robyboy

mi köze a memória felhasználásnak a kód mennyiségéhez?

Valójában nincs szoros összefüggés. De jellemzö, hogy robusztusabb rendszer jobban terheli az eröforrásokat, mint a karcsúbb rendszer, még ha nem is egyenesen arányosan.

--
robyboy

Más a filozófiája a két rendszernek. A Windows inkább valami rapid, a felhasználók többségének és a gyártó igényét azonnal, alapbeállításokkal kiszolgáló valami. Ezzel szemben a Linuxban az a nagyszerű, hogy elképesztően rugalmas, választhatsz a desktop környezet, a különféle alrendszerek technikai megoldásai között - pl. ALSA, Pulseaudio; X11, Wayland; System V (init), UpStart, systemd -, az alkalmazások széles választékából, s ha mindez nem volna elég, saját megoldásokkal, scriptekkel elérheted, hogy minden, de tényleg minden úgy működjön, ahogyan szeretnéd.


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

csak azért kérdezem, mert netto baromság. A memória felhasználás nem a komplexitástól növekszik jelentősen, hanem attól, ha valaminek sok adaton kell dolgoznia.

egyébként tehát szerinted a robusztusabb rendszerek jellemzője, hogy több bennük a hiba? mondd, tudod mit jelent a robusztus szó?

"Amihez van exploit, arra van security patch is. Linux alatt gyorsabban, mint Windows-hoz."
A sebezhetőség megléte és a security patch kiadása között sok idő is eltelhet, jelen esetben fél év, de van, amikor 22 év. Abban reménykedni, hogy a patch megjelenéséig nem használják ki a sebezhetőséget, felér egy orosz rulettel.

"a "tömegesen" szó átment?"
ssh-ról beszéltél. A másik részét már fentebb leírtam.

"Nincs választási lehetöséged"
Miért ne lenne?

"A memóriafelhasználás ott függ össze a biztonsággal, hogy mennyi a hibalehetöségek valószínüsége. Több kód, több lehetöség. Windows forráskód hány soros szerinted? Szerintem a Microsoft sem tudja..."
Nem értem mit jössz megint a Windows-zal. Senki nem állította, hogy a Windows "kurvabiztonságos", arra reagáltam, hogy azt írtad "a Linux a Windows-hoz képest tényleg kurvabiztonságosabb.", ami pedig nem igaz. Idekeversz memória használatot, ssh-t, Ubuntu vs Debiant és ki tudja mit, amiknek semmi köze a fenti kijelentésedhez.

Idézet:
A sebezhetőség megléte és a security patch kiadása között sok idő is eltelhet, jelen esetben fél év, de van, amikor 22 év. Abban reménykedni, hogy a patch megjelenéséig nem használják ki a sebezhetőséget, felér egy orosz rulettel.

Ebben a levelben ez all:

Idézet:
- The code that causes the vulnerability was introduced in May 2008 as
part of glibc 2.9.

Fel eve a hibat talaltak meg RedHat dolgozok (linkelt hwsw cikkbol):

Idézet:
a hibát a könyvtár karbantartói már tavaly július óta ismerték, és két Red Hat-es szoftvermérnök, Florian Weimer és Carlos O'Donell is elkezdett már dolgozni egy javításon a 2015-ös hibabejelentéstől függetlenül – az ügy érzékenysége miatt saját szakállra, mások bevonása nélkül. Most viszont egyesítették erőiket a Google szakembereivel, és elkészítették a javítást

Jogos, kösz a helyesbítést.

1. Amihez van exploit, arra van security patch is. Linux alatt gyorsabban, mint Windows-hoz. Ès jellemzöen nem 100-megás peccs-szörnyek, vagy pl. a 1511-es Winupdate, ami lecseréli az EGÈSZ op.renszert. Bazz.
2. a "tömegesen" szó átment?
3. Nincs választási lehetöséged
4. A memóriafelhasználás ott függ össze a biztonsággal, hogy mennyi a hibalehetöségek valószínüsége. Több kód, több lehetöség.
Windows forráskód hány soros szerinted? Szerintem a Microsoft sem tudja...

--
robyboy

> Amihez van exploit, arra van security patch is
Álmodj szépeket. :)

> Linux alatt gyorsabban, mint Windows-hoz.
A xorg / ssh / whatever bug befoltozására is csak 22 évet kellett várni.

> vagy pl. a 1511-es Winupdate, ami lecseréli az EGÈSZ op.renszert
Ez egyrészt marhaság, másrészt az nem patch volt, hanem az OS új verziója, új feature-ökkel.

"csak 22 évet kellett várni."

Ennyi idő alatt futottak le a unit tesztek :-D

Fuszenecker Róbert

Ne lovagoljunk az xorg-on. Egyrészt nem Linux specifikus, millió más rendszer használja. Így csak közvetve van köze a Linux biztonságához. 1% desktop részesedésénél nem biztos, hogy ez a legjobb példa a biztonsági hibák évtizedekig bujkálására.

Van pl. olyan Windows hiba, ami 17 év után javítottak. ;)

--
trey @ gépház

Nem a xorg-on lovagolunk. Arra próbáltam példát hozni, hogy "az open source minden körülmények között biztonságosabb, mint a proprietary" kezdetű elmélet egy baromság. Mondhattam volna az Open* bughalmazokat is, tökmindegy. Az is rendben van, hogy a Windows-ban is vannak bugok, nem állítottam az ellenkezőjét.

> 1% desktop részesedésénél nem biztos, hogy ez a legjobb példa a biztonsági hibák évtizedekig bujkálására

De igen, elég jó példa, mert sokakban az a kép él, hogy a linux az ultimate igazság, amikor biztonságos IT-ről beszélünk. Tökmindegy, hogy mekkora a részesedése, ez legfeljebb a szőnyegbombázás ellen értelmezhető. Célzott támadás esetén teljesen mindegy.

peer review, ezért a legfaszább dolog szabad szoftver.

--
GPLv3-as hozzászólás.

a glibc, a GNU C Lib, azt miért a "Linux operációs rendszer"?

btw, amúgy RMS mit mond ilyenkor? :)

Fedorára az update repóban még nem jelent meg, de aki azonnal vágyik a megoldásra, az a build szerverről már elérheti:

http://koji.fedoraproject.org/koji/buildinfo?buildID=736355

* Tue Feb 16 2016 Florian Weimer <*@redhat.com> - 2.22-9
- CVE-2015-7547: Stack-based buffer overflow in getaddrinfo (#1308943).


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

Debian Jessie az Ubi 14.04 és 16.04 is frissült.
---
http://plazmauniverzum.hu <> A látható anyag 99.999%-a plazma <>

Ja, hiszen tegnap kedd volt ;)

A probléma szerintem megint arra mutat rá, hogy lehet, hogy 2016-ban nem olyan nyelven kellene
alapkönyvtárakat írni, ami 1000 sebből vérzik/vérezhet.

Mit javasolnál helyette?


Normális HUP-ot használok!

Szerintem Javascript. Vagy valami, amit aztán erre fordítanak.
--
zsebHUP-ot használok!

rust, go, vagy bármelyik hasonló nyelvet.

Az buffer overflow problémák döntő része abból az előfeltevésből következik, hogy azt gondoljuk, hogy a fejlesztő tudja, hogy mit csinál, adjunk hát neki szabad kezet, hiszen ő okos, a teljesítmény pedig fontosabb, mint a biztonság. A C nyelv mondjuk 30 éves történelme alatt bebizonyosodott, hogy a fejlesztő "tudásában" nem szabad megbízni, elég csak megnézni, hogy statikus kódanalizátorok milyen mennyiségű buffer overflow hibát találtak olyan kódokban, amiket elvileg "profik" írtak, vagy legalábbis sok ember ránézett, és használt.

Különösen veszélyesnek érzem a problémát olyankor, amikor egy alapkönyvtárról van szó, amin keresztül jó eséllyel rommá lehet törni tetszőleges rendszert. Egyszerűen be kellene már látni, hogy az, hogy egy ms-ot gyorsítunk a mai gépek mellett senkit nem érdekel. Az viszont alapvető elvárás, hogy a program ne haljon el, vagy ha mégis, akkor azt ne lehessen kihasználni, legalábbis nagyon egyszerűen ne.

Mert nem a C nyelvben sokat hangoztatott bízzunk mindent a fejlesztőre mert az úgyis tudja mit csinál című történet miatt van a buffer overflow probléma? De, igen.

Lemaradtam valamiről? Feltalálták az ultimate nyelvet, ami mindig bugmentes?

Azt talán még nem, de ha érdekel, keresd meg Margaret Hamiltont vagy az ügyfeleit...
Elvégre mégiscsak az Ő és csapatának munkáján múlt, hogy az első holdraszállás nem hiúsult meg...

Üdv,
Marci

Ezt a témát szerintem jobb nem feszegetni. http://www.imdb.com/title/tt0081505/


Normális HUP-ot használok!

Nem ugrik be, mire asszociálsz ezzel :( - légyszi, segíts ki.

Üdv,
Marci

nem bugmentes, de buffer overflow-tól védett nyelvből van egy tucat.

milyen programnyelvben lehet bugmentes programot írni?
milyen programnyelv akadályozza meg a puffer túlcsordulást?
és hasonló hibákat?

[kiegészítve]

Nem az a kérdés, hogy bugmentes programot lehet-e írni, hiszen nyilván nem lehet. Az a kérdés hogy átlag fejlesztés során ha egy bug kerül a programba, akkor annak milyen mellékhatásai lehetnek, hogy éli túl ezt a program, hogy reagál egy bugra. Egy managed nyelv esetén pl. teljesen túlélőképes programokat lehet írni, amíg egy C kód dob egy core dump-ot, és jó eséllyel egy megfelelő input adattal még egy calc.exe-t is indít, addig egy java/c#/etc. kód dob egy exception-t - amit vagy elkapsz, vagy nem - beírja a logba, majd szépen fut tovább (amennyiben a fejlesztő is úgy akarja).

De nyelvek, amiknél nincs buffer overflow (mivel nincs pointer aritmetika)

rust, go, java, c#, python, ruby, etc. ezekben a nyelvekben nem tudsz közvetlenül memóriát kezelni alap esetben (unmanaged kódot és java direct memória kérés trükköket egyelőre hagyjuk ki), ergo nem is tudsz puffer túlcsordulást okozni, de legrosszabb esetben is egy exception-t kapsz, nem pedig egy crash-t, amit aztán kihasználhatsz.

Azert egy libc-t ne managed meg ne script koddal probalj meg levaltani, hanem valami olyannal, ami tobbe-kevesbe beteheto a helyere. (oke, Rust talan jo lehet, nemtom mennyire lehet benne C-s libraryt irni, ami a mar meglevo kod ala be tud maszni)
Pl. C++-t extern C-vel viszonylag fajdalommentesen hasznalhatsz libfejlesztesre, es ha betartasz bizonyos szabalyokat, es lecsereled a buffereket valamilyen okosabb class-ra, sebessegben alig vesztesz, es buffer tulcsordulastol (meg par hasonlo hibatol) megis vedve leszel. Referenciaszamlalast is betehetsz akar.

Meg a longhorn kornyeken megprobalt az MS managed code-ra lecserelni mindent, es a vege annyira lassu lett, hogy kutatasi projectkent adtak csak ki https://en.wikipedia.org/wiki/Singularity_%28operating_system%29 . Erdekes kiserlet egyebkent.

Persze uj nyelv, uj OS, uj mindenfele eseten megteheted, hogy az egyebkent majdnem mindennek alapot ado C-t lecsereled ahol tudod. Irsz a sajat nyelvedhez sajat futtatokornyezetet, minden mast leszarsz. Ha ugyes vagy, kozvetlenul kernelhivasokkal is megoldhatsz mindent, es akkor csak a kernel lesz alattad C-ben (vagy azt is ujrairod, ld. Singularity).

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

Nem most kellene megtenni, hanem mondjuk 20 évvel ezelőtt kellett volna. A linux kernelt kb. meg lehetne hagyni, a többi, a felett lévő dolgok nagyjából kuka (legalábbis a c részek). Na, ez lenne egy nagy előrelépés a biztonság felé. Ami nekem furcsa, hogy szoktak open source termékeken coverty-t és hasonlókat futtatni. libc-n hogy hogy nem sikerült?

Coverityvel eleg rossz a tapasztalatom. Amennyit lattam belole, az alapjan rengeteg fals pozitivot adott (eszre nem vett hibak aranyat nem ismerem, azt ugye nem jelzi), de mas feladatom volt, szoval nem turtam bele annyira magamat.
20 eve meg kevesbe lett volna eroforras a plusz ellenorzesek beiktatasara. Akkoriban meg mindenki szetoptimalizalt mindent, nem veletlenul. A MS kb. 10 evvel kesobb probalkozott, es nekik sem ment akkor meg.

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

Azon kivul amit Nyosigomboc emlitett - lassu volt 10 eve, az ujrairasnak (ugy altalaban nem csak ebben a szituacioban) anyagi vonzata is van amit senki nem akar bevallalni. Meg so ido. teszteles stb. Ez nagy cegeknel is ervenyes, ujrairatni nem igazan szoktak hacsak mar dol ossze a haz :) inkabb szeretnek uj ficsoroket kiadni mert igy elmagyarazhatak a reszvenyeseknek hogy nem megy el feleslegesen a penz :)

Szerintem c++ konyvtarak megfelelo vedelmet adnanak.

"hogy éli túl ezt a program"

Kezdő programozók hibás elgondololása, hogy a programnak túl kell élnie a hibát.
--
ulysses.co.hu

Nem, a program csak crash-eljen össze mondjuk egy hibás inputra... remek elképzelés...

Én ugyan nem értek az Erlanghoz, de nemrég jött egy ilyen szembe Twitteren és elolvastam:

http://ferd.ca/the-zen-of-erlang.html

Erlangnál a slide szerint a nyelv része, hogy crash-elhet szándékosan.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

http://c2.com/cgi/wiki?LetItCrash
http://c2.com/cgi/wiki?FailFast
https://en.wikipedia.org/wiki/Fail-fast

Jobb lehet nehany esetben, ha egy hiba nem rejtozkodik honapokig, hanem kiderul hamar es restartolodik a process egy stabil felugyelo kornyezet altal.

A 'filozofia' mogotte:
Tudod, hogy milyen hibak lehetsegesek, es azokkal tudod is, hogy mit kezdj. (Ez egyebkent barmilyen projektnel jol jon)
Ha esetleg olyan state-be kerul a programod, amire nem gondoltal, akkor inkabb faileljen el, es induljon ujra, ugy kevesbe okozhat kart.

Nagyrészt egyetértek, bár szerintem itt is valamiféle középutas megoldás a jó. Lennart Poettering amúgy az általad említett szemléletet vallja szerintem elég szélsőségesen, sokak életét megkeserítve ezzel.

A hibák más rétegben történő elfedése valóban nem szerencsés, de lehet apróbb, például input paraméterekben történő értelmezési tartományra vonatkozó ellenőrzéseket tenni, vagy akár maszkolni. 8 elemű táblázat byte-os inputja esetén egy AND 7 ne fáj senkinek, s lehet rá mondani, hogy ez nem hiba elfedés, hanem az alsó 3 biten várja az indexet, a felső 5 biten viszont bármi, akár szemét is lehet. Ekkor a hívó függvény ezt tudatosan ki is használhatja, csak megfogalmazás kérdése, hogy nem hibaelfedés, hanem tulajdonság.


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

nem, szerintem ő nem ezt vallja. A fail fast arról szól, hogy ha nem tudod, hogy mi volt a baj, és hogyan kellene kezelni, akkor crashelj el, ne veszélyeztesd az adatbiztonságot. Lennartnál az alapján amit láttam az van, hogy tudjuk mi a baj, le is lehetne épp kezelni (aka elfedni), csak szerinte nem ott kell megoldani, és pont.

Van ebben is igazsága egyébként, de a két dolog imho nem ugyanaz.

Valóban, én nem értelmeztem jól, mire is gondolt a költő. :)


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

+1

Ja, csak a C könyvtárnál nem az történik, hogy elcrash-el (ezzel önmagában még nem lenne gond), hanem közben még lefut a calc.exe is ....

Miért ne lenne gond? Számodra mit jelent a crash fogalma? Számomra azt, hogy ellenőrizetlenül fut a program. A CPU kapja az órajelet, fetheli az op. kódot, hajtja végre, csak már fene sem tudja, hogy honnan és mit.


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

nem, az elcrashel az azt jelenti, hogy a program nem fut sehogy sem. Meghal a picsába, úgy ahogy van.

A gond azzal van, hogy ezután valami még tovább fut.

Mi az, hogy meghal? Leáll az órajel generátor? Kész, mára ez volt az utolsó utasítás, amit a CPU végrehajtott?

Ha arra gondolsz, hogy kivétel keletkezik, a kernel beszántja a futó process-t, akkor értelek, de mi van akkor, ha a lefoglalt tárterületen belül kanászodik el a kód? Nem történik illegális területre címzés, így végrehajtódik, aminek nem kellene.


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

Az viszont nem crash. A process fut tovább, a kernel ütemezi. Az egy dolog, hogy nem azt hajtja végre, amit kell. De maga a process nem halt le (mert a process kivételes leállása a crash).
https://en.wikipedia.org/wiki/Crash_%28computing%29

A lényeg a security implication of crashes rész: ha egy program elcrashelhet, akkor azt a crasht fel lehet használni kódfuttatásra.

OK, akkor definíciós nézeteltérés volt. Amennyiben a crash alatt nagyjából a SIGSEGV-t értjük, akkor jó. Számomra már az is crash, ha a program nem azt csinálja, amit a programozó megfogalmazott. Ilyen például, ha túlcímez a tömbön, a kódból ez nem látszik, mert csak a konkrét indextől függ futásidőben, de ez a címzés még a folyamat által lefoglalt területen belül történik. Nagyjából ezekből van a baj.


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

A program mindig azt csinálja, amit a programozó megfogalmazott. Az egy más kérdés, hogy a programozó nem figyelt, rosszul fogalmazott, és túlcímzés lesz a dologból.

Értsd jól. :) Szándékosan nem azt írtam, hogy amire gondolt. Olyasmire gondolok, hogy nem látszik a kódból, mert természetesen változó az index érték, de ez jöhet inputból, amit viszont nem megfelelően ellenőriztek, és máris kész a baj.


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

És mindez azért van, mert a csodás C nyelvben a tömbindexelés operátor nem más, mint egy tetszőleges memóriacímzési művelet. És ez baj. Ugyanis a tömb az egy eléggé absztrakt adatstruktúra (egy indexelhető kollekció), nem pedig memóriaelemek egymás után. Például csak teljesítménybeli okai vannak, hogy a tömbelemek egymás után vannak a memóriában, ezt maga az adatstruktúra egyáltalán nem indokolja.
Eleve a tömb mint absztrakt adatstruktúra meg sem kéne engednie, hogy túlcímezzék, magas szintű nyelvekben, ahol a tömb nem csak syntax sugar, ott ennek van is szép megoldása.
Az, hogy C-ben a tömb nem más, mint egy syntax sugar, az sajnos ide vezet.
Nem véletlen, hogy nem jó dolog C-ben biztonságkritikus kódot írni, nem véletlenül létezik MISRA-C coding standard stb. Mert kódolási patternek kellenek ahhoz, hogy a nyelv hülyeségeit a programozók megoldják.

köszönöm, hogy ilyen szépen összefoglaltad, pontosan erre gondoltam.

De ne felejtsd el hogy amikor a c-t kitalaltak akkor 12 KB memoria tartozott egy szuperszamitogephez, tehat konnyeden atlattak az egesz software-t amin dolgoztak. ASM es gepikod utan megvaltas volt hidd el :) 80-as es 90-es evekben a CPU-k teljesitmenye meg alacsony volt tehat annyira nem igazan tudtak mivel felvaltani aztan kesobb "sullyedt le" alacsony szintu konyvtarakba mert magasabb szintu nyelvek jottek.

Manapsag C-t csak kernelben vagy firmware kodban latok szivesen.

De épp ezaz: miért élünk még szoftveres szinten a 70-es években? A UNIX-ot is 1970-ben találták ki.

Btw. a libc a UNIX filozófia ellen megy: Do one thing and do it well.

Nos, a libc-ben van stringkezelés, van hálózatkezelés, van locale kezelés, van minden. Baromira nem UNIX. Az, hogy a POSIX előírja, hogy milyen runtime környezet kell az alkalmazásoknak, még nem jelenti azt, hogy azt egy libraryként kéne szállítani, és a rendszer legfontosabb részének kéne lennie.
Például miért ne lehetne mondjuk lecserélni csak úgy a syscall réteget, vagy a locale részt, vagy a networking részt, anélkül, hogy a teljes libc-t lecserélnénk? Őrület.

Lásd lentebb. Az, hogy megáll, nincs tovább, az a program (még csak nem is processz) nem csinál többet semmit.

Szerintem másik oldalról nézed a dolgot, te alapvetően az implementációt nézegeted, az meg egy design pattern. Azt mondja, hogy olyan program logikát kell írni, ami ha olyan helyzetbe kerül, ahol nem tudja, mit kell tennie, akkor minél rövidebb időn belül gondoskodnia kell arról, hogy leálljon, és a kontrol visszaszálljon a szülőre. Nem az a lényeg, hogy az OS által megadott kereteket betartja-e, hanem éppen az, hogy azon belül az önfelügyelet működjön.

Ezeknek technikailag lehetséges megvalósulása pl az unhandled exceptionnel jelezni a keretrendszernek, hogy dal vége, takaríts, mondjuk javaban, vagy egy combos segfault c ben. Ez utóbbinál egy implementációs probléma, hogy utána adott esetben a fasz se tudja mi fog futni...

s/fetheli/fetcheli/


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

aha, szoval akkor szerinted ha te nem latsz pointert egy kodban, es nincs pointer aritmetika egy nyelvben, akkor az mar "biztonsagos" es nem is lehet invalid inputtal buffer tulcsordulast kivaltani?
okejo.

nem igy van?

Hiába nem tudsz ezekben közvetlenül memóriát kezelni, ha kell alája egy C-ben írt interpreter/VM/standard lib, ami a memóriakezelést megcsinálja neki - na abban ugyanúgy ott tud lenni egy ilyen bug, és pont ugyanott vagy. Azt kéne látni, hogy a memóriakezelést a hardver nem fogja helyetted megcsinálni, tehát egyszer, valamikor, valakinek meg kell jól írnia - és ez szinte biztos, hogy C-ben történik.

Másfelől pedig, léteznek a korrekt memóriakezelésre C-ben is megoldások, csak használni kell. Persze azt értem, hogy milyen fasza dolog, ha az ostoba fejlesztőktöl származó kódot egy fordító fordítja át C-be/gépi kódra, de ezt C-nél is meg lehet játszani.

+1

Bugmentes programokat nem, de buffer overrunt el lehet kerülni, ha pl. olyan nyelveket használsz, mint a Pascal, vagy az Ada.

AFAIR a VMS security alrendszerét Adában írták.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

many eyeballs volt már?

Mindenki ugy gondolta hogy a tobbi mar atnezte es nem talalt benne hibat. :)

marmint hogy ez egy jo peldaja annak hogy azert mert elerheto volt a forraskod es barki megnezheti ezert sikerult is valakinek addig neznie mig talalt benne egy hibat?

Nem éppen így történt: egy SSH kliens segfaultot vizsgáltak, amikor ráakadtak erre.

tehát pontosan így történt.