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

Bug

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.

( evone | 2016. 02. 17., sze – 12:23 )

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

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.

È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

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

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

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

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)

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

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

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.

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:

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

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

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.

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.

( locsemege v | 2016. 02. 17., sze – 12:25 )

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

( sz332 v | 2016. 02. 17., sze – 21:49 )

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.

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.

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

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.

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

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

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

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.