AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Win32/Win64 API (native code) Delphi Hinweis: Wenig bekanntes Sicherheitsproblem mit Services durch Delphi SvcMgr
Thema durchsuchen
Ansicht
Themen-Optionen

Hinweis: Wenig bekanntes Sicherheitsproblem mit Services durch Delphi SvcMgr

Ein Thema von CodeX · begonnen am 27. Aug 2014 · letzter Beitrag vom 28. Aug 2014
Antwort Antwort
Seite 1 von 2  1 2      
CodeX

Registriert seit: 30. Okt 2004
475 Beiträge
 
Delphi 12 Athens
 
#1

Hinweis: Wenig bekanntes Sicherheitsproblem mit Services durch Delphi SvcMgr

  Alt 27. Aug 2014, 13:08
Ich war gerade ganz schön erstaunt, als ich festgestellt habe, dass bei der Installation eines mit Delphi erstellten Services der Pfad zur Datei keine Anführungszeichen enthält:
Code:
C:\program files (x86)\meineanwendung\meinservice.exe
Das führt dazu, dass wenn man eine Datei C:\program.exe erstellt, diese statt des Services mit entsprechenden Rechten ausgeführt wird! Ganz nebenbei funktioniert dann der eigene Service natürlich auch nicht mehr.

Auf der Suche danach, ob das Problem bekannt ist, bin ich lediglich auf diese beiden Einträge gestoßen:
http://qc.embarcadero.com/wc/qcmain.aspx?d=5728
http://qc.embarcadero.com/wc/qcmain.aspx?d=90093
Allerdings scheint sich danach nichts gerührt zu haben. Ich kann natürlich nur für Delphi bis XE sprechen, aber es kann gerne jemand mal in den neueren Versionen nachschauen.

Grundsätzlich liegt das Problem darin, dass SvcMgr.pas: TServiceApplication.RegisterServices intern CreateService(...) lediglich mit Path := ParamStr(0) aufruft, ohne das Ganze mit Anführungszeichen zu umschließen. Selber patchen wäre hier natürlich kein Problem, aber ich rate davon ab, denn nachher vergisst man den Patch wieder und das Problem kommt mit der nächsten Delphi-Installation wieder.

Stattdessen wäre folgender Workaround eine Lösung, indem der Service seinen Pfad direkt nach der Installation selbst korrigiert:
Delphi-Quellcode:
procedure TMyService.ServiceAfterInstall(Sender: TService);
var
  reg: TRegistry;
begin
  reg := TRegistry.Create(KEY_READ or KEY_WRITE);
  try
    reg.RootKey := HKEY_LOCAL_MACHINE;
    if reg.OpenKey('\SYSTEM\CurrentControlSet\Services\' + Name, false) then
    begin
      // Vulnerability-Fix: In case the path contains spaces a file like c:\program.exe might be launched with system privileges
      reg.WriteString('ImagePath', '"' + GetModuleName(HInstance) + '"');

      // Description for the service is optional but highly recommended
      reg.WriteString('Description', 'Kurze Beschreibung');
  
      reg.CloseKey;
    end;
  finally
    reg.Free;
  end;
end;
Ich empfehle dringend jedem, der einen Service mit Delphis SvcMgr erstellt hat, diesen Fix einzubauen!
Nur Delphi schafft es, einem ein Lächeln zu schenken, wenn man sich beim Schreiben von := vertippt und stattdessen ein :) erscheint.
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.202 Beiträge
 
Delphi 10.4 Sydney
 
#2

AW: Hinweis: Wenig bekanntes Sicherheitsproblem mit Services durch Delphi SvcMgr

  Alt 27. Aug 2014, 14:45
Auch wenn ich es für sinnvoll erachte das zu fixen.
Das sicherheotsproblem ist wohl eher theoretischer Natur. Denn wenn man eine böse Exe im Rootverzeichnis liegt hat, hat man wohl ganz andere Probleme
Windows Vista - Eine neue Erfahrung in Fehlern.

Geändert von Bernhard Geyer (27. Aug 2014 um 14:53 Uhr)
  Mit Zitat antworten Zitat
CodeX

Registriert seit: 30. Okt 2004
475 Beiträge
 
Delphi 12 Athens
 
#3

AW: Hinweis: Wenig bekanntes Sicherheitsproblem mit Services durch Delphi SvcMgr

  Alt 27. Aug 2014, 14:55
Der Einwand ist nur bedingt richtig: Ja, wenn eine beliebige Anwendung auf C: direkt schreiben kann, ist das ein ganz anderes Problem. Allerdings ist der Fall gar nicht so unwahrscheinlich: Bis XP war das Gang und Gäbe. Und ab Vista (7, 8, ...) tritt der Fall ein, wenn man UAC deaktiviert. Das klingt dumm, machen aber tatsächlich viele Leute, weil sie von den Warnmeldungen genervt sind.

Und unabhängig davon: Es ist durchaus gängig ein (zusätzliches) Programmverzeichnis auf einer anderen Partition zu pflegen. Für Software, die unbedingt in ihr Verzeichnis schreiben muss und für sehr große Anwendungen, die auf C: (z.B. kleine SSD für Betriebssystem) keinen Platz finden. Da gibt es dann keine standardmäßigen Zugriffsrechte-Maßnahmen.

So theoretisch ist das Problem nicht. Aber selbst wenn das Problem nur <5% der Anwender betrifft, so ist es dennoch ein Sicherheitsproblem und es gibt keinen Grund, das Problem nicht zu beheben.
Nur Delphi schafft es, einem ein Lächeln zu schenken, wenn man sich beim Schreiben von := vertippt und stattdessen ein :) erscheint.
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#4

AW: Hinweis: Wenig bekanntes Sicherheitsproblem mit Services durch Delphi SvcMgr

  Alt 27. Aug 2014, 15:12
Das ist kein Sicherheitsproblem imho, sondern einfach ein Bug, wegen
Zitat:
Ganz nebenbei funktioniert dann der eigene Service natürlich auch nicht mehr.
Egal, ob man in 'C:\' nun ein Programm.exe hat, oder nicht.
  Mit Zitat antworten Zitat
CodeX

Registriert seit: 30. Okt 2004
475 Beiträge
 
Delphi 12 Athens
 
#5

AW: Hinweis: Wenig bekanntes Sicherheitsproblem mit Services durch Delphi SvcMgr

  Alt 27. Aug 2014, 15:18
Das ist kein Sicherheitsproblem imho, sondern einfach ein Bug
Ja, ein Bug, der u.a. zu einem Sicherheitsproblem führt.
Nur Delphi schafft es, einem ein Lächeln zu schenken, wenn man sich beim Schreiben von := vertippt und stattdessen ein :) erscheint.
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#6

AW: Hinweis: Wenig bekanntes Sicherheitsproblem mit Services durch Delphi SvcMgr

  Alt 27. Aug 2014, 15:20
Genau. Ich wollte nur den Theoretikern den Wind aus den Segeln nehmen
  Mit Zitat antworten Zitat
pertzschc

Registriert seit: 29. Jul 2005
Ort: Leipzig
309 Beiträge
 
Delphi 12 Athens
 
#7

AW: Hinweis: Wenig bekanntes Sicherheitsproblem mit Services durch Delphi SvcMgr

  Alt 27. Aug 2014, 16:47
Ich war gerade ganz schön erstaunt, als ich festgestellt habe, dass bei der Installation eines mit Delphi erstellten Services der Pfad zur Datei keine Anführungszeichen enthält
Danke dafür - habe bei mir in einigen Programmen fixen müssen!
Christoph
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#8

AW: Hinweis: Wenig bekanntes Sicherheitsproblem mit Services durch Delphi SvcMgr

  Alt 27. Aug 2014, 19:11
Allerdings ist der Fall gar nicht so unwahrscheinlich: Bis XP war das Gang und Gäbe. Und ab Vista (7, 8, ...) tritt der Fall ein, wenn man UAC deaktiviert. Das klingt dumm, machen aber tatsächlich viele Leute, weil sie von den Warnmeldungen genervt sind.
Beliebter Auto Vergleich: Bei XP war der Airbag standardmäßig deaktiviert. Nicht schön, aber man konnte ihn aktivieren. Und wer auf Vista, Windows 7, 8 den Airbag selbst abschaltet...Nun da kann man ja dem Autohersteller nicht anlasten, dass er ein unsicheres Auto ausliefern würde, wenn der Benutzer keinen Gurt anlegt, weil inn das An- und Abschnallen nervt.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
CodeX

Registriert seit: 30. Okt 2004
475 Beiträge
 
Delphi 12 Athens
 
#9

AW: Hinweis: Wenig bekanntes Sicherheitsproblem mit Services durch Delphi SvcMgr

  Alt 27. Aug 2014, 19:16
Allerdings ist der Fall gar nicht so unwahrscheinlich: Bis XP war das Gang und Gäbe. Und ab Vista (7, 8, ...) tritt der Fall ein, wenn man UAC deaktiviert. Das klingt dumm, machen aber tatsächlich viele Leute, weil sie von den Warnmeldungen genervt sind.
Beliebter Auto Vergleich: Bei XP war der Airbag standardmäßig deaktiviert. Nicht schön, aber man konnte ihn aktivieren. Und wer auf Vista, Windows 7, 8 den Airbag selbst abschaltet...Nun da kann man ja dem Autohersteller nicht anlasten, dass er ein unsicheres Auto ausliefern würde, wenn der Benutzer keinen Gurt anlegt, weil inn das An- und Abschnallen nervt.
Und was willst Du mir/uns damit sagen?
Nur Delphi schafft es, einem ein Lächeln zu schenken, wenn man sich beim Schreiben von := vertippt und stattdessen ein :) erscheint.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.184 Beiträge
 
Delphi 12 Athens
 
#10

AW: Hinweis: Wenig bekanntes Sicherheitsproblem mit Services durch Delphi SvcMgr

  Alt 27. Aug 2014, 22:16
Wer ordentlich als "Benutzer" arbeitet, der kann den Airbag/Gurt gern abschalten.
Bei "schlimmen" wird dann einfach immer nee gesagt und man ist sicher, da man das eben nicht darf.
> Bei der Fahrt gegen die Wand, wird automatisch vorher angehalten. Aber das dahinter wird dabei auch nicht erreicht.

Wer als Admin unterwegs ist, der ist selber Schuld, wenn er den Airbag/Gurt weg lässt.
Bei der Fahrt gegen die Wand, knallt es eben (der Virus darf ja das Gaspedal durchtreten).

Mit UAC darf man alles, aber wird eben vorher gefragt "Willst du wirkich durch die Wand?" (und dann macht das UAC die Wand weg und der Virus darf das auch, aber erst wenn man es ihm erlaubt)

Man kann sich also genau aussuchen, was man haben möchte.
- immer sicher, da nie etwas erlaubt ist
- fast immer sicher, da man vorher gefrag wird
- unsicher, aber dafür nervt keiner

Und grade wegen letzterem wurde das UAC erfunden, als kleiner Assistent, da die Leute einfach nicht kappiert haben, wie das mit den Rechten funktioniert.
$2B or not $2B
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:53 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz