Sicherheitslücken

Für allgemeine Fragen zur Programmierung, welche nicht! direkt mit Lazarus zu tun haben.

Sicherheitslücken

Beitragvon Mathias » 9. Sep 2016, 16:54 Sicherheitslücken

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. :roll:
Man denke nur an Windows, welches hunderte solche Fehler enthält, dabei könnte man solche Programmier-Fehler sehr einfach beheben.
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 2401
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon mischi » 9. Sep 2016, 23:16 Re: Sicherheitslücken

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.
MiSchi macht die fink-Pakete
mischi
 
Beiträge: 146
Registriert: 10. Nov 2009, 18:49
OS, Lazarus, FPC: Mac OS X 10.10, 1.2.4, 2.6.4 | 
CPU-Target: 32Bit/64bit
Nach oben

Beitragvon Mathias » 10. Sep 2016, 07:40 Re: Sicherheitslücken

Das habe ich als Beispiel genommen, dies könnte natürlich auch etwas Binäres sein.
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 2401
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Warf » 10. Sep 2016, 15:14 Re: Sicherheitslücken

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).
Warf
 
Beiträge: 499
Registriert: 23. Sep 2014, 16:46
Wohnort: Aachen
OS, Lazarus, FPC: Mac OSX 10.11 | Win 10 | FPC 3.0.0 | L trunk | 
CPU-Target: x86_64, i368, ARM
Nach oben

Beitragvon Mathias » 11. Sep 2016, 20:24 Re: Sicherheitslücken

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.
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 2401
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Warf » 11. Sep 2016, 21:12 Re: Sicherheitslücken

Mathias hat geschrieben:
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
Warf
 
Beiträge: 499
Registriert: 23. Sep 2014, 16:46
Wohnort: Aachen
OS, Lazarus, FPC: Mac OSX 10.11 | Win 10 | FPC 3.0.0 | L trunk | 
CPU-Target: x86_64, i368, ARM
Nach oben

Beitragvon fpGUIcoder » 12. Sep 2016, 10:43 Re: Sicherheitslücken

Mathias hat geschrieben: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. :roll:


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.

Mathias hat geschrieben: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.
fpGUIcoder
 
Beiträge: 199
Registriert: 20. Okt 2015, 22:13

Beitragvon Requion » 12. Sep 2016, 12:22 Re: Sicherheitslücken

fpGUIcoder hat geschrieben: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.
Mfg Requion

Das beste an Standards ist, dass es so viele davon gibt.
Requion
 
Beiträge: 106
Registriert: 3. Feb 2016, 09:39
Wohnort: nahe Grimma
OS, Lazarus, FPC: Linux(Arch Linux(+ARM)/Minibian) (L 1.6.0 FPC 3.0.0) | 
CPU-Target: 32/64Bit,ARM(RPi)
Nach oben

Beitragvon fpGUIcoder » 12. Sep 2016, 13:01 Re: Sicherheitslücken

Requion hat geschrieben:
fpGUIcoder hat geschrieben: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!
fpGUIcoder
 
Beiträge: 199
Registriert: 20. Okt 2015, 22:13

Beitragvon Mathias » 12. Sep 2016, 16:50 Re: Sicherheitslücken

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.
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 2401
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

• Themenende •

Zurück zu Programmierung



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

porpoises-institution
accuracy-worried