A Linux hibájából válhatnak feltörhetővé a Windows-zal működő gépek

A Linux hibájából válhatnak feltörhetővé a Windows-zal működő gépek
2020-07-30T11:59:00+02:00
2020-08-06T10:34:18+02:00
2022-10-18T09:10:40+02:00
  • Nem, hát, mivel a javítás bootolhatatlanná tette a gépüket

    Nekem Ubuntu van a masináimon, és én nem tapasztaltam ilyen gondot (bár tény, hogy a hibát javító hibás patch is javítva van már a jelenlegi 3.27-es GRUB2-vel).
    Mutasd a teljes hozzászólást!
  • Felvetődött a kérdés: van-e C-- nyelv. Van. C-- - Wikipedia
    Másik dolog, létezik-e olyan C ahol van index- és túlcsordulás ellenőrzés.
    Van. Gamestudio Specifications
    Mutasd a teljes hozzászólást!
  • A Debian-t is érinti: #966575 - grub-pc: error: symbol `grub_calloc' not found. - Debian Bug report logs
    (Velem eddig nem jött szembe szerencsére.)
    Mutasd a teljes hozzászólást!
  • Szóval aki rendszeresen frissíti a rendszereit, az nincs és nem is volt kitéve a BootHole-nak

    Nem, hát, mivel a javítás bootolhatatlanná tette a gépüket: Red Hat and CentOS systems aren’t booting due to BootHole patches
    Mutasd a teljes hozzászólást!
  • Csak érdekesség:

    Ez a cikk itt a PCForum.Hu-n július 30-án jelent meg (mármint a BootHole nevű, a GRUB2-ben azonosított indexhatár-ellenőrzés hiánya miatti biztonsági rés). Másnap, július 31-én megjelent a 3.26-os GRUB2, amiben javították a bug-ot. Ebben az az érdekesség, hogy a 31-i megjelenés is már késői, mert Chris Coulson, a javítás posztolója már 28-án posztolta a javítást a fenti bug-ra.
    Forrás: 2.02~beta2-36ubuntu3.26 : grub2 package : Ubuntu

    Vagyis hamarabb jelent meg a javítás, mintsem hogy itt a PCForum.Hu-n olvashattunk volna a bug-ról, sőt, még a BootHole-t biztonsági szakértők publikálása előtt is (ami 29-i dátummal olvasható).
    Forrás: There’s a Hole in the Boot - Eclypsium

    Szóval aki rendszeresen frissíti a rendszereit, az nincs és nem is volt kitéve a BootHole-nak, ha azt korábban, annak ismerete nélkül nem tudták kihasználni a támadók.


    Szerk.: Mivel ezt a hozzászólást nem valakinek válaszul írtam, hanem csak úgy "broadcast" beleszóltam a topikba, így a PCForum.Hu motorja ezt a hozzászólást is offtopik-nak értékelte, pedig ez tényleg a cikkhez történt hozzászólást tartalmaz. Ha lehet, ezt kérem szépen orvosolni.
    Mutasd a teljes hozzászólást!
  • Az 1.-2.-3. pontok a jelenlegi processzorokra is igazak

    Nem, azokra nem igazak, illetve elenyésző mértékben igazak. Pont ezért lettek ezek a sajátosságok kiemelve.

    Amúgy a legtöbb magas szintű nyelvi elem (if, while, for, ...) néhány jelenlegi assembly utasítással megvalósítható

    Egyrészt a "for" nem igazán a magasszintű, hanem inkább a lehető legalacsonyabb szintű nyelvi elemek példája. Másrészt az, hogy a "for" hány assembly utasítással oldható meg, igencsak nyelvfüggő dolog.

    A jelenlegi processzorokban is vannak nagybonyolultságú részek (utasítás előrejelzés, többszintű cache, ...). Ezeket simán gyártani tudják.

    Ezek abszolút nem bonyolult, sőt, végtelenül primitív dolgok. A modern nyelvekben elérhető programozási szerkezetekhez képest mindenképpen. Ráadásul ezek nem is egy, a processzor által kifelé, a rajtuk futó kódok számára biztosított szolgáltást képeznek, hanem a chipek belső implementációs sajátosságát - ezért sincs sok értelme előbbiekhez hasonlítani őket.
    Mutasd a teljes hozzászólást!
  • Az igazi baj az, hogy  ha egy programozó nem ismeri az strlen implementációját, akkor egy kódban simán ötször-hatszor meghívja az strlen()-t, ahelyett, hogy egyszer meghívná, letárlná a hosszt, és azt használná tovább. Ég és föld a különbség a két módszer között. Viszont a másodiknak meg van az a hibája, hogy ha közben módosul a string hossza, akkor hibás lesz a kód. Pascal-ban nyugodtan hívhatod akárhányszor a length() függvényt, nem vesztesz annyi időt, mint C-ben- Ráadásul, ha változik a string hossz, a Pascal length() mindig az aktuális hosszt adja vissza, anélkül, hogy külön vátozóban tárolnád. De már írtam korábban, hogy amíg felül tudod írni a string hosszát, addig a PAscal megoldás sem tökéletes.
    Mutasd a teljes hozzászólást!
  • Az 1.-2.-3. pontok a jelenlegi processzorokra is igazak, ott ez miért nem probléma?

    Amúgy a legtöbb magas szintű nyelvi elem (if, while, for, ...) néhány jelenlegi assembly utasítással megvalósítható. A jelenlegi processzorokban is vannak nagybonyolultságú részek (utasítás előrejelzés, többszintű cache, ...). Ezeket simán gyártani tudják.
    Mutasd a teljes hozzászólást!
  • Nem tudom miért álltak le azok a próbálkozások, hogy magas szintű nyelvek (vagy byte kód) közvetlen futtatására készítsenek processzort. Volt ilyen terv a Java-val, nem tudom mi lett vele.

    Mert kb. semmi értelmük nincs, több szempontból sem.
    1. Korlátozzák a velük használható fejlesztőeszközök körét, és/vagy csak az adott nyelvet használó kódokat tudják hatékonyan futtatni
    2. Nem lehet frissíteni őket (úgy, ahogy pl. egy x86 processzoron át lehet állni a Java 6-ról a Java 11-re vagy akár .NET-re) 
    3. Az esetlegesen felfedezésre kerül biztonsági hibákat nem lehet javítani rajtuk (úgy, ahogy egyébként lehet foltozni egy futtatóplatformot)
    4. Az 1-3 pontok miatt alig van kereslet rájuk
    5. A komplex és magasszintű logika miatt csak nagyméretű chipekben implementálhatók
    6. A nagyméretű chipek fogyasztása magas
    7. A nagyméretű chipek kihozatali aránya rossz (részleges hibák miatt menthetők úgy, mint pl. ahogy egy nyolcmagosból lehet egy négymagos processzort csinálni, ha egy-két mag gyártiási hibásra sikerül)
    8. Az előző pontok miatt nagyon magasak a fajlagos és gyártási költségeik, ezért az áruk is sokkal magasabb, és az üzemeltetésük is többe kerül, mint az azonos teljesítményre képes általános célú processzoroké.

    Nem nyelvspecifikus processzorplatformok közül is a legtöbb soha nem tudta megvetni a lábát, illetve pár évnyi, jellemzően veszteséges próbálkozás után kihaltak. Itanium, Alpha, stb.

    De a legnagyobb probléma az itt tárgyaltak vonatkozásában velük, hogy pusztán attól, hogy a processzor natívan tud értelmezni magasszintű utasításokat, nem következik, hogy akkor mentesek lesznek a biztonsági hibáktól. Ugyanakkor a hagyományos megoldásokkal szemben a felfedezésre kerülő implementációs hibák nem vagy csak nagyon körülményesen javíthatók rajtuk, elkerülő megoldások alkalmazása rajtuk pedig a legtöbb esetben kizárt.
    Mutasd a teljes hozzászólást!
  • A java-s processzor nagyon jó ötletnek tűnik, csak az egyben azt is jelentené, hogy a nem java-ban írt programokat nem tudnád futtatni. Persze lehet emulálgatni stb, csak annak meg a teljesítménye lenne problémás.

    Inkább csak érdekesség, de egyrészt léteznek ilyen processzor tervek (Java processor - Wikipedia), talán processzorok is, másrészt egy részük RISC-jellegű és jól futtat natív kódot is (pl. az ARM processzor biztosan, de a picoJava-ról is azt írják).
    Mutasd a teljes hozzászólást!
  • Mondjuk hasonlítsunk össze C-ben egy 4Kbyte és egy 4Kbyte + 1 byte hosszú karakter sorozatot (az első 4K karaktere legyen egyenló a két sorozatnak).

    Ilyet visszafele is lehet: végy két azonos hosszúságú stringet, amik rögtön az első karakterükben eltérnek. A Pascal kétszer annyi összehasonlítás után ismeri fel az eltérést, mint a C.
    Amúgy a példád kizárólag a két string azonosság-vizsgálata esetén releváns, ha pl. rendezni akarnád őket, akkor pusztán a hosszuk alapján már nem lehet következtetni semmire.
    Mutasd a teljes hozzászólást!
  • A java-s processzor nagyon jó ötletnek tűnik, csak az egyben azt is jelentené, hogy a nem java-ban írt programokat nem tudnád futtatni. Persze lehet emulálgatni stb, csak annak meg a teljesítménye lenne problémás.
    Mutasd a teljes hozzászólást!
  • Ismét továbbgondoltam a dolgot, és bár tényleg már teljesen off-topik, de ezt azért még ideírnám. Azt hiszem a C nyelv fejlődésében meghatározó volt a PDP-11 processzorának utasításkészlete. Ha jól tudom, PDP-11-en fejlesztették a Unix-ot és a C-t. Ha nem így van, elnézést, lusta vagyok utána nézni. Az viszont teljesen biztos, hogy a CPU utasításkészletének áttervezésével, optimalizálásával, hatni lehetne a biztonságosabb nyelvek tervezésének irányába. Nem tudom miért álltak le azok a próbálkozások, hogy magas szintű nyelvek (vagy byte kód) közvetlen futtatására készítsenek processzort. Volt ilyen terv a Java-val, nem tudom mi lett vele.
    Mutasd a teljes hozzászólást!
  • 1. Azokat, akik azt írták, hogy pazarlás lett volna azokon a gépeken egy tömbindex ellenőrzés, arra kérem, írjanak egy rövid értekezést mekem arról, vajon mennyire pazarló az strlen() függvénye a C-nek. 

    Egyrészt az, hogy a strlen() (ami alatt nyilván a zérus-terminált sztringekre gondolsz, csak nem tudod jól megfogalmazni) pazarló lenne, az nem jelenthető ki egyértelműen. Memória használatában pl. kifejezetten takarékos más megoldásokhoz képest. És feldolgozások során is lehet, hogy hatékonyabb. Mert pl. zérus-terminált sztringek összefüggő folyamából sokkal gyorsabban és kevésbé pazarló módon lehet LF vagy CR sortöréses szövegfájlt készíteni (és viszont), mint bármilyen más ábrázolási módból.

    Másrészt ha el is fogadjuk, hogy a zérus-terminált sztringek pazarlók, az se változtat azon, hogy az állandó határellenőrzések is azok lettek volna. Tehát a zérus-terminált sztringek használta nem érv, hanem ellenérv a még azon felül is plusz órajelciklusokat felemésztő határellenőrzések alkalmazására, ami még lassabbá tette volna a programokat, mint amilyenek azok a zérus-terminált sztringek miatt eleve lettek volna.

    Harmadrészt pedig - és talán ez a legfontosabb - a C nyelv igazából nem kényszerít senkit a zérus-terminált sztringek használatára, és nem akadályozza meg azt, hogy valaki akár Pascal-szerű ábrázolásban használjon sztringeket. Tehát akinek esetleg fontos volt, hogy ne pazaroljon erre se órajeleket, illetve olyan típusú feldolgozást végzett, amikben ez plusz órajeleket jelentett volna (lásd fent), az az strlen() és társai helyett használhatott az ő számára hatékonyabb ábrázolást a karakterfüzérek kezelésére.

     De az igazság az, hogy ha valaki tényleg biztonságos nyelvet akar készíteni, akkor bizony nagyon össze kell szednie magát. Kicsi az esély, hogy nagy software gyártók ezzel foglalkozzanak, az egyetemeket pedig úgy látom szintén nem érdekli ez a kérdés.

    Nem olyan régen linkeltem ezeket:
    Rust-ra áll át C-ről és C++-ról szoftvereiben a Microsoft?
    Rust-ban is programozhatóvá teszi a modern Windows alkalmazásokat a Microsoft
    Szuperbiztonságos új programozási nyelven dolgozik a Microsoft

    Szóval - mint az előbb is írtam - nem a Microsoft itt a probléma, és nem a Microsoft (vagy akármelyik másik szoftverfejlesztő) az akadálya annak, hogy a nyelvek és a szoftverek biztonságosabbak legyenek. Hanem az, hogy a vásárlók nem hajlandók ennek költségeit (pl. a megnövekedett tesztelési igényt, vagy a meglévő szoftverek újraírását egy biztonságos nyelvben) megfizetni. Mert, hogy egyébként nekik is bőven elfogadható az a szint, ahol azok vannak, és nem spórolnának annyit egy hibamentes szoftverrendszerrel, mint amennyibe az kerülne nekik.
    Mutasd a teljes hozzászólást!
  • Szerintem ez az indexhatár-ellenőrzés már nagyon offtopic (eredetileg ez a téma csak a GRUB2 ugyanezen bug-ja okán kapcsolódik ide), de érdekes a téma.

    Véleményem szerint indexhatár-ellenőrzést 3 módon lehet megcsinálni:

    1) A programozó gondoskodik róla. De ez egyrészt nagyon megbízhatatlan megoldás, mert mi van, ha a programozó elfelejti, nem törődik vele, vagy magában az indexhatár-ellenőrzésben vét hibát? Ráadásul így mindegy egyes programban ezt külön-külön meg kell csinálni, feleslegesen növelve azok méretét. Ez a "csináld magad" filozófia tipikusan a C nyelv velejárója.

    2) A fordító program kiválóan alkalmas lenne indexhatár-ellenőrzésre, hiszen a fordító tisztában van az összes változóval, így azok hosszával és struktúrájával is, azaz neki "kényelmes" ezekhez előre megírt indexhatár-ellenőrzéseket beszúrnia a kódba. A Pascal ezt csinálja. De akár inline-assembly-vel ez az ellenőrzés simán megkerülhető, azaz ez sem elég biztonságos.

    3) A legjobb, legbiztosabb megoldás erre az operációs rendszer. Ennek felügyelete alatt fut bármely program, azaz ha az OS felügyelné az indexeket, akkor esély se lenne azokat túlcímezni, még véletlenül sem. Bár igaz, hogy ehhez a CPU védelmi kivételkezelését is kicsit fel kell okosítani, de ezen nem múlhatna a dolog. Viszont amennyire tudom, ma még egyetlen OS sem tartalmazza ezt (vagy csak nem tudok róla).

    +1) Ez kakukktojás: Az egész x86(-64) architektúrát el kell felejteni, hogy valóban biztonságosan legyenek futtathatók a processzek. A .NET vagy a Java lenne pillanatnyilag erre a legalkalmasabb (mint önálló architektúrák), de megint csak nem tudom, van-e bennük automatikus indexhatár-ellenőrzés.

    Megjegyzés: Kicsit elkalandoztunk Prog.Hu témába...
    Mutasd a teljes hozzászólást!
  • Kicsit gondolkodtam a dolgon:

    1. Azokat, akik azt írták, hogy pazarlás lett volna azokon a gépeken egy tömbindex ellenőrzés, arra kérem, írjanak egy rövid értekezést mekem arról, vajon mennyire pazarló az strlen() függvénye a C-nek. Mondjuk hasonlítsunk össze C-ben egy 4Kbyte és egy 4Kbyte  + 1 byte hosszú karakter sorozatot (az első 4K karaktere legyen egyenló a két sorozatnak). Ennél nagyobb pocséklását az időnek nem tudom elképzelni. Számomra kissé abszurd spórolni egy index ellenőrzéssel, ugyanakkor ahelyett, hogy tárolnám egy karaktersorozat hosszát, végig kell kúsznom rajta, amíg meg nem lelem a végét jelző bináris nullát. Arról már nem is szólok, hogy  ha felülírnám esetleg azt a nullát, akkor vajon meddig tartana az strlen() futása.

    2. Igazságtalan lenne, ha nem ismerném el, hogy bizony Pascal-ban is lehet azért csúnya dolgokat csinálni. Hiába a tömb index ellenőrzés, ha átírom egy string hosszát nagyobbra, abból probléma lehet. De lehet a pointer-ekkel is olyasmit csinálni, amivel olyan helyekre is írhatok, ahová nem lehetne. Ha Dos alatt csináltam ilyesmit, a gép egyszerűen lefagyott. Védett módban már jobb volt a helyzet. De az igazság az, hogy ha valaki tényleg biztonságos nyelvet akar készíteni, akkor bizony nagyon össze kell szednie magát. Kicsi az esély, hogy nagy software gyártók ezzel foglalkozzanak, az egyetemeket pedig úgy látom szintén nem érdekli ez a kérdés.
    Mutasd a teljes hozzászólást!
  • Igazad van, nem válaszoltam. Jelenleg nincs jó válaszom. Valószínűleg ezért is nem írok operációs rendszert, vagy ahhoz való tartozékokat, mert nem tudnék most erre egy jó nyelvet mondani.
    Mutasd a teljes hozzászólást!
  • Teljesen igazad van!
    Elképzelhető, hogy valaki be bootol egy pen drive -ról! Majd mindenfélét megváltoztat. De az a gép akkor kint van a világban! Tehát senki semmiféleképpen sem tudja megvédeni. Elvégre szabadon hozzáférhettek!! Miért éppenilyen buherát tettek volna vele?
    Mutasd a teljes hozzászólást!
  •  lenne rendes string-je,

    Egyetértek.

    tömb index határ ellenőrzés, verem túlcsordulás és aritmetikai túlcsordulás elleni védelem,

    Akkori kapacitással ez pazarlás lett volna.

     a header file-okat is el kellene felejtenie.

    Ízlés kérdése.
    Mutasd a teljes hozzászólást!
  • Volt rajta Turbo Pascal, szintén bekapcsolható tömbindex ellenőrzéssel és túlcsordulás védelemmel.

    Egyrészt a Pascal egyrészt egy kifejezetten nem valós feladatok megoldására, hanem oktatási célokra kidolgozott nyelv volt. Ennek megfelelően az inkább volt arra kihegyezve, hogy a programozót megvédje a saját hülyeségeitől, mint hogy a lehető legnagyobb teljesítményt nyújtsa. A C-hez képest mindenképpen. Másrészt a Turbo Pascal-ben is simán lehetett túlcímezni pufferterületeket, még akkor is ha az ember bekapcsolt minden, egyébként alapból nem bekapcsolt ellenőrzést is, de pl. dinamikus memóriából foglalta az ember, típusátértelemezéseket végzett, stb.

    És volt rajta Clipper.

    Na, a Clippernek aztán végképp' soha semmi köze nem volt a teljesítményorientált működéshez és a takarékossághoz.

    Ja, és a 70-es évek óta eltelt 50 esztendő, és a C SEMMIT sem változott.

    Ez a kijelentés legfeljebb úgy helyes, hogy te nem tudsz róla, hogy bármit is változott volna. Mert amúgy egy rakás új kiadása is megjelent azóta: C (programming language) - Wikipedia

    Egyre másra jönnek ki a gagyibbnál gagyibb nyelvek, holott a C-ből lehetne mondjuk egy C-- nevű nyelvet csinálni, ami biztonságos lehetne. 

    Ami nem C lenne, hanem C--, és ami nem lenne képes az évtizedek alatt felhalmazódott C-s kódbázisból szinte semmit sem használni. Egyébként meg millió ilyen nyelv született már a C óta, ti. ami így vagy úgy, de a C továbbgondolásának tekinthető. Ha valakinek az kell, azokat fogja használni. 

    Én nem vagyok házilag C ellenes, csak az bosszant, hogy senki sem tesz semmit, újra és újra eltűrjük ezeket az amatőr hibákat, és a világ nem változik semmit.

    Lásd amit arról írtam, hogy a piac mit hajlandó megfizetni. Köztük te is, illetve te sem. Hiszen nyilván te sem lennél hajlandó milliókat kifizetni az asztali gépeden futó OS licencére csak azért, hogy arról formálisan (is) bizonyított legyen helyessége.

    Lehet, hogy mégis szimulált világban élünk, és a szimuláció futtatója rosszindulatú?

    Nem, csak látod te sem látod és érted, hogy te magad éppen úgy a probléma része vagy. És amíg a problémát sem sikerül helyesen azonosítani és felmérni, addig nyilván a megoldást is igen nehéz megtalálni rá.

    Bár a dolog ott kezdődik, hogy ez igazából nem olyan nagy probléma, mint azt így elmélázva a dolgon be akarod állítani, még neked sem. Mert ha annyira nagy probléma lenne, akkor tennének is ellene az emberek.

    Valójában a programok bugossága (azon a szinten ahol ez a Windows és társai esetében áll) csak egy relatív kis probléma, aminek megoldása sokkal több másik problémát keletkeztetne. Pl. a hatékonyság, a fejlődés és a gazdaságosság terén.

    Akkora lépésekben meg amennyiben indokolt, haladunk azért a megoldása felé azzal, hogy már régóta állunk át biztonságosabb nyelvekre és eszközökre (mint pl. C++, #, Rust, stb.), illetve vezetünk be mitigációs technikákat (mint pl. védelmi kivételek a processzorokban, ASLR, stb.)
    Mutasd a teljes hozzászólást!
  • Az eredeti kérdésemre nem válaszoltál: miben kellett volna írni c és asm helyett?
    Mutasd a teljes hozzászólást!
  • Dolgoztam a KSH-nál 768 KByte-os memórával rendelkező TPA-1148 gépen, RSX-11M operációs rendszeren. Azon is volt C fordító, nem volt benne tömb index ellenőrzés. Volt rajta Pascal fordító is, tömbindexet ellenőrzött már az is. És abban írtam a programjaimat. Nem volt lassú, de biztonságos volt, pedig hol volt akkor még hálózat, meg Internet, meg vírusok...

    Sőt olyan nyelvek is voltak, mint a Series-IV, amiben nem is lehetett kódot írni. Táblázatokat kellett kitölteni, amivel leírtad a képernyőket és az ellenőrzéseket. Legenerálta a programot. Abban nyilván lehetetlen volt puffertúlcsordulást előidézni.

    Ott voltak az XT-k, 640KByte RAM-mal. Volt rajta Turbo Pascal, szintén bekapcsolható tömbindex ellenőrzéssel és túlcsordulás védelemmel. És volt rajta Clipper. C-ben írták, de szerintem nem lehetett egy tömb határain kívülre hivatkozni.

    Ja, és a 70-es évek óta eltelt 50 esztendő, és a C SEMMIT sem változott. Egyre másra jönnek ki a gagyibbnál gagyibb nyelvek, holott a C-ből lehetne mondjuk egy C-- nevű nyelvet csinálni, ami biztonságos lehetne. Én nem vagyok házilag C ellenes, csak az bosszant, hogy senki sem tesz semmit, újra és újra eltűrjük ezeket az amatőr hibákat, és a világ nem változik semmit. Hogy egy kis politikát is belevigyek, a C olyan, mint a NER. Mindenki tudja, hogy rossz, de az embereknek valahogy mégis ez kell, és nem hiszem, hogy azért mert mindenki mazochista. Lehet, hogy mégis szimulált világban élünk, és a szimuláció futtatója rosszindulatú?
    Mutasd a teljes hozzászólást!
  • Igen, én is hallottam a Teve utca alatti mínusz x-dik szinten lévő szerverekről. Ez azért más kategória, mint az íróasztalomon lévő desktop.
    Mutasd a teljes hozzászólást!
  • Az assembly még rosszabb ilyen szempontból, az aztán semmilyen védelmet nem ad a programozónak a saját ostobasága ellen. A C nem lenne annyira rossz, ha lenne rendes string-je, és lenne benne tömb index határ ellenőrzés, verem túlcsordulás és aritmetikai túlcsordulás elleni védelem, és a header file-okat is el kellene felejtenie.
    Mutasd a teljes hozzászólást!
  • Igen, jól emlékszel, ez a hőbörgés már régi keletű, kb.a 80-as évek vége óta tart, és legutóbb valóban a Notepad hibájánál adtam elő. És milyen igazam van most is.
    Mutasd a teljes hozzászólást!
  • Akkor miben kellett volna írni a grubot? Egy rendszerbetöltő írásakor a magasszintű nyelvek kiesnek, rust akkor még sehol sem volt, marad a c és az assembly.
    Mutasd a teljes hozzászólást!
  • Ha jól emlékszem, ez a hőbörgés a múltkor, a notepad-os hibánál sem jött be...
    (Akkor az "IME" nevű megkönnyítőprogram okozta a hibát, nem a 'C-nyelv hibás logikája')
    Mutasd a teljes hozzászólást!
  • De láttam már. Az elsőt én magam említettem, a másik kettő meg arra jó, hogy a behatolást detektálják, de azon túl ott már minden mindegy, a rendszer kompromittálva van, és jelen hiba kihasználása nélkül is minden probléma nélkül törhető az adott rendszer. Szoftveresen addig tudunk hatékonyan védekezni, amíg fizikailag nem férnek hozzá a hardverhez, erre írtam amit írtam. A hardver védelme pedig már teljesen más kérdés, és igen, szerintem is mindkettő egyformán fontos, és nem ér semmit az egyik a másik nélkül.
    Mutasd a teljes hozzászólást!
  • Dede, gonoszak és bénák. Az interneten olvastam, hogy Pascal-ban vagy Delphi-ben kell írni mindent: Nagyon csúnya sebezhetőség van a Windows Jegyzettömbben - feltörhetik vele a gépünket
    Mutasd a teljes hozzászólást!
  •  Kernighan és Ritchie szégyellhetné magát, amennyi kárt okozott eddig ez a nyelv, százezer év börtön is kijárna már nekik...

    Egyrészt Kerningham-nak semmi része nem volt a C kidolgozásában, csak azért kapcsolódott össze a neve vele, mert az első, a C-ről szóló könyv társszerzője volt. Másrészt ez nem így működik. Amikor a C-t tervezték, a számítási kapacitások elképesztően korlátosak voltak, a biztonsági jellegű fenyegetések meg gyakorlatilag nullák. Ráadásul a programozási nyelvek elmélete sem járt olyan szinten, hogy akár csak fel is merülhetett volna egy olyan nyelv létrehozása, ami nulla felé közelítő futásidejű overhead mellett képes magasfokú adatbiztonsági garanciákat nyújtani (mint pl. a Rust, de bizonyos értelemben a C++ is ide sorolható.)

    Ezért igazából az ő részükről, illetve Ritchie részéről pont az lett volna a bűn, ha beleraktak volna a nyelvbe olyan ellenőrzéseket, amiknek ott és akkor gyakorlatilag semmi haszna nem lett volna, de pazarolta volna az igen drága erőforrásokat. Ráadásul ha meg is tették volna, akkor is egészen biztosan nem az ő nyelvük lett volna ami olyan elterjedtté vált volna, mint a C, hanem egy másik nyelv, amiből meg hiányoztak ezek az ellenőrzések.

    Egyébként is egy kényelmes dolog a nyelvek alkotóira, vagy akár a programozókra tolni annak felelősségét, hogy biztonsági vagy sok biztonsági hiba van a programokban. Miközben a valóság az, hogy azért van ez, mert a felhasználók nem hajlandók a programok hibátlanságát vagy legalábbis sokkal magasabb fokú hibamentességét (és az ennek eléréséhez szükséges plusz munkát és erőforrásokat) megfizetni.  Ami egyébként az ő részükről a legtöbb esetben szintén teljesen racionális döntés, mert értelmetlen lenne Macikának 30.000 helyett 3 millió forintba kerülő, szuperbugmentes operációs rendszert venni a gépére csak azért, hogy kétévente egyszer egy random lefagyás miatt nem vesztse el fél óra munkáját, ami maximum pár ezer forint kárt, kiesést okoz a termelésben (ti. mármint az, hogy újra kell gépelnie).

    Ahol meg fontos a dolog, mert ennél sokkal nagyobb károk keletkezhetnek, ott általában költenek is a dolgokra, beleértve a hardver biztonságossá és megbízhatóvá tétele mellett a használt szoftverek valamiféle jóval magasabb fokú tesztelését és minőségbiztosítását is. De látni kell, hogy ez a piac a fentiek miatt elképesztően kicsi, és a felhasználók legtöbbjének az ár sokkal, de sokkal fontosabb a teljes bugmentességnél. És pontosan ezért olyan bugosak a programok, amilyenek - nem azért, mert Ritchie gonosz vagy béna volt, és nem is azért, mert a mai programozók gonoszak vagy bénák. Vagy legalábbis nem azon a szinten és nem a legtöbb esetben, ahol a Windows, Linux és vele összehasonlítható szintű szoftverek mozognak.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd