Execution Flow Control

Dieses Thema: "Execution Flow Control" im Forum "Security Talk" wurde erstellt von hoza, 17.08.2003.

  1. hoza

    hoza Jungspund

    Dabei seit:
    16.08.2003
    Beiträge:
    10
    Zustimmungen:
    0
    Hi :)

    Ich hab jetzt von einem Schutz gelesen, der laut Hersteller 100% Sicherheit bieten soll. Ich will jetzt keine Diskussion lostreten "Es gibt keine 100prozentige Sicherheit *bla*". Klar sind trotzdem Konfgurationsfehler möglcih und viele andere Schwachstellen. Nur das Modell klingt ziemlich interessant und könnte kiddies den Gar ausmachen, da exploits ziemlich komplex werden müssten. Es handelt sich hierbei um einen sogenannten Execution Control Flow Schutz. Die entsprechende Homepage findet ihr unter http://203.197.88.14/efc findet.

    Um das Grundprinzip zu erklären: Jeder Prozess interagiert mit den Systemressourcen über die Syscalls. Nichts geht ohne diese im Kernel verankerten Routinen und deswegen setzt efc genau dort an. Es wird vor der Ausführung ein Ausführungsverhalten Modell erstellt und in den kernel geladen. So kann schonmal kein user space Prozess an dieses Verhaltensmuster heran. Werden jetzt bei einem Angriff syscalls aufgerufen, die nicht in dieses Verhaltensmodell passen (man denke an die shellcodes), so wird eine execption ausgelöst. Klingt alles in Allem ziemlih gut, oder was meint ihr? Die einzige Methode, die ich hierfür sehe ist einen Shellcode zu bauen, der auch dummy-syscalls mit eindeckt. Also einen in das Verhaltensmodell passenden. Allerdings dürfte das ja dann auch ziemlich komplex werden, da man entsprechend lang diesen workflow emulieren muss mit seinem code. Und wenn man erst 20 dummy calls vollziehen muss bevor man endlich mal ein execve() bekommt, dann ist das schon ziemlich overhead.

    Naja eigentlich gehts mir nur darum mal ein paar Ideen von euch zu hören und einfach mal eure Meinung zu wissen. Im Grundprinzip sieht mir dieser Schutz nämlich weitaus besser aus als non-exec pages, memory layout randomization und andere Tricks ala PaX, grsec oder Owl.

    regards hoza
     
  2. Anzeige

    schau mal hier --> (hier klicken). Viele Antworten inkl. passender Shell-Befehle!
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  3. #2 megamimi, 17.08.2003
    megamimi

    megamimi Nörgler vom Dienst

    Dabei seit:
    12.01.2003
    Beiträge:
    469
    Zustimmungen:
    0
    Ort:
    /home/megamimi
    hi...

    Also anhören tut sich das ganze auf jeden Fall schonmal sehr gut, keine Frage.

    Das was mich interessieren würde ist, ob durch die zusätzliche Schicht zwischen Kernel und Userspace das ganze System nicht ziemlich "ausgebremst" werden würde. Schließlich müssen alle Syscalls "abgesegnet" werden, oder hab ich das ein wenig falsch verstanden?

    Außerdem: Wer legt das "Verhaltensmuster" fest, das einzelne Programme haben? Müssen das die Programmierer des Programmes selbst tun?

    cu mimi
     
  4. chb

    chb Steirer

    Dabei seit:
    01.06.2003
    Beiträge:
    2.359
    Zustimmungen:
    0
    Ort:
    ÖSTERREICH
    Klingt ja ganz gut nur solche Verhaltensmuster würden ;


    Jedes Programm um Faktor 2 - 4 verlangsam
    Man müßte für jedes Programm eine Art Aura erstellen.
    Es ist nicht 100% sicher ob der Verhaltenscode net auch die Normale Funktion eines Programmes blockiert
     
Thema:

Execution Flow Control

Die Seite wird geladen...

Execution Flow Control - Ähnliche Themen

  1. PostgreSQL for Linux Payload Execution

    PostgreSQL for Linux Payload Execution: On some default Linux installations of PostgreSQL, the postgres service account may write to the /tmp directory, and may source UDF Shared...
  2. IrfanView 4.33 IMXCF.DLL Code Execution

    IrfanView 4.33 IMXCF.DLL Code Execution: IrfanView version 4.33 suffers from a code execution vulnerability in IMXCF.DLL. Weiterlesen...
  3. Splunk 5.0 Custom App Remote Code Execution

    Splunk 5.0 Custom App Remote Code Execution: This Metasploit module exploits a feature of Splunk whereby a custom application can be uploaded through the web based interface. Through the...
  4. Novell NetIQ Privileged User Manager 2.3.1 auth.dll Code Execution

    Novell NetIQ Privileged User Manager 2.3.1 auth.dll Code Execution: Novell NetIQ Privileged User Manager version 2.3.1 suffers from a remote code execution vulnerability in pa_modify_accounts() in auth.dll. The...
  5. Novell NetIQ Privileged User Manager 2.3.1 ldapagnt.dll Code Execution

    Novell NetIQ Privileged User Manager 2.3.1 ldapagnt.dll Code Execution: Novell NetIQ Privileged User Manager version 2.3.1 suffers from a perl code evaluation remote command execution vulnerability in ldapagnt_eval()...