Sicherheitsaspekte von ReactOS Teil 2

Hier können Sie auf Deutsch diskutieren. Bedenken Sie, dass Sie in den englischen Foren mehr Nutzer ansprechen.

Moderators: frik85, EmuandCo, Dr. Fred

Post Reply
RudBoy
Posts: 105
Joined: Sun Apr 02, 2006 2:02 pm
Location: Näher als Du denkst
Contact:

Sicherheitsaspekte von ReactOS Teil 2

Post by RudBoy »

Hallo Liste,

Denke das Thema Sicherheit unter ReactOS nimmt einen immer grösseren Stellenwert ein.
Wie Ihr wisst mache ich mir so meine Gedanken über neue Sicherheitskonzepte innerhalb von ReactOS, hatte mir ja überlegt die Kommunikation mit dem Internet über eine Virtuelle Maschine laufen zu lassen, eine andere Idee war eine SandboxLösung einzubauen und jetzt das, Habe heute die neueste PC-Welt gekauft, da ist eine neue Art von Rootkit beschrieben der gerade dieses Sicherheitskonzept aushebelt, falls Ihr euch dafür interesiert und euch die PC-Welt 5_2006 zulegen möchtet findet Ihr den Beitrag auf der Seite 23 unter den Titel VM BASED Rootkit
es ist immer wieder verblüffend was es da gibt.

Habe mal mein bisschen C / C++ Wissen zusammengekratzt, auch mal nachgefragt 8) und euch einen Beispielcode geschrieben der einen Pufferüberlauf im Heap erzeugen würde:

Bitte nicht nachmachen gehtdem!

// class_tres1.cpp : Definiert den Zugangspunkt für die Konsolen-
//Anwendung

#include <stdio.h>
#include <string.h>

class test1
{
public:
char name[10];
virtual -test1();
virtual void run();
};

class test2

{
public:
char name[10];
virtual -test2();
virtual void run();
};

int main(int argc, char* argv[])

{
class1 test1 *t1 = new class test1;
class1 test2 *t5 = new class test1;
class1 test1 *t2 = new class test2;
class1 test2 *t3 = new class test2;

/////////////////////////////////////////////////////////
//
// überschreibt die virtuelle Funktion von t2
// Zeiger w/ Heap-Adresse
// 0x00301E54 lässt den Destruktur
// wie 0x77777777 erscheinen
// und die run() -Funktion wie
// 0x88888888 erscheinen
//
/////////////////////////////////////////////////////////

strcpy-> (t3-> name, "\x77\x77\x77\x77\x88\x88\x88\x88XX XXXXXXXXXX"\ "XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX XXXX\x54\x1E\x30\x00");

delete t1;
delete t2; // ruft Destruktur 0x77777777 auf
delete t3

return 0;

}
void test1::run()
{
}
test1::~test1()
{
}

void test2::run()
{
puts("Was is los hier ??????");
}
test2::~test2()
{
}

Also diese Vorgehensweise bezeichnet man als Trespassing, oder in den Heap-Speicher eindringen, wer an Infos hierzu interesiert ist fragt mich einfach mal :shock:

oder so in der Art RudBoy :twisted:

ps: in memory of woody (Debian Linux programmer) peace :cry:

:shock:
Am Anfang war alle Software frei. (Georg Greve, FSFE)
FloFri
Posts: 7
Joined: Sat Nov 27, 2004 1:55 am

Post by FloFri »

Hm, also, was der Code mit deinem oben genannten Absatz zu tun hat, ist fraglich (ich schätze mal gar nichts ;) ).

Das mit dem in den Heap eindringen ist ja ganz nett, das funktioniert (eigendlich) aber nur bei dem eigenen Prozess und nicht bei fremden, da jeder Prozess ja einen eigenen Addressraum und daher auch einen eigenen Heap und Stack hat, welche von einander abgeschottet sind (wie gesagt: eigendlich ;) ).
Matthias
Posts: 496
Joined: Tue Dec 27, 2005 12:43 am

Post by Matthias »

FloFri wrote:Das mit dem in den Heap eindringen ist ja ganz nett, das funktioniert (eigendlich) aber nur bei dem eigenen Prozess und nicht bei fremden, da jeder Prozess ja einen eigenen Addressraum und daher auch einen eigenen Heap und Stack hat, welche von einander abgeschottet sind (wie gesagt: eigendlich ;) ).
Naja, zumindest unter UNIX funktioniert das auch in der Praxis recht gut, und, nach allem was ich gehört habe, auch unter Windows NT.
RudBoy
Posts: 105
Joined: Sun Apr 02, 2006 2:02 pm
Location: Näher als Du denkst
Contact:

Post by RudBoy »

FloFri wrote:Hm, also, was der Code mit deinem oben genannten Absatz zu tun hat, ist fraglich (ich schätze mal gar nichts ;) ).

Das mit dem in den Heap eindringen ist ja ganz nett, das funktioniert (eigendlich) aber nur bei dem eigenen Prozess und nicht bei fremden, da jeder Prozess ja einen eigenen Addressraum und daher auch einen eigenen Heap und Stack hat, welche von einander abgeschottet sind (wie gesagt: eigendlich ;) ).
Ja genau so haben wir es auf der Schule gelernt und so auch in C gedacht, oder C++ ein Hacker denkt anders, denke mal um die Ecke :idea:

Okay das wird wieder mal ein etwas längerer Thread, so in meinem Beispiel werden zwei Klassenobjekte auf dem Heap-Speicher instantiziert.Ein statischer Puffer eines Klassenobjektes wird überflutet und läuft in ein angrenzendes Klassenobjekt über.
Dieser Übergriff überschreibt den Zeiger(so typisch C),der auf die virtuelle Funktionstabelle (vtable-Zeiger) des zweiten Objektes verweisst(typisch C)

Die Adresse wird so überschrieben, dass die vtable-Adresse nun auf unseren Puffer verweist.Dann stellen wir Werte in die eigene Trojaner-Tabelle, um neue Adressen für die Klassenfunktionen zu definieren.Eine dieser Funktionen ist der Destruktor, den wir so überschreiben, dass unser neuer Destruktor aufgerufen wird, wenn ein Klassenobjekt abgebaut wird.

Auf diese Art und Weise können wir nun jeden Code ausführen, den wir auch ausführen möchten!
Dazu lassen wir den Destruktor auf den Angriffscode zeigen ( so was von C ) .
Das ganze hatt aber auch einen Nachteil, bei dieser Vorgehensweise besteht er darin, dass die Objektadressen von Heap-Objekten unter Umständen NULL-Zeichen erhalten, die natürlich unsere Möglichkeiten hier einschränken.
Wir müssen deshalb unseren Angrifscode an einer Stelle speichern, die keine NULL-Adressen benötigt, oder einen unserer alten Streiche :idea:
mit dem Stapel spielen, um den EIP wieder auf unsere Adresse umzuleiten, jo der og Code zeigt dir den Streich und die Methode.

in memory of woody (Debian Linux programmer) :cry:

Yep und das ist ein Rootkit puuh

soooo und jetzt weisste auch warum ich kein C oder C++ mag

Viele Grüsse der RudBoy

ps: abba Ada schafft micht nicht :!:

||-->> ach so der Angriff wurde so in etwa, in dieser Art ! von RyanRussel mitp auf nen Debian Rechner erfolgreich ausgeführt <<--||
Am Anfang war alle Software frei. (Georg Greve, FSFE)
Post Reply

Who is online

Users browsing this forum: Trendiction [Bot] and 11 guests