Entwickler-Ecke
Windows API - Delphi anfällig für DLL Hijacking-Lücke?
matze - Fr 27.08.10 20:31
Titel: Delphi anfällig für DLL Hijacking-Lücke?
Hallo.
Da im Moment ja grade die DLL Hijacking-Lücke sehr präsent ist, wollte ich einfach mal wissen: Ist Delphi dafür anfällt?
OK das ist jetzt ein bisschen blöd formuliert, da ja jeder Entwickler selber dafür verantwortlich ist.
Aber: Sind evtl in den VCL Sourcen oder anderen mitgelieferten PAS-Files solche verwundbaren LoadLibrary-Aufrufe drinnen?
Weiß da jemand Bescheid?
MfG
Matze
delfiphan - Fr 27.08.10 21:07
Ich glaube das ganze geht so, dass, wenn du ein Dokument (Word, Video, was auch immer) irgendwo öffnest (z.B. Doppelklick in Explorer), dann wird das Current Directory auf das Verzeichnis gesetzt, wo das Dokument ist und dann das Programm geöffnet, das dieses File öffnen kann. Wenn jetzt in diesem Verzeichnis auch noch eine DLL sitzt, die die Applikation braucht, dann wird diese möglicherweise geladen.
Bei den KnownDLLs (kernel32, etc.) sollte dies vermutlich kein Problem darstellen. Mir ist nicht bewusst, dass Delphi DLLs braucht, die nicht in KnownDLLs eingetragen sind. Wenn du aber eigene hast, musst du aufpassen, dass du einen hinreichend qualifizierten Pfad angibst. Ansonsten kannst du die DLLs auch signieren.
Du musst natürlich auch ein Programm haben, welches wie oben geschrieben indirekt geöffnet werden kann.
dummzeuch - Sa 28.08.10 10:50
 matze hat folgendes geschrieben  : |
Da im Moment ja grade die DLL Hijacking-Lücke sehr präsent ist, wollte ich einfach mal wissen: Ist Delphi dafür anfällt?
OK das ist jetzt ein bisschen blöd formuliert, da ja jeder Entwickler selber dafür verantwortlich ist.
Aber: Sind evtl in den VCL Sourcen oder anderen mitgelieferten PAS-Files solche verwundbaren LoadLibrary-Aufrufe drinnen?
Weiß da jemand Bescheid? |
Interessant zu dem Thema:
http://msdn.microsoft.com/en-us/library/ff919712(VS.85).aspx
Wenn ich das richtig in Erinnerung habe (ist schon ein paar Tage her), so ist prinzipiell jedes Programm betroffen, welches ein LoadLibrary ohne explizite Pfadangabe macht und sein aktuelles Verzeichnis nicht explizit setzt, so dass es durch den Anwender festgelegt werden kann (File Open / File Save Dialog oder einfach das aktuelle Verzeichnis des aufrufenden Prozesses, z.B. des Explorer-Fensters).
Dagegen hilft laut dieses Artikels der Aufruf von SetDllDirectory('') beim Programmstart. Da ich von dieser Funktion noch nie gehoert hatte, vermute ich mal, dass ich sie auch im RTL/VCL Code noch nicht gesehen habe (und ein Grep auf den Sourcecode gibt mir recht).
Das wuerde bedeuten, dass jeglicher Aufruf von LoadLibrary in der RTL/VCL unsicher ist und davon gibt es diverse:
C:\Program Files\CodeGear\RAD Studio\5.0\source\database\src\pas\dbx\driver\DBXDynalink.pas
816 FLibraryHandle := THandle(LoadLibrary(SDBX_ADAPTER_NAME));
C:\Program Files\CodeGear\RAD Studio\5.0\source\database\src\pas\dbx\driver\DBXDynalinkNative.pas
117 FLibraryHandle := THandle(LoadLibrary(SDBX_ADAPTER_NAME));
C:\Program Files\CodeGear\RAD Studio\5.0\source\Indy-renamed\Indy10\Protocols\IdGlobalProtocols.pas
927 lh:=LoadLibrary('ntdll.dll'); {do not localize}
C:\Program Files\CodeGear\RAD Studio\5.0\source\Indy-renamed\Indy10\Protocols\IdSSLOpenSSLHeaders.pas
4721 If hIdIndySSL = 0 Then hIdIndySSL := LoadLibrary(SSL_Indy_DLL_name) else exit;
4723 if hIdCrypto = 0 then hIdCrypto := LoadLibrary(SSLCLIB_DLL_name);
4724 If hIdSSL = 0 Then hIdSSL := LoadLibrary(SSL_DLL_name) else exit;
4725 // If hIdIndySSL = 0 Then hIdIndySSL := LoadLibrary(SSL_Indy_DLL_name);
C:\Program Files\CodeGear\RAD Studio\5.0\source\Indy-renamed\Indy10\Protocols\IdSSLOpenSSLHeadersNET.pas
5075 LIdCrypto := LoadLibrary(SSLCLIB_DLL_name);
5084 LIdSSL := LoadLibrary(SSL_DLL_name);
C:\Program Files\CodeGear\RAD Studio\5.0\source\Indy-renamed\Indy10\System\IdWinsock2.pas
4904 @TransmitFile := GetProcAddress(LoadLibrary('WSOCK32.dll'), 'TransmitFile'); {Do not Localize}
5087 hWS2Dll := LoadLibrary( WINSOCK2_DLL );
C:\Program Files\CodeGear\RAD Studio\5.0\source\Indy-renamed\Indy10\System\IdWship6.pas
272 hWship6Dll := LoadLibrary( Wship6_dll );
C:\Program Files\CodeGear\RAD Studio\5.0\source\Indy-renamed\Indy9\IdSSLOpenSSLHeaders.pas
4479 If hIdIndySSL = 0 Then hIdIndySSL := LoadLibrary(SSL_Indy_DLL_name) else exit;
4481 if hIdCrypto = 0 then hIdCrypto := LoadLibrary(SSLCLIB_DLL_name);
4482 If hIdSSL = 0 Then hIdSSL := LoadLibrary(SSL_DLL_name) else exit;
4483 // If hIdIndySSL = 0 Then hIdIndySSL := LoadLibrary(SSL_Indy_DLL_name);
C:\Program Files\CodeGear\RAD Studio\5.0\source\Indy-renamed\Indy9\IdWinSock2.pas
4241 hWS2Dll := LoadLibrary( WINSOCK2_DLL );
C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\IBX\IBIntf.pas
994 IBLibrary := LoadLibrary(PChar(IBASE_DLL));
1158 IBXMLLibrary := LoadLibrary(PChar(IBXML_DLL));
1227 IBInstallLibrary := LoadLibrary(PChar(IB_INSTALL_DLL));
C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\rtl\common\ComServ.pas
462 OleAutHandle := SafeLoadLibrary('OLEAUT32.DLL');
C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\rtl\win\Mapi.pas
439 MAPIModule := LoadLibrary(PChar(MAPIDLL));
C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\rtl\win\PsAPI.pas
215 hPSAPI := LoadLibrary('PSAPI.dll');
C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\Samples\Source\IBCtrls.pas
209 LibHandle := LoadLibrary('gds32.dll');
C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\vcl\AxCtrls.pas
4136 OlePro32Dll := SafeLoadLibrary('olepro32.dll');
C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\vcl\ComCtrls.pas
4225 ShellModule := SafeLoadLibrary(ShellDllName);
11864 FRichEditModule := LoadLibrary(RichEditModuleName);
C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\vcl\Controls.pas
12175 IMM32DLL := LoadLibrary(Imm32ModName);
C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\vcl\ExtActns.pas
1301 UrlMonHandle := LoadLibrary(UrlMonLib);
C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\vcl\GraphUtil.pas
647 MsImgHandle := LoadLibrary(msimg32);
C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\vcl\Menus.pas
3090 DLLHandle := SafeLoadLibrary(DLLName);
C:\Program Files\CodeGear\RAD Studio\5.0\source\Win32\xml\oxmldom.pas
1713 UrlMonHandle := LoadLibrary(UrlMonLib);
Das ist jetzt Delphi 2007, ich will nicht ausschliessen, dass auch neuere Delphi-Versionen betroffen sind.
Wer sicherstellen will, dass seine programme nicht betroffen sind, ruft einfach beim Programmstart als moeglichst erstes
auf. Beschreibung von
http://msdn.microsoft.com/en-us/library/ms686203(v=VS.85).aspx :
Parameter:
The directory to be added to the search path. If this parameter is an empty string (""), the call removes the current directory from the default DLL search order. If this parameter is NULL, the function restores the default search order.
Einziges Problem: Wie kann ich sicherstellen, dass dieser Aufruf ausgefuehrt wird, bevor einer der potentiell unsicheren LoadLibrary Aufrufe aus der RTL/VCL stattfindet.
Meiner Ansicht nach muesste der Aufruf dafuer in der INITIALIZATION Section einer Unit stehen, die als erste in der Uses-Liste der .DPR-Datei steht und die ihrerseits keine weitere Unit einbindet. Selbst dann wird natuerlich system.pas und der Memory-Manager vorher eingebunden. Man muesste also pruefen, ob da ein Problem besteht. Ausserdem ist SetDllDirectory nirgends deklariert, d.h. man muss erstmal herausfinden, in welcher Windows DLL sie steht (laut Beschreibung kernel32.dll) und diese Funktion dann selbst deklarieren:
function SetDllDirectoryA(lpPathName: PAnsiChar): LongBool;
bzw.
function SetDllDirectoryW(lpPathName: PWideChar): LongBool;
twm
delfiphan - Sa 28.08.10 11:26
Naja, es kommt ja immer noch auf die Anwendung darauf an. Wenn man die Anwendung sowieso nur durch Doppelklick auf das Exe starten kann, dann ist es nicht betroffen.
| dummzeuch hat folgendes geschrieben : |
| Dagegen hilft laut dieses Artikels der Aufruf von SetDllDirectory('') beim Programmstart. |
Da wär ich jetzt nicht so sicher. Wenn du DLLs direkt importierst (nicht zu einer späteren Zeit über LoadLibrary), dann werden die offenbar schon geladen, bevor du eine Zeile eigenen Code ausführen kannst, d.h. bevor irgend welche Units geladen sind. Wenn du in SysInit einen Breakpoint auf _InitExe setzt, dann sieht man im EventLog schon, dass bereits eine Menge DLLs geladen wurden.
elundril - Sa 28.08.10 11:30
| delfiphan hat folgendes geschrieben : |
| Naja, es kommt ja immer noch auf die Anwendung darauf an. Wenn man die Anwendung sowieso nur durch Doppelklick auf das Exe starten kann, dann ist es nicht betroffen. |
Das kann man nicht verhindern, das es auch anders geht. Ich brauch nur eine Verknüpfung erstellen und das Feld "Ausführen in" anders setzen und schon hab ich das falsche Verzeichnis wenn ichs ned prüfe.
lg elundril
jaenicke - Sa 28.08.10 11:32
| delfiphan hat folgendes geschrieben : |
| Du musst natürlich auch ein Programm haben, welches wie oben geschrieben indirekt geöffnet werden kann. |
Du kannst das Verzeichnis direkt z.B. bei ShellExecute angeben.
delfiphan - Sa 28.08.10 11:36
Ja, einverstanden. Aber dann hast du die Pfade selbst so gesetzt. Hättest ja auch gleich die DLL überschreiben können, sofern du darauf schreibzugriff hast. Solange ein Remoteangreifer den Pfad nicht setzen kann ist es für ihn relativ schwierig, diese Lücke auszunützen.
Die Sicherheitslücke wird meistens so ausgenützt, dass du eben ein .doc auf einem Share öffnest und auf diesem Share im gleichen Ordner eine DLL ist. Oder du im Browser ein Medienfile abspielst und blöderweise zuvor noch eine DLL in das gleiche Cacheverzeichnis runtergeladen wurde.
BenBE - Sa 28.08.10 13:29
Fix für das Problem dürfte sein:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
| Unit FixKnownAppIssues;
interface
implementation
function SetDllDirectoryW(lpPathName: ^WideChar): Integer; stdcall; external 'kernel32.dll' name 'SetDllDirectoryW';
initialization
SetDllDirectoryW('');
end. |
Wer sich grad wundert, warum ich nicht die Windows.pas für DWORD und Longbool einbinde: Weil ich sonst implizite Abhängigkeiten drinnen hätte und die Unit damit relativ spät in der Ladereihenfolge kommt.
Die Unit bitte im Projekt-File als erste Unit (noch vor ShareMem oder anderen Memory-Managern) einbinden.
Bzgl. Indy: der Aufruf der ntdll.dll dürfte sicher sein, weil KnownDLL. Anders sieht's bei der Anbindung von SSL aus.
Genauso msimg32.dll und urlmon.dll. Hab das aber grad nicht nachgeprüft. Auch der Punkt mit ShellDllName (shell32.dll) sollte sicher sein.
Dude566 - Sa 28.08.10 16:05
Also habe ich das richtig verstanden, wenn ich eine Anwendung öffne die sagen wir mal eine blabla.dll benötigt und laden will, dass Windows dann zunächst in der "Current Directory" danach sucht.
Jetzt könnte ein Angreifer eine dll mit dem selben Namen in dieses Verzeichnis gelegt haben und mein Programm würde diese statt der originalen laden.
Ist das so richtig? (Habe noch keine Ahnung von dll-Kram. :oops:)
jaenicke - Sa 28.08.10 17:31
Ja, das hast du schon richtig verstanden. Und weshalb das dann zu Angriffen von außen taugt, wurde ja auch bereits beschrieben.
trm - Fr 03.09.10 23:58
Benny,
eine Frage: unter Delphi 7 bekomme ich bei der Kompilierung meines Projects einen Fehler:
Delphi-Quelltext
1:
2:
3:
4:
5:
| function SetDllDirectoryW(lpPathName: ^WideChar): Integer; stdcall; external 'kernel32.dll' name 'SetDllDirectoryW';
[Fehler] FixKnownAppIssues.pas(7): Bezeichner erwartet, aber '^' gefunden
[Fehler] FixKnownAppIssues.pas(11): Inkompatible Typen: 'WideChar' und 'String'
[Fataler Fehler] Project1.dpr(6): Verwendete Unit 'FixKnownAppIssues.pas' kann nicht compiliert werden |
Unter welcher Delphi-Version hast Du das erstellt ?
Ich habe eine Lösung gefunden (
http://forum.delphi-treff.de/showthread.php?29354-L%FCcke-Unwissenheit-oder-Dummheit&p=212667#post212667 )
Martok - Sa 04.09.10 00:42
| trm hat folgendes geschrieben : |
| Unter welcher Delphi-Version hast Du das erstellt ? |
Vermutlich unter einem Virtuellen Delphi im Kopf.
Delphi will Argumente immer in echten Typen haben, nicht in ad-hoc-Typen. Also entweder selber deklarieren oder gleich PWideChar verwenden.
Flamefire - Sa 04.09.10 14:55
BTW: Könnte man das nicht besser mit:
Delphi-Quelltext
1:
2:
| SetDllDirectoryW('');
SetDllDirectory(ExtractFilePath(ParamStr(0))); |
lösen?
Dann hat man wirklich das Programmverzeichnis, aber nicht das Ausführen in verzeichnis drin.
Vorausgesetzt man kriegt das obige vor die LoadLibrary aufrufe.
IMHO wäre das DIE Lösung für einen Patch der kernel32.dll LoadLibrary Funktion, da es genau das macht, was man erwartet.
delfiphan - Sa 04.09.10 15:02
| Flamefire hat folgendes geschrieben : |
| IMHO wäre das DIE Lösung für einen Patch der kernel32.dll LoadLibrary Funktion, da es genau das macht, was man erwartet. |
Das wäre ein "contract-breaking" change. Das kann die Microsoft (zu mindest in einem Patch) nicht einfach so tun. Das würde dazu führen, dass u.U. gewisse Programme nicht mehr funktionieren, was wieder dazu führen würde, dass gewisse Leute nicht mehr updaten.
Solche DLL Mixups habe ich selbst auch schon erlebt, da muss man sehr vorsichtig sein.
Ich denke mal, dass das Problem schon seit vielen Jahren bekannt ist (daher gibt's auch obige Funktion schon länger). Wer auf sicher gehen will soll mit signierten DLLs arbeiten.
Flamefire - Sa 04.09.10 15:04
warum? Es ging doch darum, dass im Anwendungsverzeichnis nach der DLL gesucht wird. Haltes es eher für einen Fehler, dass stattdessen in einem anderen gesucht wird.
Oder wo wird gezielt das Ausführungsverzeichnis geändert, um woanders anch ner DLL zu suchen (oder das erwartet)
delfiphan - Sa 04.09.10 15:08
Es ist ein Fehler, aber den kann die Microsoft jetzt nicht einfach so beheben. Bei normalen Programmen kann man das sicher ändern; aber Microsoft kann keinen Patch rausgeben, das dazu führt, dass plötzlich etwas nicht mehr funktioniert. Dazu gehören auch schlecht gecodede Programme, die mit den DLLs vielleicht ein durcheinander haben und nur funktionieren, wenn LoadLibrary eben genau so funktioniert, wie sie eben funktioniert. Die Option "LoadLibrary anpassen" haben sich die Leute in Redmond sicher sehr gut überlegt.
Die Leute erwarten, dass Patches nichts "kaputt" machen. Wenn die MS zugibt, dass es ihr Fehler war und der Fix dazu führt, dass ein Programm nicht mehr funktioniert, haben sie sicher irgendwelche Klagen am Hals. Lieber dokumentieren sie, was die Funktion genau macht und stellen zusätzliche Funktionen bereit und überlassen es den Softwarefirmen, das Problem zu beheben.
kalmi01 - Sa 04.09.10 17:52
| delfiphan hat folgendes geschrieben : |
| Es ist ein Fehler, aber den kann die Microsoft jetzt nicht einfach so beheben. |
Warum ist es ein Fehler ?
Ich finde es super, wenn Programme in ihrem eigenen Verzeichnis nach DLL's suchen !
Dann kann man die auch selber mitliefern, wenn benötigt.
Ein Beispiel:
Anwendung A benötigt die QT-Library und kopiert sie, weil noch nicht vorhanden nach System32.
Anwendung B benötigt ebenfalls die QT-Library und kopiert sie, weil neuer, nach System32.
Anwendung C benötigt ebenfalls die QT-Library, kopiert sie aber nicht, weil eine neuere Version bereits im System32 existiert.
Da neuere Versionen nicht unbedingt abwärtskompatibel sein müssen, insbesondere dann, wenn die Software-Entwickler in eine Release noch eigene Features einkompiliert haben, würde jetzt ein heilloses Deasaster entstehen.
Dank des so gescholtenen Fehlers, kann man aber die benötigten DLL's einfach in das Verzeichnis des Programmes kopieren, welches mit den aktuellsten Lib's nicht arbeiten will.
Oder jeder Applikation ihre eigenen DLL's spendieren.
Am Besten wäre es aber, wenn Windows endlich Hardlinks transparent und dokumentiert unterstützen würde.
Dann könnte jede Anwendung im eigenen Verzeichnis alle DLL's beherbergen, inkl. Derer von MS (weil hardlinked).
Bei der Deinstallation wäre klar, ob noch jemand die DLL verwendet und die letzte deinstallation könnte korrekt aufräumen.
Leider wird mit jeder Installation und nachfolgender Deinstallation aber das System nicht wieder in dem Zustand zurück gelassen, wie es vor der Installation aussah.
Jeder hat Angst etwas zu löschen, was Andere noch benötigen (könnten).
delfiphan - Sa 04.09.10 18:15
Es ist ein Fehler, weil jetzt jedes Programm praktisch SetDllDirectory mit zu mindest leerem String als Argument übergeben soll. Diese neue Reihenfolge müsste bei LoadLibrary schon standard sein.
trm - Sa 04.09.10 21:41
Hallo,
ich habe jetzt nun schon einige Dinge bezüglich dieser "Schwachstelle" gelesen. Dabei ist mir einiges noch sehr unklar.
Warum ist das derart Problematisch, dass DLL-Dateien aus dem gleichen Verzeichnis geladen werden können?
Wer kopiert denn diese ominösen Dateien in das Programmverzsichnis - ein Virus oder ein Trojaner?
Wenn dem so ist, ist das dennoch kein Versagen von Microsoft, sondern vom Benutzer des Computers zu diesem Zeitpunkt.
Wenn die verseuchten DLL-Dateien nun nicht im Programmverzeichnis liegen, der Benutzer des PC aber ein Programm startet, welches die DLL-Datei im Systemverzeichnis überschreibt/ablegt, dann ist das doch noch gravierender, weil diese Quelle u.U. mehr Programme nutzen als die eine lokale, welche ja auch erst genutzt wird, wenn die im Systemverzeichnis nicht gefunden wird.
Tut mir leid, aber dieser "Bug" ist meiner Meinung nach nur ein weiteres Kursoium, welches von den Medien aufgegriffen wird, um propagandamäßig gegen eine Firma vorzugehen (Stichwort: Sommerloch).
Vielleicht verstehe ich es auch einfach nicht. Dann entschuldigt bitte meinen Beitrag.
BenBE - Sa 04.09.10 22:04
| trm hat folgendes geschrieben : |
Hallo,
ich habe jetzt nun schon einige Dinge bezüglich dieser "Schwachstelle" gelesen. Dabei ist mir einiges noch sehr unklar. |
Zwischen Lesen und Lesen gibt es gewaltige Unterschiede ... :mrgreen:
| trm hat folgendes geschrieben : |
| Warum ist das derart Problematisch, dass DLL-Dateien aus dem gleichen Verzeichnis geladen werden können? |
Arbeitsverzeichnis != Programmverzeichnis. Wobei "gleiches Verzeichnis" ja mal absolut undefiniert ist ... Sorry. Verstehen: Sechs, setzen. Wurde nämlich hier im Thread
lang, breit und hochkant erklärt.
| trm hat folgendes geschrieben : |
Wer kopiert denn diese ominösen Dateien in das Programmverzsichnis - ein Virus oder ein Trojaner?
Wenn dem so ist, ist das dennoch kein Versagen von Microsoft, sondern vom Benutzer des Computers zu diesem Zeitpunkt. |
Der Fehler bedarf keines Schreibzugriffs. Bitte Thread noch mal lesen, da steht alles drinnen erklärt.
| trm hat folgendes geschrieben : |
| Wenn die verseuchten DLL-Dateien nun nicht im Programmverzeichnis liegen, der Benutzer des PC aber ein Programm startet, welches die DLL-Datei im Systemverzeichnis überschreibt/ablegt, dann ist das doch noch gravierender, weil diese Quelle u.U. mehr Programme nutzen als die eine lokale, welche ja auch erst genutzt wird, wenn die im Systemverzeichnis nicht gefunden wird. |
Am System muss für dieses Problem absolut nichts verändert werden.
| trm hat folgendes geschrieben : |
| Tut mir leid, aber dieser "Bug" ist meiner Meinung nach nur ein weiteres Kursoium, welches von den Medien aufgegriffen wird, um propagandamäßig gegen eine Firma vorzugehen (Stichwort: Sommerloch). |
Mal ganz davon abgesehen, dass Du scheinbar eine andere Sprache sprichst (also zumindest
Deutsch ist das nicht [
http://de.wiktionary.org/wiki/Kursoium] ;-)), attestiere ich Dir hiermit einmal kein bis gar kein Grundlagen-Verständnis für Security-Fragen und Exploitability. Jedes Howto become a Hacker hat mehr Tiefgang...
Das Problem bei der Lücke ist einfach mal: Ich erzeuge einen undefinierten Zustand und definiere das als Standard. Juhu, genau was man in einem Verlässlichen System haben will! :twisted:
| trm hat folgendes geschrieben : |
| Vielleicht verstehe ich es auch einfach nicht. Dann entschuldigt bitte meinen Beitrag. |
Das tippe ich auch. Aber entschuldigen tue ich solch flache Postings nicht: Da könnt ja jeder kommen. Hier gilt immer noch der Grundsatz "Erst denken, dann posten." ;-)
kalmi01 - Fr 10.09.10 17:55
| BenBE hat folgendes geschrieben : |
Zwischen Lesen und Lesen gibt es gewaltige Unterschiede ... :mrgreen:
..
Verstehen: Sechs, setzen. Wurde nämlich hier im Thread lang, breit und hochkant erklärt.
..
Mal ganz davon abgesehen, dass Du scheinbar eine andere Sprache sprichst (also zumindest Deutsch ist das nicht [http://de.wiktionary.org/wiki/Kursoium] ;-)), attestiere ich Dir hiermit einmal kein bis gar kein Grundlagen-Verständnis für Security-Fragen und Exploitability. Jedes Howto become a Hacker hat mehr Tiefgang...
..
Das Problem bei der Lücke ist einfach mal: Ich erzeuge einen undefinierten Zustand und definiere das als Standard. Juhu, genau was man in einem Verlässlichen System haben will! :twisted:
| trm hat folgendes geschrieben : | | Vielleicht verstehe ich es auch einfach nicht. Dann entschuldigt bitte meinen Beitrag. |
Das tippe ich auch. Aber entschuldigen tue ich solch flache Postings nicht: Da könnt ja jeder kommen. Hier gilt immer noch der Grundsatz "Erst denken, dann posten." ;-) |
Hallo BenBe, letzteren Satz solltest DU dir mal zu Herzen nehmen.
Was soll eine derart arrogante Antwort ?
Deine Reaktion ist massiv übertrieben !
elundril - Fr 10.09.10 22:30
| kalmi01 hat folgendes geschrieben : |
Hallo BenBe, letzteren Satz solltest DU dir mal zu Herzen nehmen.
Was soll eine derart arrogante Antwort ?
Deine Reaktion ist massiv übertrieben ! |
Ich zitiere mal die Bergpredigt:
"Selig sind jene die die Ironie, Sarkasmus und schwarzen Humor kennen; denn ihnen gehört das Forenreich." ;)
An das Team: Kann man bitte Ironie-Tags einführen?
lg elundril
kalmi01 - Sa 11.09.10 17:35
| elundril hat folgendes geschrieben : |
"Selig sind jene die die Ironie, Sarkasmus und schwarzen Humor kennen; denn ihnen gehört das Forenreich." ;)
|
Ironie und Sarkasmus sind bei mir hervorragend ausgebildet.
Und mein schwarzer Humor ist so schwarz, dass schwarze Löcher dagegen hell wie Sterne leuchten.
Aber den Unterschied zwischen beleidigendem Verhalten und Sarkasmus erkenne ich schon noch !
"Sorry. Verstehen: Sechs, setzen" ist einfach nur arrogant.
"Mal ganz davon abgesehen, dass Du scheinbar eine andere Sprache sprichst" ist auch nicht wirklich höflich.
"Aber entschuldigen tue ich solch flache Postings nicht" hallo, wess geistes Kind ist das denn ?
Der Author hat eine sehr berechtigte Frage gestellt !
Ich arbeite seit TP 3.0 mit Borland-Produkten, bin also sicher kein Neuling.
Aber egal wie doof die Frage auch ist, SO springt man mit niemandem um.
Und wenn einen der User nervt, einfach mal die Schnauze halten.
Aber nicht so !
trm - Sa 11.09.10 18:38
kalmi91, Danke, dass Du für mein Posting Partei ergreifst (so interpretiere ich das mal).
Lass gut sein, entweder hatte BenBe einen nicht ganz so glücklichen Tag, als er meinen Beitrag las - oder aber, ich habe ja tatsächlich nicht das gelesen, was in diesem Thread wichtig ist.
Dennoch sollte das hier nicht aus den Fugen geraten.
>>Wer kopiert denn diese ominösen Dateien in das Programmverzsichnis - ein Virus oder ein Trojaner?
>>Wenn dem so ist, ist das dennoch kein Versagen von Microsoft, sondern vom Benutzer des Computers zu diesem Zeitpunkt.
>Der Fehler bedarf keines Schreibzugriffs. Bitte Thread noch mal lesen, da steht alles drinnen erklärt.
Wenn der "Fehler" keinen Schreibzugriff benötigt, WER packt eine dll-Datei in das Verzeichnis, in dem die Anwendung liegt.
(Wenn das nicht der Fall ist..):
WER ändert das Arbeitsverzeichnis einer (Verknüpfung?) Anwendung, damit eine komprimittierte dll-Datei benutzt werden (kann?) soll?
>>Tut mir leid, aber dieser "Bug" ist meiner Meinung nach nur ein weiteres Kursoium, welches von den Medien aufgegriffen wird, um propagandamäßig gegen eine Firma
>> vorzugehen (Stichwort: Sommerloch).
>Das Problem bei der Lücke ist einfach mal: Ich erzeuge einen undefinierten Zustand und definiere das als Standard. Juhu, genau was man in einem Verlässlichen System
> haben will! :twisted:
Wenn es einen Standard gibt, dass dll-Dateien im Programmpfad (evtl. im Suchpfad?) benutzt werden, ist das doch kein undefininierter Zustand, sondern ein gewollt definierter. Wie jemand schonmal hier im Thread bemerkte: Ich bin froh, dass ich meine DLL mit in den gleichen Pfad packen kann.
Von daher sehe ICH (ICH = ich persönlich) keinerlei handlungsbedarf seitens Micosoft. Es obliegt dem Benutzer des Computers, wie er mit seinen Verzeichnissen und seinen (per email/per icq/per internet gefundenen/[..]) Programmen umgeht, welche Programme er für wichtig erachtet, welche Programme er installiert oder auch nur ausführt..
Ein Beispiel aus der Hardeware-Welt wäre in etwa:
Die Autohersteller dürfen ab sofort keine 3 Pedale / 2 Pedale /x Pedale mehr im Fußraum anbringen
.., weil der Benutzer vom Auto nicht weiß, mit welchem Fuß das Pedal getreten werden muss.
ODER aber [..], weil der Benutzer vom Auto (eventuell) nicht weiß, welches Pedal das richtige ist.
ODER aber [..], weil der Benutzer vom Auto (eventuell) weiß, welches Pedal das richtige ist, aber dennoch das falsche tritt.
ODER aber [..], weil der Benutzer vom Auto (eventuell) weiß, welches Pedal das richtige ist, dieses tritt, aber in einer falschen Situation.
(das könnte ICH noch weiter fortführen)
Das Beispiel mit dem Auto oben kann ICH auch für andere, banalere Dinge umsetzen. Wer will, der ermutigt mich dazu.
Die letzte Frage, welche ich das letzte mal vergessen habe:
Sollte man diesen Delphi-Fix in JEDEM Programm einbauen, also auch (theoretisch) für ein "Hallo Welt" - Programm, welches in VCL erstellt wird?
Dennoch, auch wenn es stark an Sarkasmus erinnert: meine Fragen oben hätte ich gern beantwortet. Wenn sich jemand in der Lage fühlt, dann wäre ich ihm/ihr sehr verbunden.
Viele liebe Grüße
~Mathias
elundril - Sa 11.09.10 18:50
| kalmi01 hat folgendes geschrieben : |
Aber egal wie doof die Frage auch ist, SO springt man mit niemandem um.
Und wenn einen der User nervt, einfach mal die Schnauze halten.
Aber nicht so ! |
Mit dem zweiten Satz hast du den ersten gerade ad absurdum geführt, ich hoffe das ist die klar.
lg elundril
Martok - Sa 11.09.10 19:03
Könnten wir mal alle etwas runter kommen? :roll:
Das Thema ist doch wohl eigentlich zu interessant, um sich hier um Verhaltensweisen zu schlagen.
trm - Sa 11.09.10 20:38
Ich bins nochmal.
Kann mir jemand, der Windows 7 im Einsatz hat bitte einen Gefallen tun.
Ist dieser Registry-Schlüssel auf allen Installationen gleich vom Namen her ?
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{DBDBB6B7-80D1-415E-96D5-D267FEBE0E80}Machine
Hintergrund ist ein Beitrag, den ich im Heise-Forum gelesen habe:
http://www.heise.de/security/news/foren/S-Wie-man-in-Windows-7-Ultimate-oder-Enterprise-diese-Luecke-dicht-bekommt/forum-185681/msg-19124859/read/MD5-88e2e15e4b9ed8ce6c3dad7cfb0b2036/
Wenn ja, würde ich mir die Einstellungen exportieren und gegebenfalls zu einen späteren Zeitpunkt (wenn sich von Microsoft bis dahin nichts getan hat, was ICH[sic] immer noch nicht unbedingt für nötig erachte) wieder einbinden, ohne alles per Hand noch einmal umstellen zu müssen.
Nebenbei, wer den Dienst starten will über eine batch-Datei (Adminrechte werden benötigt): sc config AppIDSvc start= auto
Das #32 nach = ist Pflicht.
Andere Werte sind: <boot|system|auto|demand|disabled|delayed-auto> (siehe "sc config /?") - delayed-auto gibt es, glaube ich, erst seit Windows Vista.
trm - Sa 11.09.10 20:47
| Martok hat folgendes geschrieben : |
Könnten wir mal alle etwas runter kommen? :roll:
Das Thema ist doch wohl eigentlich zu interessant, um sich hier um Verhaltensweisen zu schlagen. |
Recht hast Du, dennoch, da es imliziert auch mich betrifft..
| elundril hat folgendes geschrieben : |
| kalmi01 hat folgendes geschrieben : | Aber egal wie doof die Frage auch ist, SO springt man mit niemandem um.
Und wenn einen der User nervt, einfach mal die Schnauze halten.
Aber nicht so ! |
Mit dem zweiten Satz hast du den ersten gerade ad absurdum geführt, ich hoffe das ist die klar.
lg elundril |
Nein, hat er/sie nicht, da er/sie das Bewertungsfrei geschrieben hat, ohne explizit einen Bezug zu meinem Beitrag herzustellen. kalmi01 hat seine Formulierung eher in Bezug auf einige Umgangsformen bezogen, wie sie in einigen Foren (Threads?) des öfteren zu lesen sind (Heise ist ein gutes Beispiel, im eher negativen Sinn).
(Nebenbei könnte dies ein gutes Beispiel (elundril's Assoziation) für den Boolean-Thread
http://www.delphi-forum.de/viewtopic.php?t=101484 sein ;) )
Nochmals viele Grüße
~Mathias
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!