Classic Shell heißt jetzt Open-Shell-Menü

[English]Neue Information für Nutzer bzw. Interessenten der eingestellten Classic Shell: Das Folgeprojekt wurde schon wieder umbenannt und heißt jetzt Open-Shell-Menü. Hier ein paar Informationen und ein Hinweis, warum man eher 'Obacht' sagen muss (obwohl die Entwickler offenbar nachgebessert haben).


Anzeige

Es gibt Software, die hält sich durch Umbenennungen im Aufmerksamkeitsfokus. Die Fortsetzung des Classic Shell-Projekts würde ich zu dieser Kategorie zählen, denn dieses Projekt hat sich wieder umbenannt.

Zum Hintergrund

Der Entwickler der Classic Shell, Ivo Beltchev, hat die Entwicklung der Software vor einiger Zeit eingestellt. Aber er übergab den Quellcode an die Community zur weiteren Pflege. Ich hatte im Blog-Beitrag Windows: Aus für Startmenü-Ersatz Classic Shell? thematisiert. Das ist schon mal gut.

Ständige Namenswechsel

Was aber für meinen Geschmack eher nicht so schön ist: Momentan glänzt das Projekt eher durch Umbenennungen. Kurze Zeit rangierte das Tool unter dem Namen Classic Start. Ich hatte dies im Blog-Beitrag Windows: Info-Splitter, Name für Redstone 5, Classic Shell etc. erwähnt. Gut, eine Umbenennung wäre ok.

Dann kam die Community auf die Idee, das Projekt in NeoClassic-UI/Menu umzutaufen (siehe den Beitrag Classic Start ist jetzt NeoClassic-UI/Menu). Außer dem neuen Namen gab es Ende Juli 2017 nichts neues zu vermelden – also 'gehen Sie weiter, es gibt hier nichts zu sehen'.

Nun heißt es Open-Shell-Menü

Bei den Kollegen von deskmodder.de lese ich, dass die Entwickler doch wirklich noch einen neuen Namen gefunden haben. Der Startmenü-Ersatz firmiert jetzt unter dem Namen Open-Shell-Menü. Die aktuelle Installationsdatei heißt nun OpenShellSetup_4_4_126.exe. Geändert hat sich wohl nichts an der Funktionalität. Das Projekt ist auf GitHub erreichbar, die Links sind aber noch nicht alle funktional. Die aktuelle Nightly Build ist hier abrufbar, wobei diese nach 6 Monaten ablaufen.

Die größte Baustelle: Sicherheit!

Jetzt könnte man den umgefallenen Sack Reis in China wieder aufheben und weiter gehen. Ich weise aber an dieser Stelle darauf hin, dass man von diesem Tool erst einmal Abstand halten sollte (unabhängig von dem, was die Community sich morgen einfallen lässt. Warum diese deutliche Warnung?

Beachtet den Kommentar von Stefan Kanthak, der nicht von der Hand zu weisen ist. Aus Gründen der Komfortabilität glauben die Entwickler einen .exe-Installer (statt einer .msi-Datei) ausliefern zu müssen. Dieser Installer muss mit administrativen Berechtigungen ausgeführt werden, um die Software zu installieren. Dabei entpackt der Installer die benötigten Dateien in ein (ungeschütztes) TEMP-Verzeichnis. Problem: Liegt eine Schadsoftware auf dem System vor, die momentan nur mit den Rechten eines eingeschränkten Benutzerkontos läuft, schlägt die Falle möglicherweise zu.

Diese Malware kann den Vorgang des Entpackens mitbekommen (es gibt Windows-APIs, die das melden und eine 'Hook-Funktion' der Malware aufrufen können). Dann reicht es, eine  DLL-Datei  mit einem bestimmten Namen in den TEMP-Ordner zu kopieren (da dieser ungeschützt ist, geht dies mit begrenzten Nutzerrechten). Der Installer versucht während des Installationsvorgangs die vermeintliche Windows-DLL zu laden, greift aber – auf Grund von Windows-Eigenarten – auf die von der Schadsoftware platzierte DLL zu. Und prompt erhält die Malware über die DLL administrative Berechtigungen.

Das Ganze segelt unter dem Begriff DLL search order hijacking, ist lange bekannt, als potentielles Sicherheitsrisiko verpönt und sollte unbedingt vermieden werden. Stefan Kanthak hat einige Links und weitere Details im Kommentar dazu gepostet. Das Projekt würde imho gut daran tun, sich weniger umzubenennen, sondern an den von Kanthak benannten Baustellen zu arbeiten.


Anzeige

Weitere Erkenntnisse

Ergänzung: An dieser Stelle muss ich temporär etwas zurückrudern. Ich habe mir jetzt mal den Installer (unter Windows 7, allerdings nur den Startmenü-Teil) zu Gemüte geführt. Interessante Feststellung: Martin Feuerstein hatte ja im Kommentar darauf hingewiesen, dass die .exe einen Schalter zum Extrahieren der .msi-Installer aufweist – lässt sich mit /? anzeigen. Man kann also die Geschichte entpacken und die passende 32-/64-Bit-Variante per .msi installieren. Werden die .msi-Dateien zur Installation benutzt, gibt es die obige Schwachstelle nicht.

Scheinbar läuft der .exe Installer-Wrapper während des Entpackens auch nur mit Standardrechten, entpackt die .msi-Dateien und ruft die passende Variante auf. Diese aktiviert dann per Manifest die UAC-Abfrage und installiert das Tool. Damit wäre ein Angriffsvektor wie oben beschrieben nach meinem bisherigen Wissen – wenn ich nichts übersehen habe – ausgehebelt (ob die richtige msi die UAC aufruft, lässt sich ja im UAC-Dialogfeld kontrollieren). Auch scheint in der .exe-Datei keine Abhängigkeit auf bestimmte Windows-Ressourcen zu existieren. Denn die von mir benutzte Test DLL-Datei wurde nicht getriggert. Die geäußerten Bedenken scheinen also in dieser Version nicht (mehr) zu gelten.

Nachtrag: Stefan Kanthak hat in den Kommentaren weiter unter ja darauf hingewiesen, dass die Dateien nicht digital signiert sind (das ist vermutlich den Nightly Builds geschuldet). Er hat mir folgendes mitgeteilt: Ruft man den Installer ClassicStartSetup_4_4_109.exe mit folgendem Link-Befehl auft:

LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_109.exe

werden die nachfolgenden Abhängigkeiten angezeigt.

COMCTL32.dll, VERSION.dll, KERNEL32.dll, USER32.dll, ADVAPI32.dll, SHELL32.dll

Diese DLLs hängen aber wieder von GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll und SHLWAPI.dll ab. Da VERSION.dll seit Windows Vista keine "known DLL" ist, wird jede Datei gleichen Namens aus dem Verzeichnis der jeweiligen Anwendung geladen. Das Gleiche gilt für SECUR32.dll und RPCRT4.dll.

Anmerkung: In den Screeshots und dem obigen Beispiel wird noch die ältere ClassicStartSetup_4_4_109.exe verwendet. Ich habe den Test auch mit der  OpenShellSetup_4_4_126.exe (ist die momentan aktuell Nightly Build) durchgeführt – gleiches Ergebnis. Auch digitale Signaturen fehlen. Daher habe ich den Screenshot und den Befehl in obigem Beispiel nicht mehr angepasst.

Stefan Kanthak hat mir einige seiner Test-DLLs überlassen. Man kann sich z.B. die Datei Forware.cab herunterladen, und dann unter Windows in einen Testordner (ich habe einen Unterordner von Downloads verwendet) entpacken. Anschließend kopiert man das zu testende Programm in den gleichen Ordner und führt es danach aus. Ich habe gleich mal die ClassicStartSetup_4_4_109.exe sowie die aktuelle OpenShellSetup_4_4_126.exe in dieser Testumgebung ausgeführt. Dazu habe ich die Programme aus dem Fenster der Eingabeaufforderung gestartet, um auch Optionen angeben zu können. Hier das Ergebnis (die Ausgabe ist für beide Programmversionen, bis auf die Programmnamen, identisch):

Warnung beim Aufruf
(Zum Vergrößern klicken)

Bereits beim Versuch des Aufrufs des Hilfedialogs mit den Aufrufoptionen gibt es eine Warnung, dass die Datei hätte manipuliert werden können. Ich habe im Anschluss die .msi-Installer extrahieren lassen. Bei deren Ausführung wird keine Warnung mehr ausgegeben. Da diese .msi-Installer aber (in den Nightly Builds) bisher unsigniert sind, könnte Malware diese manipulieren. An dieser Stelle habe ich den Test abgebrochen. Falls sich neue Erkenntnisse ergeben, trage ich diese nach.

Ähnliche Artikel
Windows: Aus für Startmenü-Ersatz Classic Shell?
Windows: Info-Splitter, Name für Redstone 5, Classic Shell etc.
Classic Start ist jetzt NeoClassic-UI/Menu


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Windows abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

22 Antworten zu Classic Shell heißt jetzt Open-Shell-Menü

  1. Martin Feuerstein sagt:

    Dann lädt man sich die MSI auf einem sauberen System (oder einem Live-System) herunter und entpackt den MSI-Installer, dafür gab es zumindest in ClassicShell einen Kommandozeilenparamter, um diesen dann für die Bereitstellung im Netzwerk zu verwenden. Das mit den Bootstrappern hat aber schon einen gewissen Sinn, um fehlende Abhängigkeiten nachzuladen, z. B. VC++, .NET Framework, VSTO oder was auch immer (noch mehr ausführbare Dateien im Temp-Verzeichnis ;-)).

    Andererseits lässt sich mit einem Windows Installer per Custom Action auch jedes Programm ausführen oder auch Schadsoftware nachladen usw. Und selbst wenn ich mir ein sauberes MSI herunterlade, liegt dieses normalerweise in einem Verzeichnis, welches potentiell Schreibzugriffe durch den Benutzer, das Systemkonto und auch Schadsoftware erfahren kann.

    Andere MSI(!)-Installer kapseln nur EXE-Installer, meines Wissens z. B. Flash Player und AIR (korrigiert mich, wenn ich falsch liege). Früher gabs Programme, die genau für die faulen Admins gestrickt wurden, um eben sowas zu erreichen (Windows Installer Wrapper Wizard). Der Java RE-Installer entpackt sich ins Appdata\LocalLow des Benutzers als MSI, da sagt auch keiner was. Und auch Microsoft verpackt seinen Windows Installer für Office hinter einer Setup.exe (auch wenn da wohl nix ins Temp geschrieben wird). Bei den "Großen" wird also auch Mist gebaut.

    Und wenn der eigene Computer mit Schadsoftware belastet ist, hat man imho ganz andere Probleme als ein DLL-Hijacking durch den Classic- oder "wie auch immer"-Shell-Installer. Da kann der Stefan Kanthak bei doofen Installern meinetwegen auch nochmal 100 Puls mehr kriegen.

    Und wer (wie ich) EXE-Installer für die Verteilung nicht gebrauchen kann, die Produkte aber dennoch verteilen muss, kann sich die Installer auch "einfach" selbst bauen (zumindest bei Open Source ohne rechtliche Probleme, alternativ beim Hersteller anfragen). So kann man sich dann sicher sein, das am Netzwerk-Bereitstellungspunkt (der durch die Clients nur lesend zugreifbar ist) eine saubere Installationsquelle zur Verfügung steht.

    • Martin Feuerstein sagt:

      Bringt mich dazu: wenns danach gehen würde, müsste eigentlich jedes Programm mit jeder neuen Version (und Update) auf einem nicht-schreibbaren Datenträger vertrieben werden, sei es nun auf CD/DVD-ROM, Floppy (mit ausgebrochenem Read-Only-Schalter), SD-Karte (mit Schreibschutzschalter) oder Read-Only-USB-Stick. Und dann müsste man von PC zu PC laufen für die Installation mit diesem einen Medium. Die Zeiten sind schon etwas her, aber das will auch niemand wieder zurück :-D

      • Günter Born sagt:

        Nein, wenn die .exe-Installer in Verzeichnisse entpacken würden, auf die ein Nutzer mit eingeschränkten Benutzerrechten keine Schreibrechte besitzt, wäre (imho) der Angriffsvektor weg.

        • Martin Feuerstein sagt:

          Das Benutzerkonto hat ja schon Schreibrechte auf das Verzeichnis, in welchem die heruntergeladene Datei liegt, nicht nur aufs Temp-Verzeichnis – und muss die Datei von dort aus starten.

          Alternativ würde der Benutzer die Datei mit einem administrativen Konto herunterladen und ausführen müssen, was dann wieder zum gleichen Problem führt. Dann hätte zwar das normale Benutzerkonto keinen Schreibzugriff mehr auf die Installationsdatei, es bleibt aber das größere Gefahrenpotential durch das Surfen mit erhöhten Rechten (mit bösen Popups, Flash und allem was dazugehört).

          Abgesehen von einer Bereitstellung in einem schreibgeschützten Verzeichnis, in dem der Benutzer das Installationsprogramm selbst nicht gespeichert haben kann, fällt mir spontan keine Lösung ein. Und selbst bei einer schreibgeschützten Bereitstellung z. B. im Netzwerk muss mindestens der Administrator der Umgebung Schreibzugriff gehabt haben – und auch der hat das Installationsprogramm meist aus dem Internet heruntergeladen.

          Bei Datenträgern hat mindestens der Hersteller Schreibzugriff, also auch da ist nicht zwangsläufig der Schutz vor Manipulation an der Quelle gegeben.

          Also doch zurück zu selbstgestanzten Lochkarten. Ich meine du hattest vor einiger Zeit mal einen Beitrag zu deinem Werdegang gemacht, in dem auch die Arbeit mit Lochkarten enthalten war.

          • Günter Born sagt:

            Martin: Ich muss mich korrigieren – ich habe es oben im Text als Ergänzung nachgetragen. Die .exe scheint nur ein Wrapper zum Entpacken zu sein und läuft mit Standardrechten. Die .msi-Installer aktivieren die UAC [internes Manifest legt das fest] selbst (da erkenne ich aktuell keinen Angriffsvektor mehr).

        • AMEN!
          Zum Entpacken (s)einer Nutzlast in ein sicheres, d.h. für unprivilegierte Benutzer/Prozesse nicht beschreibbares Verzeichnis müsste der Entpacker mit Administratorrechten laufen. Gleiches gilt, wenn der Entpacker ein solches sicheres Verzeichnis unterhalb von %TEMP% (oder sonstwo) anlegt.
          Damit öffnet sich allerdings der DIREKTE Angriffsvektor auf den Entpacker.

          Also: die VOLLIDIOTEN, sie ausführbare Installationsprogramme oder selbst-extrahierende Entpacker frickeln, haben die freie Wahl zwischen Pest und Cholera.

          Alle Anderen liefern ein signiertes *.MSI, oder eine signierte*.CAB mit einem signierten *.INF: *.MSI werden von MSIExec.exe verwurstet, und (in *.CAB eingebettete) *.INF vom per RunDll32.exe AdvPack.dll aufgerufenen SetupAPI.

          Beide sind PRINZIPIELL nicht per DLL spoofing/hijacking angreifbar: sie liegen im System-Verzeichnis.
          Weder SetupAPI noch der Windows Installer müssen die in *.MSI oder *.CAB enthaltenen Dateien entpacken, sondern verarbeiten diese DIREKT aus dem Paket/Archiv, OHNE Umweg über ein möglich^Wtypischerweise unsicheres %TEMP%-Verzeichnis.
          Zudem prüfen SetupAPI und Windows Installer die Authenticode-Signaturen der *.MSI und *.CAB sowie deren Nutzlasten.
          Eine Fälschung oder Modifikation führt beim Windows Installer zu einer Warnung und beim SetupAPI zum Abbruch.

      • Wie üblich: AHNUNGSLOS!
        Wer garantiert die Authentizität der auf einem (nicht)schreibgeschützten Medium gespeicherten Dateien?
        Die Authentizität von heruntergeladenen *.MSI und *.CAB, aber auch *.EXE stellt jeder nicht völlig bescheuerte Anbieter mit einer digitalen Signatur sicher.
        Bei der Verarbeitung von *.MSI und *.CAB stellt Windows sicher, dass unprivilegierte Benutzer/Prozesse keinen Einfluss nehmen können. Bei *.EXE ist das NICHT der Fall.
        DAS IST DER KLEINE UNTERSCHIED!

        • monddulbe sagt:

          win8.1 Defender schlägt bei deiner Seite (https://skanthak.homepage.t-online.de/) an, dass, bei Aufruf, da was bereinigt worden sei, warum? Vtotal sagt 0 / 67…

          • Günter Born sagt:

            Das machen auch die Security Essentials. Der Hintergrund (habe ich mal vor langer Zeit mit Stefan Kanthak diskutiert – ich zitiere mal aus unserem Mail-Austausch):

            > Hallo Stefan,
            >
            > kurze Frage. Warum versucht deine Webseite
            > https://skanthak.homepage.t-online.de/ das Eicar-Testvirus auszuliefern,
            > wenn jemand auf der Seite surft?

            Weil einige Schlangenoel-Hersteller noch immer zu bloede oder
            unfaehig sind, URLs wie

            <data:application /octet-stream,X5O!P%25%40AP%5B4%5CPZX54%28P%5E%297CC%297%7D%24EICAR-STANDARD-ANTIVIRUS-TEST-FILE!%24H%2BH*>

            zu erkennen oder zu dekodieren, knapp 20 Jahre nach Einfuehrung von DATA URLs: < https://tools.ietf.org/html/rfc2397>

            Ich verwende diese DATA URLs seit dem letzten Jahrtausend zur
            Demonstration in meinen Webseiten und habe damals fast allen
            Anbietern von Schlangenoel mehrfach demonstriert, dass ihr Zeux
            scheunentorgrosse Loecher hat und KEINERLEI Schutz bietet.

            Kopiere die o.g. URL mal in die Adresszeile ALLER Deiner Browser. Welche wollen dann eine 68 Byte grosse Datei speichern?
            IE und Edge machen das nicht, die interpretieren DATA URLs nicht ueberall: < https://msdn.microsoft.com/en-us/library/cc848897.aspx>

            Hilft aber nichts: die auch von Microsoft verwendete PNGlib oder zlib hatten in den letzten Jahren nette Loecher.

            > Hier schlägt MSE jedes Mal an, wenn ich ein Refresh mache, und löscht das Eicar-Test Virus.

            Die Segnungen von nutz- und wirkungslosem Schlangenoel…

            1. erkennt MSE den Schaedling beim HTTP(S)-Transfer der Seite?

            Dann muesste er die Auslieferung der HTTP-Nutzlast, in diesem
            Fall die HTML-Seite, an den Browser unterbinden, und dieser
            duerfte NICHTS (oder nur eine Fehlermeldung) anzeigen.

            Falls der Browser die HTML-Seite dennoch anzeigt: zu spaet,
            der Browser hat den "Schaedling" bereits interpretiert, MSE
            kommt zu spaet.

            Frage #1: was passiert, wenn Du den Browser den Quelltext der
            HTML-Seite anzeigen laesst (typischerweise per
            CTRL-U)?

            Wenn das NICHT funktioniert weil MSE den "Schaedling" erkennt:
            wieso konnte der Browser die Seite anzeigen?

            Frage #2: was passiert, wenn Du den Browser den Quelltext der
            HTML-Seite speichern laesst (typischerweise per
            CTRL-S)?

            Wenn das NICHT funktioniert weil MSE den "Schaedling" erkennt:
            wieso konnte der Browser die Seite anzeigen?

            2. erkennt MSE den Schaedling (erst) im Browser-Cache?

            Dann ist es zu spaet, der Browser hat den Schaedling laengst
            (bzw. parallel zum Schreiben des Caches) verarbeitet.

            Ich koennte natuerlich auch einen RICHTIGEN Schaedling ausliefern,
            den kein Virenscanner erkennt … beispielsweise einen der auf
            < https://skanthak.homepage.t-online.de/malware.html> gezeigten.

            Einige (aber nicht alle) Browser wollen schlau sein und laden die
            im HTML-Code per

            <head>
                    <link REL="Next" HREF=.../>
                    <link REL="Previous" HREF=.../>
                    <link REL="Related" HREF=.../>
                </head>

            als "naechste", "vorherige" oder "verwandte" Seite angegebenen
            URLs auf Verdacht und dekodieren dort angegebene DATA URLs, ohne
            Zutun des Benutzers; wenn sie den dekodierten Inhalt dann in den
            Browser-Cache schreiben schlaegt der Virenscanner an.

            Ich hoffe, das reicht als Erklärung. Wir haben Schlangenöl und ne Menge Schlangengruben …

            aus diesem Grunde plane ich hier auch weitere Artikel von 'Zeugx', welches ich von Stefan Kanthak zugeschickt bekommen habe, aufzubereiten.

          • monddulbe sagt:

            bleibt immer noch mehr so abschreckend. für normale Nutzer.
            Was soll ich ins tiefere html-etc. eintauchen (wollen), um irgendwas merkwürdiges einer x-beliebigen Seite nachvollziehen zu können – wozu? Weiss mit meiner Zeit besseres anzufangen.
            Es fehlt ein (Warn-)Hinweis auf dieser Seite, indiskutabel. Das kann man sich nu schönlügen – oder aber, sinnvoller, sowas links liegen lassen. Weil Null Mehrwert.

          • Günter Born sagt:

            @monddulbe: Es bleibt dir unbenommen, die Seite links liegen zu lassen und ich sehe dich von den Seiteninhalten nicht als Zielgruppe (ich kann sogar deine Reaktion verstehen). Aber der Ansatz, einen data Tag mit dem Eicar-Testvirus zu bestücken, dieses Element aber nicht in einem Seitenscript abzurufen und zu sehen, was passiert, ist imho bestechend.

            Das ist ja im Grunde die Schizophrenie: Die Leute wollen maximal sicher sein, installieren sich das neueste Windows (wird in höchsten Tönen gelobt) und on Top kommt der neueste Kaspersky oder was weiß ich. Wird dann mal aufgezeigt, was da alles im Argen liegt, fängt die Mannschaft sofort an, zu relativieren (machen andere doch auch so) und abzuwiegeln (lässt sich das ausnutzen, zu kompliziert etc.). Beobachte ich bei einigen meiner Artikel aus diesem Genre.

            Mein Fazit nach diversen Artikeln der letzten 2 Wochen: Die Leute wollen belogen werden oder nichts davon hören, und erwarten weiße Salbe … Beherzigt man das, dann segelt es sich als Blogger am leichtesten ;-).

            PS: Ich werde nie Sicherheitscrack werden – aber bei bestimmten Themen löckt mich halt der Stachel – ergo greife ich so was auf und wenn's zum Test ist, ob vorhersehbare Reaktionen auf einen Artikel kommen.

            PPS: Gerade die proof in diesem Artikel (geht um elektronische Wahlmaschinen aus den USA, die auf der Defcon von einem 11 jährigen Mädchen manipuliert werden konnten) gefunden, dass es anderen auch nicht anders geht.

    • Günter Born sagt:

      'Bei den "Großen" wird also auch Mist gebaut.' Nun, da kann ich dir leider nicht widersprechen – und speziell bei MS gibt es Dokumente (sind ein paar Jahre alt), die erklären, was man aus Sicherheitsgründen nicht machen soll. Aber da hält sich niemand dran.

      Bzgl. der ose.exe (Office Installer) – ich habe es nicht veröffentlicht. Mir liegt eine Info des MS-Entwicklerteams an Kanthak vor, dass man diese Schwachstelle nach seinen Hinweisen entfernt hat. Ob es final zutrifft, kann ich nicht sagen – man wird es ggf. hören.

  2. "Werden die .msi-Dateien zur Installation benutzt, gibt es die obige Schwachstelle nicht."
    AUTSCH!
    Wie überprüfst Du die Authentizität der entpackten *.MSI?

    Weder diese noch der Entpacker sind digital signiert, sie können von Hinz&Kunz manipuliert worden sein … oder von einer der DLLs, die der Entpacker aus seinem "application directory" geladen hat, und die die volle Kontrolle über diesen Prozess haben.

    • Martin Feuerstein sagt:

      Nur so zur Ehrenrettung: Die alten Releases von Ivaylo Beltchev *sind* digital signiert.

      Die neuen Releases von Coddec sind tatsächlich (noch?) nicht digital signiert – es sind aber auch "nur" ein "Developer Release" und darauf aufbauend ein "Hotfix for Windows Insider Preview" verfügbar, also eigentlich noch nix für den Endanwender (es steht – anders als bei Kaffeebechern von McD, die warnen, dass der Kaffee heiß sein könnte – nicht dabei, dass man das nur installieren sollte, wenn man auch weiß, was man da tut).

  3. Anonymous sagt:

    @Stefan und Günter:
    Ich möchte (hierzu halbwegs passend) mitteilen, dass selbst vom BSI explizit für die Verarbeitung von VS-NfD-eingestuften Daten zugelassene Programme (siehe https://www.bsi.bund.de/DE/Themen/Sicherheitsberatung/ZugelasseneProdukte/Liste_Produkte/Liste_Produkte_html.html ) diese Probleme aufweisen. Ich nutze sowohl Ecos SBS als auch Sirrix/Rohde und Schwarz Trusted Disk. Der Sentinel von Herrn Kanthak schlägt sowohl beim Enrollment von Ecos an, als auch beim Verwenden der Trusted Disk Hilfskomponente CardOS API von ATOS.

    Man sollte meinen, dass das BSI solche Dinge in seinen Prüfungen finden sollte. Ich habe dies auch vor längerer Zeit dem Support von ATOS mitgeteilt, erhielt aber keine Antwort.

  4. Bernhard Diener sagt:

    Ich frage mich, ob diese Lücken, die Herr Kanthak vorführt, überhaupt ernst genommen werden. Ich kenne selbst zwei Programme, die diese aufweisen (gefunden über Kanthaks Sentinel), und diese Programme sind in dieser Version derzeit sogar vom BSI geprüft und zugelassen für Verarbeitung von eingestuftem Datenmaterial (Geheimschutz: VS-NfD): Ecos SBS und Rohde und Schwarz Trusted Disk (siehe Liste https://www.bsi.bund.de/DE/Themen/Sicherheitsberatung/ZugelasseneProdukte/Liste_Produkte/Liste_Produkte_html.html ). Trusted Disk benutzt zum Beispiel die Hilfskomponente ATOS CardOS API 5.4 U11, welche ein Autostartelement installiert, bei welchem Sentinel anschlägt. Habe ATOS informiert, keine Reaktion, keine Änderung.
    Interesse?

    • Ich nehme an, die beiden mit dem Wix Toolset verbrochenen *.MSI tragen den Pfadnamen zum installierten Programm cardoscp.exe unter
      [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
      "CardOS API"="C:\Program Files\…\cardoscp.exe"
      ohne die notwendigen Anführungszeichen ein.
      Siehe https://cwe.mitre.org/data/definitions/428.html

      Solche ANFÄNGER-Fehler sind Industriestandard!
      JEDER nicht völlig ahnungslose Entwickler und erst recht dessen Tester und JEDE Qualitätssicherung dürfte die fehlenden Anführungszeichen übersehen … zumal sie eine der MINIMAL-Anforderungen der inzwischen 23 Jahre alten "Designed for Windows"-Richtlinien Microsofts sind.

      Dummerweise können seit Vista nur Administratoren C:\Program.exe anlegen, daher spielen viele Frickelbuden diese Ausprägung des Anfängerfehlers herunter … obwohl das bei der Windows-Installation angelegte Benutzerkonto noch immer ein "Administrator" und die Benutzerkontensteuerung ein SEHR schlechter Scherz ist!
      Da C:\Program.exe mit den Rechten des sich gerade anmeldenden Benutzers ausgeführt wird kann es nicht mehr Schaden anrichten als jedes andere Programm, das dieser Benutzer beispielsweise in seinem "Downloads"-Ordner zur Ausführung bringt…

      "Hübscher" sind die von Ahnungslosen verbrochenen "custom actions":
      1) cmd.exe /c "pnputil -a setup.inf"
      2) BIN_vc_redistEXE_x86 /q /norestart

      JEDER nicht völlig ahnungslose Entwickler würde %SystemRoot%\System32\PnPUtil.exe natürlich DIREKT mit seinem vollqualifizierten Pfad aufrufen, anstatt indirekt über den Kommandoprozessor, und auch den wohlbekannten vollqualifizierten Pfad der setup.inf angeben.

      BIN_vc_redistEXE_x86 ist ein von Microsoft mit einem veralteten Wix Toolset 3.7.3813.0 verbrochenes Installationsprogramm (für die MSVCRT 2015), das TRIVIAL angreifbar ist.
      Siehe dazu http://seclists.org/bugtraq/2016/Jan/105 sowie https://www.firegiant.com/blog/2016/1/20/wix-v3.10.2-released/

      Zur Demonstration empfehle ich, die NTFS-ACE (D;OIIO;WP;;;WD) auf %TEMP% sowie %SystemRoot%\Temp zu setzen. Letzteres kann der während der Windows-Installation angelegte Benutzer ohne UAC-Intervention sobald https://support.microsoft.com/en-us/kb/950934 einmal zugeschlagen hat.

  5. Bernhard Diener sagt:

    Du hast Recht bezüglich der Anführungszeichen. Noch mehr: Ausgabe von Sentinel:
    ATTENTION!
    This might have been the call and the execution of a malicious executable (worm, virus, trojan horse)!
    Executed process: C:\Program.exe
    Executed command: C:\Program Files\CardOS API\bin\chkscreg.exe
    Calling process: cardoscp.exe
    Current directory: C:\WINDOWS\System32

    und ein zweites Mal:
    Executed process: C:\Program.exe
    Executed command: C:\Program Files\CardOS API\bin\chkscreg64.exe
    Calling process: cardoscp.exe
    Current directory: C:\WINDOWS\System32

    Danke für den Kommentar.

  6. wufuc_MaD sagt:

    ich verstehe und beachte den hier erhaltenen hinweis .msi statt .exe installer zu nehmen wo immer man die auswahl hat, ist ja recht häufig. gehört für mich zum beruf wenn man dazu lernt und kunden einem vertrauen schenken. danke für die hinweise!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.