Scripting engine -> nativer Code - Sicherheit?

[Tilt!]

Hallo!

Ich möchte gerne Skripte eines Programms durch DLLs / nativen Code ersetzen.

Das Programm hat scheinbar eine VM integriert, denn es existiert ein externer Compiler, der das an C angelehnte Skript übersetzt und eine .SCR datei erstellt. Diese wird dann vom Programm ausgeführt.

Es gibt aber einige Bugs, und da es keinen Quellcode gibt, möchte ich jede .SCR durch DLLs ersetzen.
Das ist nicht das Problem (Script_Execute hooken und DLL Funktion mit entsprechender "Message" als Callback aufrufen).

Doch ich mache mir Sorgen um die Sicherheit.
Die Skripte erlauben nur ganz bestimmte Funktionsaufrufe.

tl;dr
Wenn ich nun DLLs unterstütze, könnten diese schadhaften Code beinhalten.

Ich suche nun nach einer Möglichkeit, die "Privilegien" der DLL sinnvoll zu begrenzen.
Zuerst dachte ich daran, die IAT, also die importierten Funktionen, zu checken.
Doch es gibt so viele Funktionen, das wäre sehr aufwändig oder gar nicht sinnvoll möglich.
Die STL soll zB. unterstützt werden. Ich wüsste aber gar nicht, ab welcher Funktionalität man schon ernsthaft schädlichen Code erzeugen kann...
Nur Winsock sperren wird wohl nicht reichen...

Fällt euch etwas dazu ein?
Danke jedenfalls!

MfG

[alu]

Was spricht gegen verbreitete Scriptsprachen wie z.B. Lua oder AngelScript?

[Tilt!]

C++ ist doch viel mächtiger

[TyRoXx]

Tilt! schrieb:

Wenn ich nun DLLs unterstütze, könnten diese schadhaften Code beinhalten.

Wirklich? Wer macht diese DLLs denn und wer führt sie dann aus?

Tilt! schrieb:

Ich suche nun nach einer Möglichkeit, die "Privilegien" der DLL sinnvoll zu begrenzen.
Zuerst dachte ich daran, die IAT, also die importierten Funktionen, zu checken.
Doch es gibt so viele Funktionen, das wäre sehr aufwändig oder gar nicht sinnvoll möglich.
Die STL soll zB. unterstützt werden. Ich wüsste aber gar nicht, ab welcher Funktionalität man schon ernsthaft schädlichen Code erzeugen kann...
Nur Winsock sperren wird wohl nicht reichen...

In jedem Fall müsstest du einen separaten Prozess verwenden. Anders kann man beliebige DLLs nicht vom Host trennen. Die würden dann auch unter einem anderen Benutzer laufen. Ich weiß nicht, wieviel man einem Benutzer oder Prozess mit Windows verbieten kann. Ganz einfach wird das aber nicht werden.

[Ethon]

Mindestens mit direkten Syscalls kommt man auf jede Systemfunktionalität runter. Vergiss es.