Prozess-Handles nur geringe Rechte erlauben

[Apollonius]

Hier habe ich mit der großen Hilfe von Dezipaitor eine Methode entwickelt, mit der man verhindern kann, dass Prozess-Handles zu große Rechte erlangen. Auf diese Weise kann man verhindern (oder zumindest erschweren, wenn das "feindliche" Programm mit Administrator-Rechten arbeitet), dass ein Prozess terminiert wird, dass Write/ReadProcessMemory oder die Virtual...Ex-Funktionen verwendet werden und so ziemlich alles, wofür Prozess-Handles gebraucht werden.

Delphi-Quellcode:

uses Sysutils,
     Windows,
     AclApi,  //Für SetSecurityInfo
     AccCtrl; //Für SE_KERNEL_OBJECT als Wert einer Aufzählung
function ConvertStringSecurityDescriptorToSecurityDescriptorA(StringSecurityDescriptor: PChar; StringSDRevision: DWORD; var SecurityDescriptor: PSECURITY_DESCRIPTOR;  SecurityDescriptorSize: PULONG): boolean; stdcall; external 'Advapi32.dll';
//Der letzte Parameter wird nicht als var deklariert, damit nil eingesetzt werden kann

//Zugangsrechte für eigenen Prozess setzen
//Rights: eine or-Verknüpfung aller Rechte, die noch erlaubt sein sollen
procedure SetProcessHandleRights(Rights: Cardinal); 
const PROTECTED_DACL_SECURITY_INFORMATION = $80000000;
      SDDL_REVISION_1=1;
var Desc: PSECURITY_DESCRIPTOR; SDDLString: ansistring;
    DACL: pACL; err: cardinal;
    d1, d2: LongBool; //Dummies
begin
SDDLString:='D:(A;;0x'+inttohex(Rights, 8)+';;;WD)';  //Näheres im PSDK unter SDDL
if not ConvertStringSecurityDescriptorToSecurityDescriptorA(PChar(SDDLString), SDDL_REVISION_1, Desc, nil) then
  raise EOSError.CreateFmt('Error in function ConverStringSecurityDescriptorToSecurityDescriptorA: %s', [syserrormessage(getLastError)]);
if not getSecurityDescriptorDACL(desc, d1, DACL, d2) then
  raise EOSError.CreateFmt('Error in function getSecurityDescriptorDACL: %s', [syserrormessage(getLastError)]);
//jetzt das Kernstück
err:=SetSecurityInfo(getCurrentProcess, SE_KERNEL_OBJECT, DACL_SECURITY_INFORMATION or PROTECTED_DACL_SECURITY_INFORMATION, nil, nil, DACL, nil);
if err<>0 then
  raise EOSError.CreateFmt('Error in function setSecurityInfo: %s', [syserrormessage(err)]);
end;


//Beispielaufruf
procedure TForm1.Button1Click(Sender: TObject);
var ProcId, ProcHandle: Cardinal;
begin
SetProcessHandleRights(PROCESS_ALL_ACCESS and not PROCESS_VM_WRITE); //WriteProcessMemory kann auf eigenen Prozess nicht mehr verwendet werden

//Test, ob es funktioniert hat
getWindowThreadProcessId(self.Handle, ProcId);
ProcHandle:=OpenProcess(PROCESS_ALL_ACCESS, false, ProcId); //Null-Handle-> hat funktioniert 
showmessage(inttostr(ProcHandle));
closeHandle(ProcHandle);
end;

Um das ganze sicher zu machen, muss man außerdem PROCESS_DUPLICATE_HANDLE verbieten, da sonst ein Handle mit PROCESS_ALL_ACCESS erlangt werden kann.

[edit=Matze]Dieses Thema reicht nicht ganz aus, um in die Code-Library aufgenommen zu werden. MfG, Matze[/edit]

[Zacherl]

Wo erschwert der Code beispielsweise das Terminieren des Prozesses? Ich habe alle Rechte für meinen Prozess eingeschränkt, aber terminieren über den Taskmanager kann ich ihn trotzdem noch.
Genauso der Testaufruf: Erfolgreich das Handle zurückgegeben.

[DGL-luke]

Zitat:

Zitat von Zacherl

Wo erschwert der Code beispielsweise das Terminieren des Prozesses?

Terminieren _fremder_ Prozesse.

[Win32.API]

Bei mit funktioniert es auch nicht, es gibt ein gueltiges handle.

[Zacherl]

Bei mir nämlich auch ..

[Apollonius]

Über den Taskmanager will ich nichts gesagt haben, hier geht es nur darum, von anderen Prozessen mit TerminateProcess terminiert zu werden - ich habe keine Ahnung, wie der Taskmanager sowas macht.
Wie habt ihr denn die Rechte im Aufruf von SetProcessHandleRights und im Aufruf von OpenProcess gesetzt? Bei mir funktioniert es tadellos. Ich arbeite mit XP als Administrator.

[Zacherl]

Habe einfach deine Demo verwendet wo es um das WriteProcessMemory Handle geht. Schon da, also in der eigenen Anwendung bekomme ich ein gültiges Handle.

Arbeite mit Adminrechten unter XP Home.

[Apollonius]

Ich bin schockiert. Mit dem Demo-Code kriege ich nämlich ein Null-Handle. Irgendwelche Einwürfe von den WinAPI-Gurus?
Irritierend ist vor allem, dass wir in der gleichen Umgebung arbeiten und unterschiedliche Ergebnisse bekommen...

[Dezipaitor]

Zitat:

Zitat von Apollonius

Ich bin schockiert. Mit dem Demo-Code kriege ich nämlich ein Null-Handle. Irgendwelche Einwürfe von den WinAPI-Gurus?
Irritierend ist vor allem, dass wir in der gleichen Umgebung arbeiten und unterschiedliche Ergebnisse bekommen...

Das Null Handle ist schon in Ordnung!!
Du bekommst es, weil du ja vollen Zugriff haben willst, der Zugriff aber eingeschränkt wurde.

Der Taskmanager macht auch nichts anderes als TerminateProcess. Um das zu verhindern muss man einfach :

Delphi-Quellcode:

SetProcessHandleRights(PROCESS_ALL_ACCESS xor PROCESS_TERMINATE);

schreiben. Schon kann man den Prozess nicht mehr beenden.

Das Problem bei der Sache ist jedoch, dass 90% der Windowsbenutzer als Administrator arbeiten. Administratoren haben das Debug-Privileg, welches IMMER volle Rechte für OpenProcess beschert - egal was die DACL sagt.
Selbst Leute, die nicht als Admin unterwegs sind, haben meist zum Programmieren das Debugprivileg eingeschaltet - die Gruppe DebuggerUsers oder andere. Für MSDevStudio 2003 war das noch zwingend.
Wenn selbst Admins ein Nullhandle bekommen, dann liegt es entweder daran, dass sie kein Debugprivileg haben oder das Privileg ist ausgeschalten. Privilegien haben die Attribute : vorhanden, eingeschaltet, eingeschaltet von Anfang an.

Debugprivilegien sind nicht notwendig, um mit Delphi oder anderen IDEs seine Programme zu debuggen. Sie sind eigentlich nur notwendig, um Prozesse anderer Benutzer zu debuggen, zB. Dienste.
Wer mehr über Debugprivilegien wissen will, der suche nach SE_DEBUG_NAME.