sicherer mit winxp sp2 ?

jcyberpunk

habe gerade den heise artikel ( Diesen hier ) zum thema windows xp und service pack2 gelesen.

naja, was soll ich sagen.... ms macht sich gedanken über ihren mist, den sie jahrelang verzapft haben und setzen auf default firewall policies und speicherschutz mechanismen, wie z.b. pax unter linux.

fakt ist allerdings auch, dass nicht alles was glänzt auch gold ist.

nicht überall können ports geschlossen werden, nur selten existieren systeme die nahezu vollen schutz bieten (64bit prozessoren) und auch längst nicht alle anwendungen werden mehr laufen ( Einige Applikationen, die etwa zur Laufzeit neuen Programmcode generieren und ausführen wollen, dürften nach der Installation des Service Packs nicht mehr funktionieren. Über spezielle Funktionen können neue Anwendungen ausführbaren Speicher anfordern, ältere Programme müssen dazu überarbeitet werden. )

bis die meisten user also aufatmen koennen, wird sicherlich noch einige zeit vergehen.

ganz in sicherheit kann man sich allerdings nie wiegen koennen, da natürlich viren oft erst dann erscheinen, wenn stabiler exploit code gebaut wurde, will heissen, return-into-libc ähnliche angriffe werden immer funzen und wenn jemand die als sample exploit in zukunft bastelt wird, weden auch dann weiterhin die würmer am leben bleiben.

cheers,
johnny

Edit by Paulchen
Bitte keine Direktlinks verwenden
daher hier geändert !

Psylix

quatsch... meine apps liefen alle noch nach der installation von SP2...
Die Firewall.. naja^^ Microsoft traut man nicht smile

Ich hab meine HardwareFirewall und gut großes Grinsen

Zitat:

nur selten existieren systeme die nahezu vollen schutz bieten (64bit prozessoren)

meinst du 64bit cpus schaffen das?

hängt das nicht von dem jeweiligen benutzern und deren software/hardware ab?
ich denke nicht das nur allein durch ne 64-Cpu alles sicher is.

jcyberpunk

es geht nicht darum, dass es an 32 oder 64 bit prozessen liegt, dass der heap dann auch geschützt ist, sondern man hat erst mit einführung der 64 biter einen bestimmten mechanismus eingebaut,
der dann auch diese bereiche schützt.

die implementation pax (pax.grsecurity.net) für linux kernel kann
auch auf 32bit prozessoren schon heap protection. nur softwaremaessig halt und nicht hardwaremaessig.
ebenfalls openbsd >= 3.4

desweiteren habe ich auch nur gesagt, dass es einige anwendungen gibt, die dann nicht mehr laufen, nicht generell alle.

eben die, die etwa zur laufzeit neuen programmcode generieren und ausführen wollen.

exploitation wird auf jedenfall eine ecke härter. beispielsweise gibt es
nur ganz wenige exploits die z.b. unter linux mit pax laufen, obwohl
eine schwachstelle im service existiert, der ohne pax exploitable wäre.
der service stürzt dann lediglich ab und es wird kein shellcode ausgeführt.

lediglich durch return-into-libc kann das funktionieren, ist aber oft nicht stabil, da der exploit, genau für die eine box gebaut wird.
hat der service kein relaunch, sondern ist oneshot, ist's eh vorbei, mit z.b. bruteforce mode.

cheers,
johnny

Psylix

soll jetzt nicht beleidigend sein oder so, aber ich hab etwa 50% deines textes nicht verstanden smile

jcyberpunk

naja, um die problematik mit dem ausführbaren code zu verstehen,
muss man schon mal etwas in die tiefe gehen.
obwohl ich noch versucht habe, dass relativ einfach darzustellen.

nur vieleicht noch mal kurz zum verständniss, wie exploits in der basis arbeiten.

ein einfacher stack exploit:

fehler im c-code:

char buf[10]="";
strcpy(buf,argv[1]);

bug:
übergibt jemand nun in argv[1] über die commandozeile mehr als 10 bytes, stürzt das programm ab.
was aber passiert genau ?
dazu muss man sich den speicher mal ansehen und verstehen wie ein betriebssystemkern funzt.

speicherbereich:

offset 0-9 daten von buf(10bytes)
10-13 frame pointer
14-17 stack pointer

zum frame pointer sage ich jetzt mal einfach nix, um
nicht noch mehr zu verwirren.
der kernel versucht unser c programm abzuarbeiten und ist gerade
an der strcpy stelle die den fehler hat. auf dem stack pointer steht
nun die rücksprungadresse die der betriebssystemkern benutzt
um wieder zum programmfluss zurückzukehren, damit darunterliegende befehle weiter abgearbeitet werden können.
überschreibe ich diesen speicherbereich nun mit lauter 'A's will
der betriebsystemkern plötzlich zu einer adresse ( A in hexadezimal ist 0x41) 41414141 springen. da dieser bereich allerdings keinen
sinnvollen code einthält oder gar illegaler speicher ist, sieht der
betriebssystemkern das als schutzverletzung an und beendet das
programm. ein klassischer Denial of Service.
will man nun kontrolle über das system gewinnen, muss also versuchen eine sinnvolle adresse zu finden zu der man zurückspringen kann. z.b. wieder zurück in meinen datenbereich
wo ich nun keine sinnloses As platziert habe, sondern ein kleiner
assemblercode, der z.b. einen admin user zur datenbank hinzufügt.
oder häufig wird auch eine remoteshell kreiirt auf die der angreifer
dann das system anconnecten kann.

für diese stack bugs, gibt's diverse sicherheitsmechanismen unter
unix platformen und das schon lange.
einen softwaremässigen schutz bietet windows 2003 zum ersten mal an.
mit service pack 2 für windows xp wird das auch der fall sein.
und zusätzlich ab 64 bit rechnern auch eine hardware protection,
die vor heap overflows schützt.

stack beispiel : char buf[256]="";
heap beispiel : buf = malloc(256);

heap speicher wird komplizierter verwaltet als stack speicher
und ist vor allem dynamisch.
von daher allein schon schwieriger umzusetzen.
openbsd hat z.b. eine lösung bei der gesagt wird.

du darfst in den speicher schreiben oder ausführen aber nicht
beides auf einmal. denn schreib speicher koennen z.b. variablen
sein und ausführbar darf nur programmcode sein.
damit trennt man klar den code von den daten. somit kann ein
angreifer nicht mehr so leicht im datenbereich code platziert
und ihn nachher starten.

das war nur ein 0,1 % von dem was es bedeutet sich mit dieser
materie auseinander zusetzen. ich hoffe aber es ist nun etwas
klarer geworden, was ich eingehends meinte. Augenzwinkern