C: Warum erhalte ich nicht die erwartete Ausgabe?

[Matthias (Gast)]

Moin,

in Kürze: Ich wollte probieren, inwieweit ich unter Windows mit einem 
Programm in die Daten eines anderen Programms/Prozesses eingreifen kann.
Dabei stehe ich noch ganz am Anfang: Mein kleiner Versuch: Programm 1 
legt eine Zeichenkette in den Speicher und gibt diese im 
5-Sekunden-Rhythmus aus, das zweite legt ebenfalls eine Speicherkette in 
den Speicher, legt einen Zeiger darauf an und zählt anschließend diesen 
Zeiger so weit runter, dass als Ausgabe eigentlich die Zeichenkette des 
ersten Programms erscheinen müsste - das ist aber nicht der Fall, obwohl 
die Adressen übereinstimmen:

//Programm 1
#include <stdio.h>
#include <windows.h>
 
int main(int argc, char* argv[])
{
    char ausgabetext[]="Beispieltext\n";
  char* zeiger = &ausgabetext[0];
  printf("Adresse von ausgabetext: %i\n",zeiger);
  while (1) {
    printf(ausgabetext);
    Sleep(5000);
    }
    return 0;
}

//Programm 2
#include <stdio.h>
 int main(int argc, char* argv[])
{
    char meintext[]="MeinText\n";
  char* zeiger;
  int i;
  zeiger = &meintext[0];
  for (i=0;i<30;i++) {
    printf("%i\t",zeiger);
    printf("%3i\t%c\n",zeiger[0],zeiger[0]);
    zeiger=zeiger-1;
  }
    return 0;
}

Ich erhalte als Ausgabe von Programm 1:
Adresse von ausgabetext: 1638202
Beispieltext
[...]

Ausgabe von Programm 2:
1638206   77  M
1638205   43  +
1638204  -35  Ý
1638203    0
1638202  24
1638201  -1     ÿ
1638200  56     8

Das "M" von "MeinText" wird also ausgegeben, aber für Adresse 1638202 
kein "B" von "Beispieltext". Mache ich hier einen Denkfehler 
(wahrscheinlich)? Oder liegt das nicht am C-Code, sondern an ...?
Hinweis: Ich rufe beides vom Windows7-Kommandozeileninterpreter "cmd" 
aus auf; starte nacheinander prog1, prog2.
Danke für jeden Hinweis!

[Tom (Gast)]

Matthias schrieb:
> zeiger=zeiger-1;

[Max H. (hartl192)]

Matthias schrieb:
> Mache ich hier einen Denkfehler
> (wahrscheinlich)?

Matthias schrieb:
> zeiger=zeiger-1;

Versuchs mal mit zeiger++;

[Peter II (Gast)]

soll das ein April-Scherzt sein?

Wenn nein. Alle aktuellen Betriebssysteme verwenden virtuellen Speicher. 
Jede Anwendung hat seinen eignen Privaten Adressraum.

Ja es gibt Möglichkeiten den Speicher von anderen Programme zu ändern, 
aber dann muss man das mithilfe der API vom MS machen.

[Mark B. (markbrandis)]

Matthias schrieb:
> in Kürze: Ich wollte probieren, inwieweit ich unter Windows mit einem
> Programm in die Daten eines anderen Programms/Prozesses eingreifen kann.

Das ist eine der Aufgaben des Betriebssystems, so etwas nicht einfach 
mal eben so zuzulassen.

[Matthias (Gast)]

Moin,
ja, genau, das Thema mit "privaten Adressräumen" kenne ich. Und nein, 
kein Aprilscherz.

Letzten Endes ist es genau das, was ich bisher nicht verstehe, und 
wirklich mal nachvollziehen will: Wie genau kann es durch Pufferüberlauf 
und/oder gezieltes Schreiben in den Speicher möglich sein, einen Prozess 
mit höheren/mit Administratorrechten zu übernehmen und sich auf diese 
Weise eben Administratorrechte zu verschaffen? Klar, in der Umsetzung 
der Betriebssystemfunktion für die privaten Adressräume können Fehler 
sein. Und auch klar, wenn ich es schaffe, in den Speicherbereich eines 
anderen Prozesses zu schreiben, kann ich das Programm/den Prozess 
"verwirren" und zum Absturz bringen. Aber dann hätte ich das Ziel, 
diesen Prozess bzw. dessen Rechte zu übernehmen, ja wiederum nicht 
erreicht...

Gruß,
Matthias

[Udo S. (urschmitt)]

Matthias schrieb:
> Wie genau kann es durch Pufferüberlauf
> und/oder gezieltes Schreiben in den Speicher möglich sein, einen Prozess
> mit höheren/mit Administratorrechten zu übernehmen und sich auf diese
> Weise eben Administratorrechte zu verschaffen?

Auf Deutsch, du willst Exploits finden.
Natürlich nur zum akademischen Zweck :-)
Zum Glück ist das nicht ganz so einfach.

[Peter II (Gast)]

Matthias schrieb:
> Letzten Endes ist es genau das, was ich bisher nicht verstehe, und
> wirklich mal nachvollziehen will: Wie genau kann es durch Pufferüberlauf
> und/oder gezieltes Schreiben in den Speicher möglich sein, einen Prozess
> mit höheren/mit Administratorrechten zu übernehmen und sich auf diese
> Weise eben Administratorrechte zu verschaffen?

kann man das denn?

Wenn ein Programm als root/admin läuft und man schafft es von Außen mit 
falschen eingaben einen Pufferüberlauf zu erreichen, kann man damit die 
Kontrolle über diesen Prozess übernehmen.

Dafür braucht man aber kein 2.Programm.

[Peter II (Gast)]

so könnte man es machen

int main()
{
    char p[10];
    char* prog = "dir ";

    gets( p );

    char x[100] = 0;
    strcat( x, prog );
    strcat( x, p );
    System( x );
}

damit müsste es möglich sein, durch eine falsche Eingabe beliebige 
Programm zu starten.

[Vlad T. (vlad_tepesch)]

Peter II schrieb:
> damit müsste es möglich sein, durch eine falsche Eingabe beliebige
> Programm zu starten.

wenn du sowas zulässt, brauchts nichtmal einen Pufferüberlauf durch 
gets.

[Peter II (Gast)]

Vlad Tepesch schrieb:
> Peter II schrieb:
>> damit müsste es möglich sein, durch eine falsche Eingabe beliebige
>> Programm zu starten.
>
> wenn du sowas zulässt, brauchts nichtmal einen Pufferüberlauf.

wie meinst du das? Es sollte ja "offiziell" nur "dir" gestartet werden.

[Karl H. (kbuchegg)]

Matthias schrieb:

> Weise eben Administratorrechte zu verschaffen? Klar, in der Umsetzung
> der Betriebssystemfunktion für die privaten Adressräume können Fehler
> sein.

Du stellst dir das ein wenig zu einfach vor.
Das ist nicht einfach nur eine Software Sache, sondern da ist auch 
Hardware im Spiel. Da gibt es eine MMU (Memory Management Unit), die die 
Adressumsetzung anhand von Tabellen macht. In der Tabelle ist 
festgehalten, welche virtuelle Adresse auf welche physikalische Adresse 
im tatsächlichen RAM führt. Dies geschieht in Form von Speicherblöcken.

Wenn dein Programm startet, dann wird vom Betriebssystem eine Belegung 
in die MMU geschrieben, die deinem Programm vorgaukelt völlig alleine im 
Speicher zu sein. Im Rahmen der dir bereits zugewiesenen Speicherblöcke 
kannst du nicht auf die anderer Prozesse zugreifen. Denn entweder dein 
Programm greift auf einen regulär dir zugewiesenen Speicherbereich zu, 
dann setzt die MMU diesen Zugriff in den deinem Prozess zugewiesenen 
Speicherbereich um und du greifst auf den Speicherblock zu, der vom 
Betriebssystem für dich reserviert wurde.
Oder aber du greifst mit einer (virtuellen) Adresse auf den Speicher zu, 
dessen Block noch nicht für deinen Prozess reserviert wurde. In dem Fall 
löst dann die MMU eine Sonderbehandlung aus, das Betriebssystem springt 
an und bestimmt einen physikalischen Speicherblock, der dann auf genau 
diese von dir benutzte Adresse führt und trägt den zusätzlich in die MMU 
für dich ein. Ab sofort gehört dieser Speicherblock dann zu deinem 
Prozess (und ist natürlich vorher vom Betriebssystem für dich 
freigeschaufelt worden, wenn er schon anderweitig benutzt war)
Um also an der MMU vorbei in den Speicher zu adressieren, musst du dich 
an der MMU vorbeischummeln, was aber so nicht geht, weil deine 
Berechtigung nicht ausreicht um die MMU zu manipulieren.

Wie bereits erwähnt: Bei Multitasking Systemen ist es eine der 
wichtigeren Aufgaben des Beteriebssystems (und der Hardware), die 
einzelnen Tasks so voneinander zu trennen, dass es zu keiner wie auch 
immer gearteten unfreiwilligen gegenseitigen Beeinflussung kommt. 
Insbesondere darf ein Amok laufender Task nicht einfach so einen anderen 
Task beeinflussen in dem er einfach den Speicher niederbügelt.

[Matthias (Gast)]

Hallo Karl-Heinz,

danke für die Erklärungen. Aber im Grunde bin ich damit nicht weiter, da 
ich einen "Zirkelbezug" habe: Um mir Administratorrechte durch 
Speicherüberschreiben zu verschaffen, brauche ich vorher schon 
Adminrechte, um die Adressverwaltung/MMU zu manupulieren.

Wir hatten einfach neulich im Kollegenkreise geplaudert, und irgendwie 
meint jeder, Cyberangriffe seien alltäglich, und überhaupt seien 95% der 
Privatrechner schon gehackt. Zusätzlich sieht und liest man z.B. bei 
heise.de regelmäßig von Pufferüberläufen, die ggf. genutzt werden 
können, um ein System zu kompromittieren, weshalb schnellstens Update xy 
eingespielt werden sollte.

Ich kann für mich dieses "ggf. genutzt werden können" nicht 
quantifizieren bzw. sonst irgendwie fassen (und ich habe auch nicht vor, 
wirklich etwas zu hacken o.ä.). Vielmehr habe ich "damals" 
Wirtschaftsinformatik studiert, kenne daher "theoretisch" auch die 
Betriebssystemkonzepte sowie Programmierung (bin aber berufsmäßig eher 
bei "Wirtschaft" gelandet).

Mir fehlt einfach zum Verständnis der letzte Schritt von "ich schreibe 
Daten in den Speicherbereich eines anderen Prozesses" zu "ich habe 
Adminrechte auf dem System".

Im Grunde muss es wohl wie folgt laufen: Nicht im Datenbereich des 
Speichers, sondern im Funktionsaufrufsbereich (Stack) liegen 
Rücksprungsadressen. Ein mit Admin-Rechten laufendes Programm hat 
seinerseits eine andere Funktion aufgerufen und vorher seine 
Rücksprungadresse dort abgelegt. Ich als Angreifer schreibe eine 
"bösartige" Funktion (etwa rufe eine Shell auf) und ermittle deren 
Adresse und packe sie - nach trial&error - auf den Stack. Wenn jetzt das 
Adminprogramm bzw. das davon aufgerufene zurückspringen will, sucht es 
sich die Sprungadresse raus, erwischt aber die von mir dort stattdessen 
hinterlegte Adresse, springt daher in meine Funktion, und schon habe ich 
eine Eingabeaufforderung mit Admin-Rechten.

In diesem theoretischen Vorgang, glaube ich nur, dass bei Manipulation 
des Stack es viel eher zu einem Crash des Admin-Programmes kommen wird. 
Und außerdem muss ich erst einmal Schreibrechte auf beliebige Stellen 
bzgl. des Stack bekommen...

Die Frage ist, läuft es wirklich so ab, oder gibt es noch andere 
Möglichkeiten?

[Μαtthias W. (matthias)]

Hi

Wenn der angegriffene Prozess (Programm) nicht schon mit Adminrechten 
läuft ist das typischerweise ein (mindestens) zweistufiger Vorgang. 
Erstmal greift man ein Programm an um eigenen Code zur Ausführung zu 
bringen und dann versucht man über eine Fehler im OS höhere Rechte zu 
erlangen.

http://de.m.wikipedia.org/wiki/Rechteausweitung

In heutigen Systemen kann das ordentlich komplex werden da sich ein 
Angreifer diversen Hürden stellen muss um z.B. per manipulierter 
Onlinewerbung an Adminrecht zu kommen.

Matthias

[Bitflüsterer (Gast)]

Nur das der Stack auch von der MMU verwaltet wird - da es einfach nur 
Speicher ist.

Das ist nichts was man eben mal an 'nem Abend ausprobiert um am 
folgenden Abend am Stammtisch darüber nett zu plaudern. Vielmehr geht es 
um ein sehr spezielles Thema. Die Tatsache, dass oft recht einfach 
aussehende Kommandos und Vorgänge reichen um sich irgendwo rein 
zuhacken, verdeckt, dass man diese Kommandos, Funktionen etc. in der 
Regel so gar nicht ausführt, weil sie für den normalen Benutzer keinen 
Wert hätten. Mal abgesehen von dem Fall, das jemand gezielt nach solchen 
Lücken sucht, kommt man eher durch Zufall darauf. Um aber nach den 
Lücken zu suchen, braucht man schon ein recht gerütteltes Maß an 
Systemkenntnissen, Programmierfähigkeiten und Geduld.

[Bitflüsterer (Gast)]

Was Du da mit einfachem herum kopieren oder Stack überschreiben träumst, 
dass hat vor 30 Jahren vielleicht mal auf 'nem MP/M-Rechner geklappt. 
Seit 29 Jahren geht das da auch nicht mehr so einfach.

Wenn Du da nicht extreme Leidenschaften für entwickelst oder Deinen 
Lebensunterhalt mit verdienen willst, lass es einfach. Ehe Du soweit 
bist, dass Du da was findest, was aktuell funktioniert, haben Deine 
Enkel schon Häuser gebaut. Man muss auch bedenken, dass die Gurus auf 
dem Gebiet die Entwicklung von Angriffen und Gegenmassnahmen in der 
Regel auch schon seit Jahrzehnten mitmachen.

[Matthias (Gast)]

>Man muss auch bedenken, dass die Gurus auf
>dem Gebiet die Entwicklung von Angriffen und Gegenmassnahmen in der
>Regel auch schon seit Jahrzehnten mitmachen.

<<< Ein anderer Matthias

Eine sehr einseitige Betrachtung der Materie.

Neben 'Gurus' auf dem Gebiet der IT-Sicherheit, gibt es da draußen 
abertausende User, denen etwaiges Know How fehlt.

Jeden Tag wird neue Software auf den Markt geworfen, die die gleichen 
Fehler, wie vor 30 Jahren aufweist, man muss sie nur finden.

Und Windows betreffend, ganz ehrlich, Windows ist alles andere, aber 
nicht 100 % Exploitgeschützt.

Darüber hinaus, sicher, es gibt Sprachen welche Typsicherheit als Kredo 
formulieren, aber nach wie vor kann mit C,...,... programmiert werden.

[Bitflüsterer (Gast)]

Matthias schrieb:

> <<< Ein anderer Matthias
>
> Eine sehr einseitige Betrachtung der Materie.

Ach.

[Markus K. (markus-)]

Es gibt im Prinzip zwei Ansätze:
1) Ein Programm mit Adminrechten verarbeitet Daten (zB per TCP/IP oder 
es liest Daten von der Platte) und hat in der Verarbeitung einen Fehler. 
Wenn Du diesen Fehler findest und der geeigneter Natur ist, dann kannst 
Du mit manipulierten Daten zB den Stack überschreiben. Auf dem Stack 
liegen nicht nur die Rücksprungadressen, sondern auch die 
Funktionsparameter und die lokalen Variablen.
2) Jedes Programm kann Betriebssystemaufrufe machen und wenn eine 
Funktion des Betriebssystems nicht sauber programmiert wurde und seine 
Parameter nicht richtig überprüft, dann kannst Du damit ebenfalls 
Variablen bzw. den Stack überschreiben. Du bist dann im Betriebssystem 
und hast alle Rechte.

Wie das mit dem Stack überschreiben funktioniert wird zB in der 
Wikipedia erklärt: http://en.wikipedia.org/wiki/Stack_buffer_overflow
Dort werden auch die von Bitflüsterer erwähnten Gegenmaßnahmen 
besprochen.

Prinzipiell geht es dabei um das Finden von Fehlern. Meistens 
Programmierfehlern, seltener auch um Konfigurations- oder Designfehler.

[Diek (Gast)]

Kann man sowas nicht über den shared memory machen? Zumindest in c++ 
würde das ja zum Datenaustausch zwischen zwei Programmen funktionieren

[Rufus Τ. F. (rufus)]

Diek schrieb:
> Kann man sowas nicht über den shared memory machen?

An den muss man aber erst mal herankommen. Und um auf Speicherbereiche, 
die anderen Prozessen gehören, zugreifen zu können, bedarf es 
entsprechender Berechtigungen.

Mit Programmiersprachen hat das ganze weniger zu tun.

[Bronco (Gast)]

Matthias schrieb:
> Mir fehlt einfach zum Verständnis der letzte Schritt von "ich schreibe
> Daten in den Speicherbereich eines anderen Prozesses" zu "ich habe
> Adminrechte auf dem System".

Der ganze Sinn von Task-Trennung, Speicherschutz, Rechteverwaltung etc. 
ist ja genau, Deine dunklen Absichten zu verhindern.
Wenn es so einfach wäre, sich Adminrechte zu beschaffen, bräuchte man 
keine Adminrechte.
Das von Dir beschriebene Szenario funktioniert nur dann, wenn
- das System keinen entsprechenden Schutzmechanismen hat (z.B. das alte 
AmigaDOS),
- oder in Programmcode, der mit höheren Rechten läuft, ein Fehler 
existiert, der sich ausnutzen läßt. Solange Du nicht explizit so einen 
Fehler ausnutzst, kannst Du Dir auch nicht höhere Rechte beschaffen.

[Hans Ulli K. (Gast)]

Hallo,

auch wenn du Adminrechte auf deinem System besitzt, wird du niemals 
die MMU manipulieren können.
Siehe http://de.wikipedia.org/wiki/Ring_%28CPU%29

Du bewegt dich allenfalls auf dem Ring 1.
Auf Ring 0  (Kernel) darfst du die MMU verändern (z.B. Gerätetreiber)

Die Lösung von deinem Problem sollte hier sein :
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366551%28v=vs.85%29.aspx

[uwe (Gast)]

http://www.codeproject.com/Articles/28318/Bypassing-PatchGuard#_1_2
http://uninformed.org/?v=8&a=2&t=pdf

[Peter II (Gast)]

Hans Ulli Kroll schrieb:
> Die Lösung von deinem Problem sollte hier sein :
> 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366551%28v=vs.85%29.aspx

nein, da muss ja der andere Prozess mitspielen:

damit geht es:
https://msdn.microsoft.com/de-de/library/windows/desktop/ms681674(v=vs.85).aspx

unter Linux könnte man einfach in /dev/mem rumschreiben.

[fgfg (Gast)]

Man sieht hier mal wieder wie unvollständig das wissen selbst mehrere 
Fachleute sein kann wenn niemand sich damit ernsthaft beschäftigt und 
das wir hier eine Hardwareform haben.

Wenn du es nicht explizit deaktivierst wird dir jeder aktuelle Compiler 
aus genau deinen Absichten mindestens folgenden Schutzmechanismus 
einbinden.

http://de.wikipedia.org/wiki/Address_Space_Layout_Randomization

Damit lässt sich zwar erst mal kein buffer overflow verhindern, jedoch 
ist die RAM-aufteilung immer anders. Lesen/Schreiben von fremden 
Prozessvariablen  so wie du es vor hast funktioniert nur an dynamischen 
Adressen.

Das hat mit windows api und mmu erst mal nix zu tun

Meine Empfehlung: such dir eine geeigneteres Forum wenn du dich 
ernsthaft damit beschäftigen willst.

[Heinz L. (ducttape)]

Ui, endlich mal was wo ich 'ne Antwort geben kann statt nur fragend blöd 
rumzustehen. :)

Buffer overflows (und die zugehörigen Exploits) sind im Prinzip nicht 
weiter kompliziert, man sollte allerdings ein wenig Wissen um die 
Funktionsweise des x86 (oder irgendeines) Assemblers mitbringen. Da ich 
jetzt nicht weiss wie die geneigten Boardmods drauf reagieren wenn ich 
hier "Hacking 101" abspule, belass ich's besser beim theoretischen Teil. 
Wobei ich dazu sagen will dass "einfach mal eben" Buffer-Overflow nutzen 
ohnehin spätestens mit Windows Vista und ASLR nicht mehr "einfach so" 
funktioniert.

Was es braucht damit das funktioniert ist ein Programm, das eine 
Schwachstelle hat, und zwar eine sehr besondere. Das Programm muss 
Userdaten verarbeiten (also irgendwelchen Input, der Klassiker beim 
Buffer Overflow sind Strukturen die entweder variable Länge haben können 
oder wo das System dämlicherweise die Länge der Struktur sich vom 
Benutzer vorgeben läßt). Zusätzlich muss das Programm diese Daten auf 
dem Stack speichern. Wird hier nun nicht hinreichend geprüft ob die 
Strukturlänge stimmt, kann ein Angreifer indem er mehr Daten schreibt 
als das Programm erwartet die Rücksprungadresse der Subroutine 
überschreiben. Und da PCs nunmal von Neumann Maschinen sind und Daten 
und Programme (anders als in den üblichen µC) im gleichen Speicher 
untergebracht sind, kann man so, wenn man weiss wo die Daten liegen, die 
Rücksprungadresse in den Datenbereich umbiegen.

Und da man selbst ja diese Daten übergeben hat, bestimmt man auch was 
dort liegt. Zum Beispiel eben Code der irgendwas "Böses" macht. Der 
läuft dann mit den Rechten des Programmes, das da eben grad läuft. Weil 
das Programm eben der Ansicht ist, ohnehin nur "selbst" grad zu laufen.

Mit ASLR ist das natürlich jetzt viel komplexer geworden, weil es eben 
schwerer (leider nicht unmöglich) wird vorherzusagen, wo denn die Daten 
für den Rücksprung rumliegen werden.

[Peter II (Gast)]

Heinz L. schrieb:
> Und da man selbst ja diese Daten übergeben hat, bestimmt man auch was
> dort liegt. Zum Beispiel eben Code der irgendwas "Böses" macht.

dazu kommt aber noch die Hürde, das man Speichseite als nicht 
"ausführbar" kennzeichnen kann. Dann kann diese code auch nicht einfach 
gestartet werden.

[Heinz L. (ducttape)]

Meinst Du damit das IMAGE_SCN_MEM_EXECUTE Flag aus dem PE-Header? Das 
hat Windows noch nie wirklich dabei gestört irgendwas auszuführen.

Falls Du DEP meinst, ja, das wäre toll. Wenn's durchgängig funktionieren 
würde. Meines Wissens ist nicht mal MS selbst vollständig "DEP-Konform". 
Und spätestens bei diversen Kopierschutzverfahren mit 
selbstmodifizierendem Code ist ohnehin Schluss.

Den größten Schutz in diesem Zusammenhang würde die ASLR bieten. Auch 
weil diese nicht von der Kooperation anderer Softwarehersteller abhängig 
ist. Wenn sie endlich richtig implementiert würde. Meine Fresse, sogar 
die Gratiscodeklopfer von Linux haben's hinbekommen, aber MS eiert seit 
3 Desktopversionen rum.

[Peter II (Gast)]

Heinz L. schrieb:
> Meinst Du damit das IMAGE_SCN_MEM_EXECUTE Flag aus dem PE-Header? Das
> hat Windows noch nie wirklich dabei gestört irgendwas auszuführen.
>
> Falls Du DEP meinst, ja, das wäre toll. Wenn's durchgängig funktionieren
> würde. Meines Wissens ist nicht mal MS selbst vollständig "DEP-Konform".
> Und spätestens bei diversen Kopierschutzverfahren mit
> selbstmodifizierendem Code ist ohnehin Schluss.
naja, dann muss der Prozess halt ausführbaren Speicher reservieren. 
Dafür müsste man aber diese Programm anpassen.

> Den größten Schutz in diesem Zusammenhang würde die ASLR bieten. Auch
> weil diese nicht von der Kooperation anderer Softwarehersteller abhängig
> ist. Wenn sie endlich richtig implementiert würde. Meine Fresse, sogar
> die Gratiscodeklopfer von Linux haben's hinbekommen, aber MS eiert seit
> 3 Desktopversionen rum.

ist doch schon seit Vista drin oder was meinst du?

[Heinz L. (ducttape)]

Peter II schrieb:

> ist doch schon seit Vista drin oder was meinst du?

Ist es. Vista, 7, 8 und jetzt bald 10. Mal gucken ob sie dort dann den 
Zufallsgenerator so hingebogen haben dass er auch wirklich die 
Adressräume zufällig vergibt.

Irgendwie scheint das für MS echt ein dramatisches Problem zu sein.

Egal, irgendwie glaub ich hilft das dem Threaderöffner jetzt nicht 
unbedingt weiter. Die Frage ist eher... ja, was genau würde ihm 
weiterhelfen?

[Georg (Gast)]

Heinz L. schrieb:
> Die Frage ist eher... ja, was genau würde ihm
> weiterhelfen?

Leider oder Gottseidank ist Hacker noch keine anerkannte 
Berufsausbildung, auch die Mafia veranstaltet da keine Seminare zur 
Weiterbildung, sondern bedient sich einfach aus dem Pool derer, die sich 
auf dem Gebiet selbst weitergebildet haben, wobei eine Ausbildung in 
Systemprogrammierung durchaus eine gute Grundlage ist.

Der TO ist da schon auf dem richtigen Weg, bloss im falschen Forum, hier 
ist nicht die Expertise vertreten, die er sucht. Ausserdem habe ich den 
Eindruck, dass sein Grundlagenwissen nicht annähernd ausreicht: dass man 
in Windows einfach in den Speicher einer anderen Anwendung schreiben 
kann bloss weil die Adresse anscheinend gleich ist, ist schon sehr naiv. 
Das ging noch unter CP/M im 64k-Adressraum.

Georg

[Matthias (Gast)]

Moin,
darauf möchte ich als TO doch noch mal antworten: Mir ist völlig klar, 
dass der Ansatz des initialen Postings naiv ist - aber immerhin war er 
der Auslöser für diesen Thread, in dem ja doch noch einige interessante 
Beiträge gelandet sind. Zudem ging es mir um ein grundlegendes 
Verständnis, und da wollte ich ein möglichst einfaches Beispiel als 
Start wählen, das eben von allen möglichen, verkomplizierenden Themen, 
abstrahiert. Das (Thema) wurde dann ja ein Selbstläufer ;-)

Außerdem (vgl. meinen Beitrag vom 10.04., 18:37) habe ich nicht wirklich 
das Interesse, ein Hacker o.ä. zu werden, sondern möchte ein Gefühl 
dafür kriegen, wie einfach es tatsächlich ist, sich Adminrechte zu 
verschaffen. Die Qualität der Antworten hier im Forum zu allen möglichen 
Fragen schätze ich i.d.R. sehr hoch ein - insofern sehe ich Euch als 
Fachleute an. Danke dafür!

Für mich erhalte ich als Ergebnis eine Bestätigung meiner Vermutung, 
dass die bloße Existenz einer Sicherheitslücke nicht ausreicht, um 
Adminrechte zu bekommen und so den Rechner zu hacken. Vielmehr ist ein 
tiefes Verständis und Kenntnis des jeweiligen Betriebssystems notwendig. 
Wenn das ganze dann auch noch über das Netz durchgeführt werden soll, 
existieren weitere Hürden.
Zurück zu der (pauschalen) Aussage, dass eh 95% aller Privatrechner 
heute bereits gehackt seien (vgl. ebenfalls mein Posting vom 10.04., 
18:37): Sofern die "normalen" Sicherheitsvorkehrungen eingehalten werden 
(Einspielen von Updates, Firewall, aktueller Virenscanner; nicht 
bedenkenlos surfen bzw. auf Links (auch nicht in Mails) klicken, usw.), 
gibt es keinen Grund zu der Annahme, der Rechner sei kompromittiert. 
Denn wenn er es dennoch wäre,  müsste jemand (=der Angreifer) entweder 
verdammt viel Glück gehabt haben (Zufall), oder aber über sehr 
umfangreiches Wissen verfügen; dieser (zeitliche) Aufwand ist bei einem 
Privatrechner vermutlich eher nicht gerechtfertigt. Ob jetzt 95% aller 
Privatleute sich auch tatsächlich sicherheitsbewusst verhalten, bzw. ob 
die eigenen Daten im Netz ebenfalls sicher sind, sind zwei ganz andere 
Fragen...

[Heinz L. (ducttape)]

Georg schrieb:

> Leider oder Gottseidank ist Hacker noch keine anerkannte
> Berufsausbildung

Dochdoch, ist es. In Österreich zumindest kenne ich die Uni Hagenberg, 
die ein Magisterstudium für Information Security Management anbietet. 
Das umfasst zugegebenermaßen etwas mehr als "nur" das und schließt 
natürlich auch Dinge wie IT Governance und ITSM ein, hat aber auch seine 
technischen Seiten. Ist jetzt halt Österreich, würd mich aber wundern 
wenn es sowas nicht auch schon in Deutschland gibt. Ausser Euer 
Rollstuhlparanoiker hat den Boden dafür hinreichend vergiftet.

Gibt's halt noch nicht so lang, und alle "Alten" in dem Gewerbe haben 
sich das Ganze halt mehr oder weniger autodidaktisch (mit ggf. 
vorhandener "normaler" IT Ausbildung/Studium als Grundlage) 
rangeschafft.


@Matthias (Gast): Nein, nur die Existenz so einer Sicherheitslücke 
reicht nicht. Es würde aber auch das Problem auf die leichte Schulter 
nehmen heißen, würde man jetzt annehmen dass dieses arkane Wissen nur 
einem kleinen Kreis eingeweihter Druiden bekannt wäre und diese es nur 
innerhalb ihres erlauchten Zirkels weitergeben würden. Erstens kann das 
jeder problemlos per Google usw. in endlicher Zeit rausfinden und auch 
lernen. Und selbst wenn nicht, dazu gibt's üblicherweise (wenngleich 
auch nur gegen Einwurf kleiner Münzen) fertige Kits. Vergleichbar ist 
das in etwa damit wie Spiele "gecrackt" werden. Können tun das nicht 
sooo viele. Aber man muss nicht verstehen wie ein Crack funktioniert um 
ein gecracktes Spiel zum Laufen zu bringen. Doppelclick auf das Programm 
mit dem Namen Crack reicht dazu aus.

Ähnlich verhält es sich mit den Exploits. Ja, die Anzahl der Leute die 
sowas wirklich selbst ausnutzen können ist eher überschaubar. Aber man 
muss es nicht können um ein exploit-kit verwenden zu können.

[Kaj G. (Firma: RUB) (bloody)]

Georg schrieb:
> Leider oder Gottseidank ist Hacker noch keine anerkannte
> Berufsausbildung,
Mööp. falsch!

Uni Bochum: IT-Sicherheit BA+MA (MA vertiefung: Embedded-Systems, 
Internet, usw.) | Studiengang seit mehr als 10 Jahren

Uni Saarland: Cyber-Security BA | Studiengang 2014 gegründet

Um nur mal 2 Studiengänge/Unis in Deutschland zu nennen.


An Matthias:
Ich kann dir ein paar Bücher empfehlen:

Hacker's Guide - http://amzn.to/1FXx5AV
Moderne Betriebssysteme - http://amzn.to/1b0dYeN
Hacking mit Python - http://amzn.to/1EMkXEl
Hacking - The Art of Exploit - http://amzn.to/1czlDSx
Penetration Testing mit Metasploit - http://amzn.to/1GP3f4J
Das Phantom im Netz: Die Autobiographie des meistgesuchten Hackers der 
Welt - http://amzn.to/1DLVREC
PHP-Sicherheit - http://amzn.to/1GP42me
Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing 
Tools, and Obfuscation - http://amzn.to/1HbDVV2

Diese Seite ist ebenfalls interessant:
http://www.enigmagroup.org/
Wenn du eine Frage hast, dann kannst du die dort stellen.

Es könnte für dich ebenfalls interessant sein, mal auf die 
Security-Mailing-Lists zu schauen.
http://seclists.org/

Hier ein Tutorial zu Buffer-Over-Flows:
http://netsec.ws/?p=180

Hacker-News:
http://www.enigmagroup.org/hackers-home-page/
https://news.ycombinator.com/newest

Exploit-DB:
http://www.exploit-db.com/

Linux-Distros:
Kali Linux - Eigenständige Distro basierend auf Debian (früher: 
BackTrack) - https://www.kali.org/

Black Arch Linux - Kann unter Arch einfach als Repo eingetragen werden, 
oder als eigene Distro genutzt werden - http://www.blackarch.org/