Linux - a legnagyobb fenyegetés Amerika számára?
2004-01-23T11:52:26+01:00
2004-02-08T20:33:14+01:00
2022-07-27T14:27:41+02:00
  • Akit komolyabban erdekel, itt egy nagyon jo osszefoglalo a temarol:
    Secure programmer: Countering buffer overflows

    netchan
    Mutasd a teljes hozzászólást!
  • A linket jo esellyel en postoltam.

    Amit az OpenBSD-sek csinaltak az egy k nagy hekk. A temat legjobban vago csapat hosszu honapokig gyurte az i386-ot mire kiagyaltak ezt a tobbe-kevesbe mukodo megoldast, ami:
    - messze nem egyenerteku azzal, ami az ezt hw-bol tamogato processzorokon elerheto,
    - teljesen mas megkozelites, mint amirol itt szo van
    Ilyen jellegu megoldas garantaltan nem fog bekerulni egyetlen mainstream OS-be, max mint patchkit.
    Mutasd a teljes hozzászólást!
  • Csak arra gondoltam, hogy fölösleges ezerszer ismételnem magamat, mert mindig visszakapom a flat modell cimű hozzászólást, aminek persze alapja van, csak nem válasz a kérdésre.
    Van egy másik topic, ahol valaki küldött egy linket arról, h az openBSD-ben hogyan oldották meg ezt az ügyet.
    Szóval akkor összefoglalva: mégiscsak megoldható a 386-oson és abszolute nem érdekel, hogy ettől elméletileg most flat-e a modell v. nem, a lényeg az, hogy stackot nem lehet végrehajtani
    A megoldás portolható, tehát linux-on is lesz (van?)

    itt a link

    És ha jól láttam, Sting-nek is olvasnia kellett. Tehát itt nincs másról szó, mint hogy vannak kifejezett hülyék (mint pl. én) és vannak okosok, akik a szent igéket mormolva igazságot osztanak és lekicsinylően ajkat biggyesztenek.
    De ha szabály a tények figyelmen kívül hagyása, akkor rendben van, akkor tényleg NEM én voltam türelmes, hanem az, aki a szent igét n-edszer elmormolta.
    Mutasd a teljes hozzászólást!
  • Fejtsd mar ki bovebben.
    Mutasd a teljes hozzászólást!
  • No comment
    Mutasd a teljes hozzászólást!
  • ehh, ez a kerdes vagy otodszorre jon elo valtozatlan formaban... csodalom a turelmed
    Mutasd a teljes hozzászólást!
  • Szóval a 386(?) / 486 óta megvan a lehetőség hardverileg

    A flat modellhez - amit a Windows és a Linux is használ - nincs meg. A védelmet ennél a modellnél nem a szegmens-leíróban, hanem a lapleíróban megvalósított futtatásvédelem jelentheti, ami az eddigi x86 processzorokban nem volt meg. Az AMD most az Athlon64-ben megcsinálta (ti. definiált egy no-execute bitet a lapattribútumokhoz), és valószínűleg az Intel is követni fogja.
    Mutasd a teljes hozzászólást!
  • De ez egészen pontosan winen is igy van. Ahogy a "de akkor nyoma van" is szóról-szóra igaz winen


    Mondtam, hogy nem?
    (nem is szivesen mondanám, mer win-hez keveset értek.)

    Szóval van itt két tábor, de tkp-en egyiknek sincs igaza: aki linux-os az nem ismeri a win-t elég mélyen, aki meg win-es az meg nem ismeri a linux-ot elég mélyen. Én élvezem, mert olyan dolgokról értesülök, amikre vszinüleg valamikor szükségem lesz - desktop windoz az nagyon tartja magát. De eléggé elmentünk az eredeti témától
    Mutasd a teljes hozzászólást!
  • Hát az rdp nem akadozik 384-en, de 56k-n se...
    Ezt csak megerősíteni tudom én is. A konzol villámgyors (felismerhetetlenül pörögnek a sorok felfelé, ha folyamatosan ír egy program a konzolra),

    Jó tudni
    (Már csak azt kéne megoldanom, hogy a linux desktopomon fussanak a win management eszközei és akkor pá rdesktop )
    Mutasd a teljes hozzászólást!
  • Mert biztos mar megoregedtel.

    Bizony, bizony

    Vagy az X ssh tunelingjere gonoltal?

    Gondoltam rá, de csak ha nagyon muszáj (meg ha nagy a sávszél és ölég gyors az ellengép)

    Amúgy szeretném leszögezni, hogy alapjában véve csakis a GUI-t szeretem, lehetőleg 1 kattintásosat, kérdés és választási lehetőség nélkül. A baj az, hogy nem mindig oldja meg a bajokat a kattintás
    Mutasd a teljes hozzászólást!
  • mert x86 processzorokon minden memóriaterület ami olvasható, az egyben futtatható is (a CPU nem különbözteti meg ezt a két attribútumot).


    Ez egy totális tévedés: a CPU megkülönbözteti Már egyszer írtam, de most direkt meg is néztem: INTEL i486 Microprocessor Programmers Reference Manual, 5. fejezet (Memory Management), Table 5.1 (Application Segment Types): Code elérés, Data elérés megkülönböztetve, 9.9.13: GPF keletkezik, ha non-executable segmensre kerül a végrehajtás. Amúgy emlékeim szerint a 386 is tudja, de azt a manuálomat kidobtam.
    Szóval a 386(?) / 486 óta megvan a lehetőség hardverileg
    Mutasd a teljes hozzászólást!
  • "Köszi, de maradok ssh-nál"

    Mert biztos mar megoregedtel.

    ssh-val nem manageled a clusteredet valami gyorsan. Vagy az X ssh tunelingjere gonoltal?
    Mutasd a teljes hozzászólást!
  • X-hez van valami proxy ami joval kisebb adatforgalommal mukodik, most fejbol nem tudom a nevet, ha fontos megkereshetem, de szerintem te is megtalalod.

    Köszi, de maradok ssh-nál (csakúgy példának hoztam föl)
    Mutasd a teljes hozzászólást!
  • Es mit latok a TPC.org-on?

    TPC-C kategoriaban egy uj gyoztesunk van mind tpmC mind price/performance tekinteteben.

    Linux-cluster guruk par linket firkantsanak legyszives cluster temakorben.
    Mutasd a teljes hozzászólást!
  • A linux nagyon gyors fejlődése a régi ko5rlátokat felszakítja és ujj lehetőségeket ad a programozásra.


    Úgy látom, a helyesírási és nyelvtani korlátokat nem szakítja ÁT.
    Mutasd a teljes hozzászólást!
  • "linuxnak a legnehezebb viszafejteni az ip címét idegen gépekről"

    Méghogy az egységsugarú júzerek nem tudják használni a linuxot...
    Mutasd a teljes hozzászólást!
  • Sting
    Tévedsz, mert a linuxnak a legjobba védelni rendszere a winXP-n kívül.
    Pl. a linuxnak a legnehezebb viszafejteni az ip címét idegen gépekről.
    Elég kevés a vírus rá.
    mivel ingyenes ezért viszaszorítja a Microsoft hatalmat.
    Mutasd a teljes hozzászólást!
  • A linux nagyon gyors fejlődése a régi ko5rlátokat felszakítja és ujj lehetőségeket ad a programozásra.
    Aki egyetért írjon.
    Mutasd a teljes hozzászólást!
  • loader a processzor MMU-ját úgy állítja be, hogy ahol a stack van, onnan ne futhasson kód.

    Erről magyarázok napok óta, hogy ezt nem lehet beállítani, mert x86 processzorokon minden memóriaterület ami olvasható, az egyben futtatható is (a CPU nem különbözteti meg ezt a két attribútumot). Ezért hamis az elnevezés.

    Ráadásul ez a védelem semmit sem ér azokkal a támadásokkal szemben, amelyek nem egy a stacken lévő pufferterület túlcsordulását használják ki.
    Mutasd a teljes hozzászólást!
  • Hát az rdp nem akadozik 384-en, de 56k-n se...

    Ezt csak megerősíteni tudom én is. A konzol villámgyors (felismerhetetlenül pörögnek a sorok felfelé, ha folyamatosan ír egy program a konzolra), és a grafikus felülre sem kell várni. Az egyetlen probléma a nagy bitképek átvitele (tehát ha egy program egy nagy grafikát jelenít meg valamelyik ablakban), mert az kegyetlen lassan tud átjönni. Viszont a Windows beépített adminisztrációs eszközei közül egyik sem nagyon követ el ilyen "merényletet" a távmenedzseléssel szemben...

    ADSL-en meg olyan gyors a TS/RDP, hogy az ember hajlamos elfelejteni, hogy nem azon a gépen dolgozik, ami előtt éppen ül.
    Mutasd a teljes hozzászólást!
  • De mondjuk egy 386/64-es adsl-en az X is tud akadozni,


    X-hez van valami proxy ami joval kisebb adatforgalommal mukodik, most fejbol nem tudom a nevet, ha fontos megkereshetem, de szerintem te is megtalalod.
    Mutasd a teljes hozzászólást!
  • De mondjuk egy 386/64-es adsl-en az X is tud akadozni


    Hát az rdp nem akadozik 384-en, de 56k-n se... (hacsak nincs hálózati probléma, de az meg nem ide tartozik)
    De mint többször leirtam semmi szükség winen a grafikus felület átvitelére...
    Mutasd a teljes hozzászólást!
  • akkor meg má nem root, hát hogyan irkálja nekem összevissza a filejait?


    Oda ir ahova joga van... (azért akad 1-2 irható nem rendszerfile, de létre is hozhat magának) De ez egészen pontosan winen is igy van. Ahogy a "de akkor nyoma van" is szóról-szóra igaz winen is.
    Mutasd a teljes hozzászólást!
  • lehet, hogy bennem van a hiba, de egy röpke 5 perces mérésből úgy látszik, hogy nagyobb sávszél kell az rdesktopnak)


    Reg hasznaltam, de ha jol emlekszem mar 33.6-on hasznalhato volt, ha nincsenek nagy bitmap-ek.

    netchan
    Mutasd a teljes hozzászólást!
  • Tudod egyáltalán hogyan működik ez az - amúgy teljesen megtévesztő módon elnevezett - 'non executable stack area' technika?


    Ez engemet is érdekelne

    (Ugyanis eddig abban a hiben éltem, hogy egyszerűen úgy működik, hogy a stack területet külön memóriaszegmensbe linkelik és a loader a processzor MMU-ját úgy állítja be, hogy ahol a stack van, onnan ne futhasson kód. De meglehet, hogy tévedek ... )
    Mutasd a teljes hozzászólást!
  • Egesz pontosan meg lehet nezni, hogy milyen tamadasok ellen ved:
    paxtest

    netchan
    Mutasd a teljes hozzászólást!
  • Hát rpc meg rdesktop nagyon jó, hogy így 100 Mbps van a két gépem között. Illetve rpc-t nem látom, de nyilván jó.
    De mondjuk egy 386/64-es adsl-en az X is tud akadozni, akkor micsinál az rdesktop (lehet, hogy bennem van a hiba, de egy röpke 5 perces mérésből úgy látszik, hogy nagyobb sávszél kell az rdesktopnak)
    Nyiván ha azt mondom, hogy mondjuk 1G pentium-om igencsak régen kiléptem a shellből mire az rdesktopon a bejelentkezés egyáltalán följön, akkor az lesz az érv, hogy cseréljem le az ócskavasat
    Mutasd a teljes hozzászólást!
  • also hatart egy gprs mobil es egy notebooknal


    és mit csinálsz, ha a gprs éppen 80 byte/sec-es elérést ad akkor, amikor a legjobban el kellene érned a legfontosabb serveredet?
    Mutasd a teljes hozzászólást!
  • Nem érted mit mondok. Nem a saját config filejába ir bele. Akárhova, akár létrehoz a könyvtárak mélyén valamit. Vagy egy létező config fileba (teljesen más programé) kommentként ir be valamit. Vagy nem használt területre, tökmind1, lényeg, hogy nem az install program végzi, hanem maga a futó program igy az installernek esélye sincsen loggolni, majd uninstallkor lepucolni.

    Hát izé, izé , szóval :
    rpm telepítés rootként, bárhova írhat, de akkor nyoma van ugyebár
    ha meg elindítom, akkor meg má nem root, hát hogyan irkálja nekem összevissza a filejait?
    Mutasd a teljes hozzászólást!
  • Ne zavarjon, hogy
    - ennek semmi köze az itt említett technikákhoz, valamint,
    - szinte semmi ellen sem véd
    - ami ellen véd, olyan exploit a gyakorlatban Windows alatt nem is létezik (mert több MB-nyi kód injektálását tenné szükségessé, ami gyakorlatilag nem opció egy távoli támadásnál).

    Tudod egyáltalán hogyan működik ez az - amúgy teljesen megtévesztő módon elnevezett - 'non executable stack area' technika?
    Mutasd a teljes hozzászólást!
abcd