Hlavní navigace

Vlákno názorů k článku Bude váš Linux potřebovat antivirus? od Izak - 1. Jednalo se o chybu ve webove apl. 2....

  • Článek je starý, nové názory již nelze přidávat.
  • 14. 11. 2005 11:36

    Izak (neregistrovaný)
    1. Jednalo se o chybu ve webove apl.
    2. Antivir by nic neresil.
    3. Dnes je nejbeznejsi chyba preteceni bufferu a dnesni AMD64 tohle resi nonexecutable stackem.

    Ale, je pravdou ze veci co nejesou nejak podepsane se asy scanovat antivirem budou, takze po stazeni je bude admin kontrolovat.

    Stanice nemusi mit otevreny zadne porty, mozna SSH pro administraci.
    Ja mam stanici s verejnou IP primo na netu a pres IP tables omezeny sluzby jen do vnitrni site.
    Akorat tam mam utoky na SSH.
  • 14. 11. 2005 12:08

    Zdenek (neregistrovaný)
    Kdyz uz jsi se dotkl "nonexecutable stacku", mel bych dotaz - tahle moznost uz tu preci je od 386tek (mozna uz 286 - ale tam byl PM takovy, no ehm... :) ), muze mi nekdo znaly problematiky rici, proc se tato moznost (tj. mit "nespustitelny" datovy/stack segment) nevyuziva?
    Osobne mi pripada, ze je o dost slozitejsi napsat system se spustitelnym stackem, nez bez nej (cti: s nespustitelnym).

    Vzdyt je to tak jednoduche:
    1) kod -> RO, Exec segment
    2) data -> RW (/RO - zalezi na charakteru dat), Non-Exec segment
    3) stack -> RW, Non-Exec, Stack segment
    atd...

    Vzdycky jsem si myslel, ze tuhle architekturu (alespon teoreticky) celkem znam, ale pravdepodobne ve svem uvazovani delam nekde chybu...
  • 14. 11. 2005 12:27

    Zdenek (neregistrovaný)
    Delate chybu, neznate x86 ani teoreticky. Diky "inzenyrum" z Intelu ve snaze usetrit jeden bit, neslo nastavit strance non-executable. U x86 jste mel na vybranou pouze R/W nebo R+Executable.
  • 14. 11. 2005 15:11

    ghost (neregistrovaný)
    No i kdyby to byly tak jak pises, tak je to preci porad OK - pokud je neco R/W a Nonexec, tak je to v poradu - data. Pokud je to R+Exec, tak taky neni problem, protoze sice muzu spoustet kod, ale nemuzu ho modifikovat.
  • 15. 11. 2005 13:02

    Ales Hakl (neregistrovaný)
    No ono to s tim stackem je takove zvlastni. Intelove to vymysleli tak, ze stack i386 MUSI BYT no-exec. Nicmene cela ta jejich klasicke x86 podobna myslenka je pomerne podivna, tak na to vsichni kaslou a udelaji to tak ze vsechny segmentove registry obsahuji deskriptory s bazi 0 a limitem 4G a cela ochrana se presouva na strankovani, kde toho u i386 opravdu mnoho nastavit nelze.
  • 5. 1. 2006 3:43

    hstech (neregistrovaný)
    Stránce ne ale segmentu ano. Takže na x86 se to dělá tak, že code segment pokrýva pouze tu část adresního prostoru v procesu, která obsahuje pouze spustitelný kód, zbytek už ne. K datam a stacku se přistupuje skrz jiné segmenty (data and stack segment) a pokus připadného útočníka (nebo červa) skočit si na ňákej shellcode v stacku pak skončí neelegantním segfaultem.
  • 14. 11. 2005 12:30

    SanTiago (neregistrovaný)
    Protoze i386 umoznuje nonexecutable flag nastavit jednotlivym segmentum a ne jednotlivym strankam (alespon doufam, ze si to pamatuji spravne) a protoze Linux z mnoha duvodu (napr. prenositelnost na jine platformy) nevyuziva segmentaci, ale pouze strankovani.
  • 14. 11. 2005 13:21

    Michal Kubeček (neregistrovaný)
    Problém je v tom, že segmenty se mohou překrývat. A aby si autoři ušetřili práci, obvykle se také překrývají.
  • 14. 11. 2005 15:16

    ghost (neregistrovaný)
    "aby si usetrili praci" - no to je prave to hrozne. Uz od dob i386 (pokud tedy budu uvazovat pouze x86 platformu), tu prakticky mame skvely hw nastroj, ktery ale kvuli lenosti nepouzivame :-( ...smutne.
  • 14. 11. 2005 21:14

    abyssal (neregistrovaný)
    Je to uz sice nejaky piatok, co som sa o to zaujimal, ale ak sa dobre pamatam:

    Flat memory model je model segmentacie, kde je segmentacia "takmer vypnuta", tj. vsetky deskriptory su natiahnute na celu pamat (alebo rovnako na nejaku jej cast). Niekolko ich je pre user ring (CPL 3) a niekolko pre kernel ring (CPL 0) - v kazdom treba spustitelny segment, datovy segment so zapisom (pre stack) a typicky datovy pre nejake data programu.

    Problem s flat memory modelom je v tom, ze ak na adresu SS:0xDEADBEEF zapiseme spustitelny kod a donutime nejakym bugom (a la stack overflow) jump/return na 0xDEADBEEF, ten isty kod lezi na CS:0xDEADBEEF a spusti sa. Grsecurity (http://grsecurity.net), ak sa dobre pamatam, to riesi dvoma sposobmi: prave nejakou segmentaciou, aby sa segment zasobniku neprekryval s executable segmentom a druhy sposob je nahodne umiestnovanie adries VM (vyzaduje position-independent code). To druhe kvoli tomu, aby nesiel spravit jednoducho return-to-libc-attack (druh utoku, kde sa nevklada kod, len sa zmeni prepisom zasobnika navratova hodnota na uz existujuci kod). Plus este nejake dalsie featury. Funguje pre i386, sparc, ia64 a snad este nejake dalsie architektury.

    "Segmentation fault" v linuxe neni v skutocnosti problem so segmentaciou, ale pristup na stranku, ktora nie je namapovana a nebola odswapovana. Niektore programy toto vedia vyuzivat (nie moc cisty hack) aby si vytvorili svoj vlastny memory management - obcas sice sahaju mimo malloc()om alokovanu pamat (len read), ale nepreslo by im to, keby napr. segment zacinal v strede stranky. (Bolo by asi neprakticke na urovni kernelu alokovat tak pamat, ale niekedy sa robia pri programovani "wild assumptions".) Skuste si napr. v zdrojakoch Pythonu vygrepovat slovo valgrind :-)

    Prvy krat som sa s flat modelom stretol tusim u Watcom C++ pre DOS a extenderov DOS4GW a PMODE/W. Watcom C++ pokial viem ponukal niekolko memory modelov (teda moznosti segmentacie), ale z nejakeho dovodu sa vacsinou pouzival flat v kode, co som videl. Sam uz presne neviem preco, ale myslim, ze to bolo pohodlnostou, vtedy sa na bezpecnost moc nehralo a bolo lahsie napr. hladat video pamat na DS:0xA0000 nez pracne pridavat deskriptory. V pripade operacnych systemov mohla hrat nejaku rolu aj prenositelnost a udrzovatelnost kodu, pretoze asi nema kazda architektura obdobu GDT/LDT (globalna vs lokalna tabulka deskriptorov) ako u x86.
  • 15. 11. 2005 13:08

    Ales Hakl (neregistrovaný)
    On se ten Flat memory model pouziva hlavne proto, ze je pro C takovy privetivejsi. Pointer je jedno 32-bitove cislo a tak podobne.

    Nicmene je spousta veci, ktera by se s i386 segmentaci resila lepe a radostneji (a typicky s mensim overheadem) jako krasny priklad mi prijde dynamicky linker u ktereho by temer odpadla nutnost provadet nejake relokace.
  • 15. 11. 2005 13:50

    abyssal (neregistrovaný)
    jj, takyto dynamicky linker by odstranil nutnost relokacii. Ale mozno by musel byt odlisny executable/shared object format pre x86 ako pre ostatne architektury. S tym overheadom som si tiez neni taky isty, hlavne pocet GDT deskriptorov je obmedzeny, kazdy proces by mohol mat vlastnu LDT, len pokial sa pamatam, tak task switching via TSS a prepinanie adresovych priestorov nebola zrovna rychla operacia.
  • 16. 11. 2005 23:03

    Pavel (neregistrovaný)
    Apropo, vy asi neprekladate sdilene knihovny s -fpic. Jinak by jste vedel,
    ze pri on demand natahovani stranek z ELFovych knihoven k zadne relokaci nedochazi.
    V kodu to stoji jeden indirect call na kazde volani funkce z jine knihovny a neprime
    odkazovani na data, udavan asi 3% overhead proti statickemu linkovani.
    Jedine, co je potreba updatovat pri natazeni knihovny, jsou stranky s tabulkami
    cilu skoku a ukazatelnu na globalni data. Kdyz si predstavime nahradu vsech ukazatelu
    za verzi far 16+32 bitu s nutnosti prochazet GDT ci LDT nebo Call Gates, tak by bylo za
    usetreni nutnosti PIC kodu zaplaceno narustem delky kodu a prisernym narustem
    casu provadeni volani. To je take duvod, proc Linuxove jadro pred mnoha lety opustilo
    prepinani segmentovych registru pri vstupu do kodu jadra syscallem a spoleha se nyni
    pouze na ochranu strankovanim. Samotny Intel jiz v dokumentaci k PentiuPro vysvetluje
    overhead pri pouziti segmentu a doporucuje tuto vybavu procesoru zcela ignorovat.
  • 17. 11. 2005 16:41

    abyssal (neregistrovaný)
    Neviem, ci ste si poriadne precitali, co som pisal predtym. Ako alternativa PIC bol uvadzany uz na zaciatku. IMHO je to celkom dobre riesenie, ale mam radsej principialne riesenia - t.j. PIC mi pride trocha ako "hack". Na jednej strane, urcite je to rychlejsie, predsa natahovanie pred programatorom skrytych casti segmentovych registrov pri ich zmene nie je najrychlejsie. Na druhej strane, neviem o kolko by bol size/speed overhead pri segmentovanej verzii. Cally vnutri kniznice su vsetky relativne, potial je to easy. Problem nastava len pri volani rutin z inych kniznic. Hlavny problem vidim v tom, ze segmentovych registrov je malo. Co by sa dalo riesit hardwarovo - pridanim nejakeho mnozstva registrov - co je ale zrejme drahe a pravdepodobne nenastane, pretoze to nikto neziada.

    Druha moznost by bola napr. vyhradit dva segmentovy registre (napr. FS, GS) pre segment kodu a dat jadra tak, ze by sa softwarovo simulovala brana volania. Dynamic loader by proste zavolal rutinu jadra na "zaregistrovanie" kniznice, programy vyzadujuce kniznicu by zavolali nejaku upravenu verziu dlopen, ktora by vratila nejake 32-bitove cislo ako identifikaciu kniznice. Kod by sa predlzil o 2xMOV pre kazde volanie, jeden na identifikaciu kniznice a druhy na entry point. Neboli by treba relokacie - len pri loadnuti kniznice by sa naplnilo par hodnot v statickej datovej casti, kde by boli ulozene tie identifikacie pouzivanych zdielanych kniznic.

    Netvrdim, ze je to genialne riesenie, ani ze by to nejak extremne zrychlilo cely proces (oproti branam volania a inym prostriedkom poskytovanym hardwarom), ale je to jedna z dalsich moznosti. Nikdy som to neskusal zmerat, ale keby som mal za ulohu vytvorit OS so zameranim predovsetkym na bezpecnost (rychlost az na druhom mieste), asi by som to skusil, resp. vyhladal si vyskum, co uz niekto robil. Mozno je cena naozaj prohibitivny overhead - co je mozno dovod, preco sam Intel doporucoval upustit od segmentacie. Ale to boli casy Pentium Pro, procesory trocha zrychlili odvtedy, je teoreticky mozne, ze by niekto zvolil takyto pristup (spekulacia). Ten MS Singularity OS je tiez krok podobnym smerom, aj ked inymi prostriedkami. Tazko povedat, ci sa to niekedy ujme.

    BTW, preco si myslite, ze mam zdielane kniznice skompilovane bez -fpic? Ono by to u mna bez toho s niektorymi featurami dost dobre nefungovalo :-) Inak typicky sa linker (ld) snazi do urcitej miery vytvorit position-independent code aj bez -fpic, dava "DT_TEXTREL in object" warning ak sa mu to nepodari.
  • 17. 11. 2005 20:41

    abyssal (neregistrovaný)
    Len drobna oprava s DT_TEXTREL: gcc samozrejme vytvara kod, linker dava warning ak vysledny objekt potrebuje relokacie.
  • 15. 11. 2005 18:25

    bez přezdívky
    S mensim overheadem ... i kdyby. Jakekoliv teoreticke vyhody pouzivani segmentace se ztrati v obrovskem overheadu pointerove aritmetiky, kterou jazyk jako C MUSI delat (aby splnoval normu) pokud nema flat model ...

    K tomu pripocti, ze nejpozdeji v dobe pentii si vyvojari procesoru vsimli, ze vsichni pouzivaji flat model, a pravdepodobne pro nej zacali optimalizovat ... a AMD64 v 64bitovem modu segmentaci uz nema (resp. je hardwarove prepnuta na flat model).
  • 14. 11. 2005 14:28

    Izak (neregistrovaný)
    No spise se to resi soft. pres grsecurity patche.
    Bud jen na urovni jadra, nebo rovnou optachovam GCC + jadra.
  • 14. 11. 2005 18:59

    Petr (neregistrovaný)
    Ja nevim - co si pamatuju, tak v instrukcni sade treba neexistovala instrukce typu "zavolej interrupt, tady je jeho cislo" a takovehle veci se musely resit bud zapisem do kodu nebo vytvorenim kodu v zapisovatelne pameti.
  • 15. 11. 2005 18:29

    bez přezdívky
    Zrovna volani interruptu ti v linuxu je k nicemu, jediny interrupt ktery mas co volat je 0x80. Spustitelny zasobnik byl zapotrebi napriklad na kod pro obsluhu signalu - uz neni, uz se to vyresilo nejak jinak.