Sicherheitslücken

[Mathias]

So einfach kann es einem passieren, das man eine Sicherheitslücke reinprogrammiert.

Code: Alles auswählen

const
  filename = 'data.txt';
 
var
  rec: TRec;
 
  TRec = record
    Data: array[0..3] of Char;
    passwd: array[0..39] of Char;
  end;
 
{ TForm1 }
 
procedure TForm1.FormCreate(Sender: TObject);
begin
  rec.passwd := 'passwort';
  Label1.Caption := rec.passwd;
end;
 
procedure TForm1.Button1Click(Sender: TObject);
var
  f: file of char;
  i, l: integer;
begin
  AssignFile(f, filename);
  Reset(f);
  l := FileSize(filename); // Hier ein grosser Fehler
  for i := 0 to l-1 do begin
    Read(f, rec.Data[i]); // Heir gibt es den Überlauf !
  end;
  CloseFile(f);
  Label1.Caption := rec.passwd;
end;

Der Programmierer wollte zB. nur ein Spielstand laden, welcher normalerweise 4 Byte hat und den Inhalt "abcd" hat, also ist die Datei 4 Byte gross.
Das Programm hat ein Zugang welcher durch ein Passwort geschützt ist, im Beispiel "passwort", welches der Hacker natürlich nicht kennt.
Da aber das Programm einen Fehler hat, hat der Hacker die data.txt abgeändert welche dann folgenden Inhalt hat: "abcd12345678".
Somit heisst das Passwort auf einmal nicht mehr "passwort", sondern "12345678" und schon hat der Hacker Zugang zum geschützten Bereich.

Was mich aber erstaunt, das es in der Praxis so viele solche Überlauffehler gibt, welche die Hacker dann für einen Trojaner ausnutzen können.
Man denke nur an Windows, welches hunderte solche Fehler enthält, dabei könnte man solche Programmier-Fehler sehr einfach beheben.

[mischi]

Ist nicht schon auch das Passwort in Klartext im Code ein Bringer. Das bekommt man doch mit strings prompt geliefert und mit wenigen Versuchen hat man es.

[Mathias]

Das habe ich als Beispiel genommen, dies könnte natürlich auch etwas Binäres sein.

[Warf]

Dein Beispiel ist sowieso nicht sicher.

1. Der Angreifer kann das Programm selbst ändern/einsehen, das Passwort auslesen oder gar verändern. Die Rückführung einer Assembly in Quelltext heißt Reverse Engineering und ist eine gängige Praxis, und wenn man zugriff auf den Quelltext hat ist es sowieso mit der Sicherheit einer Solchen Sicherung vorbei.
2. Der Angreifer könnte zur Laufzeit in dein Programm eingreifen und einfach die Speicherzellen des Records überschreiben in dem das Passwort gesichert wird, und so ein eigenes Passwort Injizieren
3. Der Angreifer könnte eigenen Code in dein Programm injizieren welcher die Methodenaufrufe Abfängt, und auf deinen Daten rumspielt wie er lustig ist, bevor er mit die eigentliche Methode aufruft, oder er kann sogar Methodenaufrufe und Code Zeilen überspringen lassen, welche z.B. die Passwortüberprüfung durchführen.

Lustigerweise ist deine angeführte Sicherheitslücke sogar eine ziemlich schlechte, wenn das Programm z.B. auf einem Big-Endian System ausgeführt ist gibt es zwar einen Überlauf, aber dieser schreibt dann nicht in das Passwort, sondern außerhalb des Records (Man sollte sich nie mals auf Überläufe verlassen, anderes System->Anderes Verhalten).

[Mathias]

2. Der Angreifer könnte zur Laufzeit in dein Programm eingreifen und einfach die Speicherzellen des Records überschreiben in dem das Passwort gesichert wird, und so ein eigenes Passwort Injizieren

Genau, dies meine ich.

Das Beispiel sollte zeigen, wie man es nicht machen soll.

[Warf]

2. Der Angreifer könnte zur Laufzeit in dein Programm eingreifen und einfach die Speicherzellen des Records überschreiben in dem das Passwort gesichert wird, und so ein eigenes Passwort Injizieren

Genau, dies meine ich.

Das Beispiel sollte zeigen, wie man es nicht machen soll.

Man kann den Speicher des Programms allerdings immer ändern, dafür benötigt es nicht mal den Überlauf, Programme wie cheat Engine für Windows können einfach jeden Speicher eines Programmes verändern. Und da kann mn auch nichts gegen machen. Damit macht dein Überlauf das System auch nicht unsicherer als es nicht ohne hin schon ist

[fpGUIcoder]

So einfach kann es einem passieren, das man eine Sicherheitslücke reinprogrammiert.

Code: Alles auswählen

const
  filename = 'data.txt';
 
var
  rec: TRec;
 
  TRec = record
    Data: array[0..3] of Char;
    passwd: array[0..39] of Char;
  end;
 
{ TForm1 }
 
procedure TForm1.FormCreate(Sender: TObject);
begin
  rec.passwd := 'passwort';
  Label1.Caption := rec.passwd;
end;
 
procedure TForm1.Button1Click(Sender: TObject);
var
  f: file of char;
  i, l: integer;
begin
  AssignFile(f, filename);
  Reset(f);
  l := FileSize(filename); // Hier ein grosser Fehler
  for i := 0 to l-1 do begin
    Read(f, rec.Data[i]); // Heir gibt es den Überlauf !
  end;
  CloseFile(f);
  Label1.Caption := rec.passwd;
end;

Der Programmierer wollte zB. nur ein Spielstand laden, welcher normalerweise 4 Byte hat und den Inhalt "abcd" hat, also ist die Datei 4 Byte gross.
Das Programm hat ein Zugang welcher durch ein Passwort geschützt ist, im Beispiel "passwort", welches der Hacker natürlich nicht kennt.
Da aber das Programm einen Fehler hat, hat der Hacker die data.txt abgeändert welche dann folgenden Inhalt hat: "abcd12345678".
Somit heisst das Passwort auf einmal nicht mehr "passwort", sondern "12345678" und schon hat der Hacker Zugang zum geschützten Bereich.

Was mich aber erstaunt, das es in der Praxis so viele solche Überlauffehler gibt, welche die Hacker dann für einen Trojaner ausnutzen können.

Klar sollte man in der Programmierung darauf achten, solche Überlauffehler zu vermeiden, aber da interessiert mich dann doch mal, wieviel Prozent solcher Überlauffehler dann wirklich für solche Angriffe genutzt werden. Müssen dann doch schon wirklich Experten sein, die das können, besonders dann wenn der Quellcode nicht offen liegt.

Man denke nur an Windows, welches hunderte solche Fehler enthält, dabei könnte man solche Programmier-Fehler sehr einfach beheben.

[/quote]

Ach ja, und Linux ist 100% fehlerfrei programmiert???? Zweifel?

Und selbst wenn dem so wäre, Linux ist quelloffen. Ein Angreifer könnte demnach sich den Quelltext besorgen und dann einen Trojaner einbauen. Konnte man unter Linux nicht im laufenden Betrieb den Kernel neu kompilieren??? Damit hat so ein Angreifer alles was er braucht, um ein Linux zu kompromomittieren.

[Requion]

Ach ja, und Linux ist 100% fehlerfrei programmiert???? Zweifel?

Und selbst wenn dem so wäre, Linux ist quelloffen. Ein Angreifer könnte demnach sich den Quelltext besorgen und dann einen Trojaner einbauen. Konnte man unter Linux nicht im laufenden Betrieb den Kernel neu kompilieren??? Damit hat so ein Angreifer alles was er braucht, um ein Linux zu kompromomittieren.

Davon hat doch keiner gesprochen. Niemand ist der Meinung das Linux fehlerfrei ist. Und ja es ist quelloffen, und der "Hacker" könnte einen Trojaner einbauen. Aber was glaubst du wie er an den User kommt? Auf dem offiziellen Weg (Beispiel: ein kompromittieres Debian von deren Webseite) ist dies kaum möglich und mit Drittanbieter Kernel sollte man generell vorsichtig sein.

Ja Linux und Windows (und Mac) sind nicht perfekt, fehlerfrei und sicher. Aber von den dreien ist Windows schon von der Basis her das anfälligste. Sonst gäbe es ja für Linux und Mac schon mehr Schadsoftware.

[fpGUIcoder]

Ach ja, und Linux ist 100% fehlerfrei programmiert???? Zweifel?

Und selbst wenn dem so wäre, Linux ist quelloffen. Ein Angreifer könnte demnach sich den Quelltext besorgen und dann einen Trojaner einbauen. Konnte man unter Linux nicht im laufenden Betrieb den Kernel neu kompilieren??? Damit hat so ein Angreifer alles was er braucht, um ein Linux zu kompromomittieren.

Davon hat doch keiner gesprochen. Niemand ist der Meinung das Linux fehlerfrei ist. Und ja es ist quelloffen, und der "Hacker" könnte einen Trojaner einbauen. Aber was glaubst du wie er an den User kommt? Auf dem offiziellen Weg (Beispiel: ein kompromittieres Debian von deren Webseite) ist dies kaum möglich und mit Drittanbieter Kernel sollte man generell vorsichtig sein.

Ja Linux und Windows (und Mac) sind nicht perfekt, fehlerfrei und sicher. Aber von den dreien ist Windows schon von der Basis her das anfälligste. Sonst gäbe es ja für Linux und Mac schon mehr Schadsoftware.

Der Angreifer könnte immerhin eine seriös wirkende Webseite bauen und sein kompromittiertes Linux dort anbieten. Es gibt noch immer Leite, die alte Rechner von 2000 verwenden für die es passende Altversionen von Linux nicht mehr gibt. Das gefundene Fressen für den Angreifer, der dann so ein altes Linux dort anbietet. Ich selber schreibe dies hhier mit einem Rechner mit Mainboard Asus A7V 133 mit 1 GHz Cpu. Neuere Linux Versionen fordern entschieden zu viele Ressourcen, Knoppix wegen des 3D Würfels zum Desktopwechsel. Da brauche ich eine Uraltversion und könnte so Opfer der von mir geschilderten Praxis werden. Sicherer wäre Linux daher schon mal ohne die Forderung, jedes Jahr einen neuen Rechner kaufen zu müssen, indem man diese Uralt Versionen weiterhin anbietet!

[Mathias]

Klar sollte man in der Programmierung darauf achten, solche Überlauffehler zu vermeiden, aber da interessiert mich dann doch mal, wieviel Prozent solcher Überlauffehler dann wirklich für solche Angriffe genutzt werden.

Wen so was abgefangen wird, wie kann dann ein JPG-Bild oder ein PDF ein Sicherheitsrisiko sein ?
Ich habe schon gelesen, das ein JPG ein Überlauf erzeugt, und so Schads-Code erzeugt.