Anderes Programm im eigenen Installer installieren (Error 1618: Es wird bereits anderweitig eine Installation ausgeführt)

Hallo,

ich liefere meine eigene Software per InstallShield-Setup-Paket an den
Anwender aus. Da sind ein paar Fremd-DLLs dabei, die diese "VC-Runtime"
im System benötigen. Bisher habe ich die beiden dazu nötigen Dateien
(MSVC...DLL) einfach mitinstalliert (=mit in den Programmordner kopiert),
aber inzwischen sind die Fremd-DLLs mit VC++2017 compiliert, und der
Hersteller dieser DLLs meint, man solle die jetzt nötige "vcredist 2017"
unbedingt mit dem Microsoft-eigenen Installer installieren, weil da
irgendwelche komplexen Abhängigkeiten drin sind und das simple Kopieren
von zwei Dateien möglicherweise nicht mehr genügt.

Gesagt, getan - also rufe ich während meiner eigenen Programminstallation
eben das originale "vc_redist.x86.exe" auf (mit "/install /passive" oder
"/install /quiet", damit der Benutzer nicht "Ok" klicken braucht oder so).

Hat nur leider den Haken, dass das aufgerufene vc_redist.x86.exe dann sagt:
"Error 1618 (Es wird bereits anderweitig eine Installation ausgeführt.
Beenden Sie den anderen Installationsvorgang, bevor Sie diese Installation
fortsetzen)".

Wenn man so darüber nachdenkt, ist das eigentlich auch logisch - denn es
läuft ja gerade _meine_eigene_ Installation!

Das ist natürlich ein systematisches Problem - wie löst man das denn am
besten?

Bei manchen Fremdprogrammen habe ich während der Installation auch gelegent-
lich schon mal das VCRuntime-Fenster kurz aufploppen sehen - da ging's ja
auch. Wie haben die das gemacht?

Beim Googeln habe ich bisher nur irgendwelche "Hilfskrücken" mit Verändern
von Registry-Einträgen gefunden, à la http://www.installsite.org/pages/de/msifaq/error/1618.htm
aber bevor ich solche "Hintertüren" aufmache, wollte ich erst mal fragen,
ob es dafür nicht auch einen "offiziellen" Weg gibt...

Danke & Gruß Matthias.

Edzard Egberts

2017-06-30 09:36:52 UTC

Post by Matthias Hanft
ich liefere meine eigene Software per InstallShield-Setup-Paket an
den Anwender aus. Da sind ein paar Fremd-DLLs dabei, die diese
"VC-Runtime" im System benötigen. Bisher habe ich die beiden dazu
nötigen Dateien (MSVC...DLL) einfach mitinstalliert (=mit in den
Programmordner kopiert), aber inzwischen sind die Fremd-DLLs mit
VC++2017 compiliert, und der Hersteller dieser DLLs meint, man solle
die jetzt nötige "vcredist 2017" unbedingt mit dem Microsoft-eigenen
Installer installieren, weil da irgendwelche komplexen Abhängigkeiten
drin sind und das simple Kopieren von zwei Dateien möglicherweise
nicht mehr genügt.

Die DLLs in das Verzeichnis des Programms zu kopieren, das diese DLLs
benötigt, ist eigentlich die sauberste Lösung - die Verwendung der
System-DLLs führt leicht in die "DLL-Hell". Noch besser wäre es, die
Libs gleich statisch zu linken, dann muss man gar nichts mehr
installieren. Das Problem sind nicht irgendwelche komplexen
Abhängigkeiten, sondern die Lizenzbestimmungen - AFAIK darf man den
MSVC-Kram nämlich nicht einfach kopieren oder gar statisch linken.

Von daher benutze ich LGPL-Open-Source plus MinGW und linke alles
statisch in die Programme, so dass die Win-32bit-Programme auch unter
Win-64bit laufen. Den MS-Schrott kann man ja nicht verwenden, ohne sich
irgendwelche undurchsichtigen Lizenzbedingungen einzufangen, vor allem
kann man dieser Firma nicht vertrauen.

Post by Matthias Hanft
Das ist natürlich ein systematisches Problem - wie löst man das denn
am besten?

Ein Wrapper, der erst den MSVC-Kram installiert und dann Deine
Installation aufruft? Ist das zu trivial?

Matthias Hanft

2017-06-30 10:29:53 UTC

Post by Edzard Egberts
Die DLLs in das Verzeichnis des Programms zu kopieren, das diese DLLs
benötigt, ist eigentlich die sauberste Lösung - die Verwendung der
System-DLLs führt leicht in die "DLL-Hell". Noch besser wäre es, die
Libs gleich statisch zu linken, dann muss man gar nichts mehr
installieren. Das Problem sind nicht irgendwelche komplexen
Abhängigkeiten, sondern die Lizenzbestimmungen - AFAIK darf man den
MSVC-Kram nämlich nicht einfach kopieren oder gar statisch linken.

Ja, andere technische Lösungen wären natürlich vorzuziehen, das
stimmt. Aber durch die Fremd-DLLs sind mir da die Hände gebunden.

Post by Edzard Egberts
Ein Wrapper, der erst den MSVC-Kram installiert und dann Deine
Installation aufruft? Ist das zu trivial?

Stimmt, wäre eine Lösung - muss der Benutzer halt zweimal die UAC
abnicken, aber warum auch nicht. Wobei die erneute MSVC-Installation
bei späteren Programmupdates natürlich eigentlich überflüssig wäre,
aber die (programmgesteuerte) Beantwortung der Frage "ist die MSVC-
Runtime bereits installiert?" (damit man die Installation im Wrapper
ggf. überspringen könnte) scheint nicht trivial zu sein und lief in
einem Forum auf die Lösung hinaus "einfach immer installieren; wenn
schon installiert, tut der Installer einfach nix".

Eine andere Lösung (bei der ich keinen Wrapper bauen müsste) ist mir
auch noch eingefallen: das VCRedist-Zeug in meinem Installer *nicht*
installieren und beim ersten Programmstart nachholen. Da kann man
dem Anwender dann auch vorher eine Dialogbox einblenden, damit er
nicht überrascht wird, was da abläuft. Auch hier wäre es natürlich
von Vorteil, wenn man beim erwähnten Programmstart irgendwie prüfen
könnte, ob man den VCRedist-Installer aufrufen muss oder nicht.
Notfalls könnte man "LoadLibrary(FremdDLL)" probieren, und wenn da
als Fehler kommt "das angegebene Modul wurde nicht gefunden", wäre
das ein Hinweis auf die fehlende VCRuntime. Denn sonst kommt bei
einer "immer installieren"-Funktion erst die Dialogbox "Obacht,
jetzt wird gleich VCRuntime installiert", und dann passiert nix -
auch verwirrend für den Anwender...

In der Registry nachgucken, ob es unter HKLM\SOFTWARE\Microsoft\
Visual Studio\14.0\VC\Runtimes\x86" einen Schlüssel "Installed"
mit dem Wert 1 gibt, ist vermutlich auch nicht "offiziell", würde
aber anscheinend funktionieren...?! Wobei sie auf
https://stackoverflow.com/questions/12206314/detect-if-visual-c-redistributable-for-visual-studio-2012-is-installed
stattdessen (für 2017/x86)
[HKEY_CLASSES_ROOT\Installer\Dependencies\,,x86,14.0,bundle\Dependents\{c239cea1-d49e-4e16-8e87-8c055765f7ec}]
vorschlagen, aber das ist anscheinend versionsabhängig (25008;
inzwischen kann man 25017 runterladen, der scheint stattdessen
{f325f05b-f963-4640-a43b-c8a494cdda0f} zu haben - das kann man
also nehmen, wenn man eine ganz bestimmte Version haben will,
aber ansonsten fände ich (wenn überhaupt die Registry testet,
weil man keine bessere Möglichkeit findet) die erste Methode
sinnvoller...?!

Gruß Matthias.

Edzard Egberts

2017-06-30 11:16:16 UTC

Post by Matthias Hanft
Eine andere Lösung (bei der ich keinen Wrapper bauen müsste) ist mir
auch noch eingefallen: das VCRedist-Zeug in meinem Installer *nicht*
installieren und beim ersten Programmstart nachholen.

Dann muss das Programm aber ggf. mit Admin-Rechten gestartet werden,
davon kann man IMHO nicht ausgehen - schon bei der Installation ist es
Zufall, wenn der Windows-Benutzer dran denkt.

Post by Matthias Hanft
Notfalls könnte man "LoadLibrary(FremdDLL)" probieren, und wenn da
als Fehler kommt "das angegebene Modul wurde nicht gefunden", wäre
das ein Hinweis auf die fehlende VCRuntime.

Ich habe im ersten Moment an "testweise Programm ausführen
und Fehlercode auswerten" gedacht, LoadLibrary() wäre aber eleganter.

Post by Matthias Hanft
Wobei sie auf
https://stackoverflow.com/questions/12206314/detect-if-visual-c-redistributable-for-visual-studio-2012-is-installed
stattdessen (für 2017/x86)
[HKEY_CLASSES_ROOT\Installer\Dependencies\,,x86,14.0,bundle\Dependents\{c239cea1-d49e-4e16-8e87-8c055765f7ec}]
vorschlagen, aber das ist anscheinend versionsabhängig (25008;
inzwischen kann man 25017 runterladen, der scheint stattdessen
{f325f05b-f963-4640-a43b-c8a494cdda0f} zu haben - das kann man
also nehmen, wenn man eine ganz bestimmte Version haben will,

Das ist die korrekte Lösung (vorausgesetzt man kann sich auf die
Registry verlassen), denn Du willst natürlich die Version installiert
haben, die zu Deinem Programm passt. Bei einer älteren Version könnte es
sonst passieren, dass das Programm zwar losläuft, dann aber bei einem
nicht implementierten Einsprung abstürzt.

Matthias Hanft

2017-06-30 12:56:14 UTC

Dann muss das Programm aber ggf. mit Admin-Rechten gestartet werden,
davon kann man IMHO nicht ausgehen - schon bei der Installation ist es
Zufall, wenn der Windows-Benutzer dran denkt.

Ich hatte eigentlich angenommen, dass die UAC-Abfrage beim Start des
vcredist-Installiers (via CreateProcess) erscheint? Dann läuft halt
*der* mit Admin-Rechten - und *mein* Programm muss das ja nicht. Bin
leider noch nicht so weit beim Programmieren - werde ich heute nach-
mittag mal ausprobieren...

Post by Matthias Hanft
[HKEY_CLASSES_ROOT\Installer\Dependencies\,,x86,14.0,bundle\Dependents\{c239cea1-d49e-4e16-8e87-8c055765f7ec}]

Der Hersteller der Fremd-DLLs sagt nur "Visual Studio 2017". Ich gehe
mal davon aus, dass es dann egal ist, ob Build 25008 oder 25017 beim
Anwender installiert ist.

Gruß Matthias.

Matthias Hanft

2017-06-30 15:44:37 UTC

Post by Matthias Hanft
Ich hatte eigentlich angenommen, dass die UAC-Abfrage beim Start des
vcredist-Installiers (via CreateProcess) erscheint? Dann läuft halt
*der* mit Admin-Rechten - und *mein* Programm muss das ja nicht. Bin
leider noch nicht so weit beim Programmieren - werde ich heute nach-
mittag mal ausprobieren...

Ja, das geht. Also mein Programm startet als normaler User, stellt
anhand des fehlenden Registry-Eintrags fest, dass die vcredist fehlt,
startet das vcredist.exe via CreateProcess, dann kommt automatisch
die UAC-Abfrage, und das Zeug wird installiert. Falls der User bei
der UAC-Abfrage "Nein" drückt, kriegt mein Programm das sogar über
den Exit-Code 1602 ("Die Installation wurde vom Benutzer abgebro-
chen") mit (ansonsten kommt S_OK, also 0).

Das sieht doch schon mal gut aus. Ich werde das jetzt mit den pas-
senden Dialogfeldern für normalsterbliche Anwender garnieren, und,
wenn keine Katastrophen mehr passieren, so lassen.

Gruß Matthias.

Stefan Kanthak

2017-06-30 12:17:13 UTC

Post by Matthias Hanft
Hallo,
ich liefere meine eigene Software per InstallShield-Setup-Paket an den
Anwender aus.

AUTSCH!
AUSFUEHRBARE Installationspakete sind defekt per Design und ALLE kaputt:
siehe <https://skanthak.homepage.t-online.de/~execute.html>

Post by Matthias Hanft
Da sind ein paar Fremd-DLLs dabei, die diese "VC-Runtime"
im System benötigen. Bisher habe ich die beiden dazu nötigen Dateien
(MSVC...DLL) einfach mitinstalliert (=mit in den Programmordner kopiert),

AUTSCH!
Dort werden sie von Windows Update nicht entdeckt und nicht aktualisiert;
siehe <https://support.microsoft.com/kb/835322>

Post by Matthias Hanft
aber inzwischen sind die Fremd-DLLs mit VC++2017 compiliert, und der
Hersteller dieser DLLs meint, man solle die jetzt nötige "vcredist 2017"
unbedingt mit dem Microsoft-eigenen Installer installieren, weil da
irgendwelche komplexen Abhängigkeiten drin sind und das simple Kopieren
von zwei Dateien möglicherweise nicht mehr genügt.

Siehe <https://support.microsoft.com/kb/326922> und neuere MSKB-Artikel.

Post by Matthias Hanft
Das ist natürlich ein systematisches Problem - wie löst man das denn am
besten?

Durch Bauen eines *.MSI

Stefan
[

--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)

Matthias Hanft

2017-06-30 13:04:01 UTC

Post by Stefan Kanthak
siehe <https://skanthak.homepage.t-online.de/~execute.html>

The requested URL /~execute.html was not found on this server.

Post by Matthias Hanft
im System benötigen. Bisher habe ich die beiden dazu nötigen Dateien
(MSVC...DLL) einfach mitinstalliert (=mit in den Programmordner kopiert),

Dort werden sie von Windows Update nicht entdeckt und nicht aktualisiert;

Aber die müssen/sollen ja auch nicht geupdatet werden - das sind
ja die speziellen MSVC-DLLs für _genau_diese_ Software.

Post by Stefan Kanthak
Siehe <https://support.microsoft.com/kb/326922> und neuere MSKB-Artikel.

Dieser Artikel geht nur bis VC++2005.

Für VC++2017 schreibt der Hersteller der Fremd-DLLs:

--- schnipp ---

der "Nachfolger" zur MSVCR120.DLL heißt VCRUNTIME140.DLL, aber es genügt nicht, nur die beiden Bibliotheken MSVCP140.DLL und VCRUNTIME140.DLL in das Anwendungsverzeichnis zu legen!

Microsoft hat die neue Visual C++ 2017-Runtime in zahlreiche Einzelbibliotheken aufgespalten, die wiederum haben eine Abhängigkeit zur Windows Universal CRT haben, die unter Windows-Versionen vor
Windows 10 nicht garantiert vorhanden ist.

Wir empfehlen daher, die Microsoft Redistributables als ganzes zu installieren, da die Abhängigkeiten der zahlreichen Runtime-Bibliotheken nicht dokumentiert sind und sich bei Updates ändern könnten.
Ein weiterer Grund: Microsofts Redistributable Installer installieren die Windows Universal CRT bei Bedarf automatisch mit.

--- schnapp ---

Also führt wohl nichts am Aufruf von vc_redist.x86.exe vorbei...

Post by Matthias Hanft
Das ist natürlich ein systematisches Problem - wie löst man das denn am
besten?

Durch Bauen eines *.MSI

Ich kann InstallShield (durch Weglassen des Häkchens bei "Installer
inkludieren") schon dazu bringen, ein MSI statt ein EXE zu produzieren.
Aber das löst ja nicht das grundsätzliche Problem während der Installation.

Gruß Matthias.

Stefan Kanthak

2017-06-30 21:55:10 UTC

Post by Matthias Hanft

Post by Stefan Kanthak
siehe <https://skanthak.homepage.t-online.de/~execute.html>

The requested URL /~execute.html was not found on this server.

AUTSCH, mein Fehler: korrekt ist ...!execute.html

Post by Matthias Hanft

Post by Matthias Hanft
im System benötigen. Bisher habe ich die beiden dazu nötigen Dateien
(MSVC...DLL) einfach mitinstalliert (=mit in den Programmordner kopiert),

Dort werden sie von Windows Update nicht entdeckt und nicht aktualisiert;

Aber die müssen/sollen ja auch nicht geupdatet werden - das sind
ja die speziellen MSVC-DLLs für _genau_diese_ Software.

Post by Stefan Kanthak
Siehe <https://support.microsoft.com/kb/326922> und neuere MSKB-Artikel.

Dieser Artikel geht nur bis VC++2005.

und gilt sinngemaess auch fuer neuere Versionen!
[...]

Post by Matthias Hanft
Also führt wohl nichts am Aufruf von vc_redist.x86.exe vorbei...

Nur wenn Microsoft keine *.MSM fuer die benoetigte Version der MSVCRT
bereitstellt.
ABER: *.MSM aelterer Versionen werden von Windows Update nicht erkannt,
sodass die notwendigen (Sicherheits-)Updates nicht installiert werden!

Post by Matthias Hanft

Post by Matthias Hanft
Das ist natürlich ein systematisches Problem - wie löst man das denn am
besten?

Durch Bauen eines *.MSI

Ich kann InstallShield (durch Weglassen des Häkchens bei "Installer
inkludieren") schon dazu bringen, ein MSI statt ein EXE zu produzieren.

Kannst Du InstallShield auch beibringen, *.MSI nicht mit ihren proprietaeren
Skripts zu versauen?

Post by Matthias Hanft
Aber das löst ja nicht das grundsätzliche Problem während der Installation.

Doch: saubere *.MSI rufen keine externen Programme auf!

Stefan
[

Edzard Egberts

2017-06-30 13:10:17 UTC

Post by Matthias Hanft
Hallo,
ich liefere meine eigene Software per InstallShield-Setup-Paket an
den Anwender aus.

AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design und
ALLE kaputt: siehe
<https://skanthak.homepage.t-online.de/~execute.html>

Geht nicht, aber das:

http://skanthak.homepage.t-online.de/!execute.html

Echt jetzt, das muss man alles beachten, um irgend ein Programm auf
Windows zu installieren? Ist ja wohl eine Zumutung!

AUTSCH! Dort werden sie von Windows Update nicht entdeckt und nicht
aktualisiert; siehe <https://support.microsoft.com/kb/835322>

Garantiert mir Microsoft, dass so eine Aktualisierung mein Programm
nicht kaputt macht?

Post by Matthias Hanft
aber inzwischen sind die Fremd-DLLs mit VC++2017 compiliert, und
der Hersteller dieser DLLs meint, man solle die jetzt nötige
"vcredist 2017" unbedingt mit dem Microsoft-eigenen Installer
installieren, weil da irgendwelche komplexen Abhängigkeiten drin
sind und das simple Kopieren von zwei Dateien möglicherweise nicht
mehr genügt.

Siehe <https://support.microsoft.com/kb/326922> und neuere
MSKB-Artikel.

Post by Matthias Hanft
Das ist natürlich ein systematisches Problem - wie löst man das
denn am besten?

Durch Bauen eines *.MSI

Warum macht MS selber das nicht, sondern gibt den vcredist-Krempel als
"Executable installer" heraus? Du willst uns doch veräppeln! ;o)

Claus Reibenstein

2017-06-30 14:29:39 UTC

Post by Matthias Hanft
ich liefere meine eigene Software per InstallShield-Setup-Paket an
den Anwender aus.

AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design und
ALLE kaputt: siehe
<https://skanthak.homepage.t-online.de/~execute.html>

http://skanthak.homepage.t-online.de/!execute.html

Nun ja, ein kleiner Typo. Kann ja mal passieren. Die beiden Zeichen
liegen ja auch so dicht beieinander ... ;-)

Post by Edzard Egberts
Echt jetzt, das muss man alles beachten, um irgend ein Programm auf
Windows zu installieren? Ist ja wohl eine Zumutung!

Das ist Windows doch schon lange.

AUTSCH! Dort werden sie von Windows Update nicht entdeckt und nicht
aktualisiert; siehe <https://support.microsoft.com/kb/835322>

Garantiert mir Microsoft, dass so eine Aktualisierung mein Programm
nicht kaputt macht?

Gute Frage. Nächste Frage: Garaniert Dir irgendjemand, dass diese DLLs
keine Sicherheitslücken enthalten und deshalb nicht gepflegt werden
müssen? Garantierst Du das Deinen Kunden? Übernimmst Du die volle
Verantwortung dafür?

Post by Matthias Hanft
Das ist natürlich ein systematisches Problem - wie löst man das
denn am besten?

Durch Bauen eines *.MSI

Warum macht MS selber das nicht, sondern gibt den vcredist-Krempel als
"Executable installer" heraus?

It's Microsoft, you know ...

Post by Edzard Egberts
Du willst uns doch veräppeln! ;o)

Kanthak? Keine Ahnung. Microsoft? Mit Sicherheit!

Gruß
Claus

Edzard Egberts

2017-07-03 06:21:22 UTC

Post by Edzard Egberts
Garantiert mir Microsoft, dass so eine Aktualisierung mein Programm
nicht kaputt macht?

Dafür, dass ich nicht alle Sicherheitslücken beheben muss, benutze ich
ein OS, statt barebone zu Programmieren.

Ein Beispiel: Zur Zeit arbeite ich an Wolkenerkennung mit der OpenCV -
das Programm bekommt Fotos als Input und wirft Tabellen und Grafiken
aus. Ich erwarte von einem Betriebssystem, dass so ein Programm in einer
sicheren Umgebung läuft und ich mich *nicht* um irgendwelche
Sicherheitslücken kümmern muss, gerade bei Programmen, die an sich
nichts sicherheitskritisches unternehmen. Ansonsten könnte ich doch
besser gleich alles selber machen.

Und warum soll ich Verantwortung für Sicherheitslücken in Windows
übernehmen? Nehmen wir den umgekehrten Fall und Microsoft macht eine DLL
kaputt: Dann hat erst der Kunde Ärger, danach der Händler, dann mein
Chef, dann ich. Je nach Problem geht der Ärger dann richtig los und
weitet sich ggf. noch auf Gerichte und Familienangehörige aus. Und jetzt
überlege mal, wer dann die ganze Zeit nicht den geringsten Ärger und
auch gar kein Interesse an einer Fehlerbehebung hat (Tipp: "Fragen Sie
Ihren PC-Händler oder Systemadministrator (aber bloß nicht uns!)")?

Ich übernehme *immer* die volle Verantwortung, da bleibt mir gar nichts
anderes übrig!

Stefan Kanthak

2017-07-03 11:29:15 UTC

Post by Edzard Egberts
Garantiert mir Microsoft, dass so eine Aktualisierung mein Programm
nicht kaputt macht?

Dafür, dass ich nicht alle Sicherheitslücken beheben muss, benutze ich
ein OS, statt barebone zu Programmieren.

Dann informiere Dich ENDLICH ueber die Funktionsweise und die daraus
resultierenden Schwachstellen des von Dir missbrauchten OS: eine GANZE
Reihe von Sicherheitsluecken baust Du durch Ignoranz in Deine Programme
ein.

Stefan
[

Edzard Egberts

2017-07-03 12:15:50 UTC

Post by Edzard Egberts
Garantiert mir Microsoft, dass so eine Aktualisierung mein
Programm nicht kaputt macht?

Gute Frage. Nächste Frage: Garaniert Dir irgendjemand, dass diese
DLLs keine Sicherheitslücken enthalten und deshalb nicht gepflegt
werden müssen? Garantierst Du das Deinen Kunden? Übernimmst Du
die volle Verantwortung dafür?

Dafür, dass ich nicht alle Sicherheitslücken beheben muss, benutze
ich ein OS, statt barebone zu Programmieren.

Dann informiere Dich ENDLICH ueber die Funktionsweise und die daraus
resultierenden Schwachstellen des von Dir missbrauchten OS: eine
GANZE Reihe von Sicherheitsluecken baust Du durch Ignoranz in Deine
Programme ein.

Ich weiß, es ist viel verlangt, aber bitte nenne mir doch mindestens ein
Beispiel dafür, das ich verstehe (oder von dem Du erwartest, dass das
irgend ein anderer verstehen könnte ;o) und am Besten auch sofort
anwenden kann. Mir bleibt nämlich völlig unverständlich, wie ein
triviales Programm (z.B. eine Textverarbeitung oder ein Paint), das nur
die Windows-API verwendet, Sicherheitslücken öffnen könnte, die nicht
sowieso schon in Windows vorhanden sind.

Warum soll es das Problem des Programmierers sein, wenn ein Programm
ohne sicherheitsrelevante Funktionen, das ganz normal mit Userrechten
läuft, irgendwelche Sicherheitslücken erzeugen kann? Das ist doch
einfach nur ein Komplettversagen des Betriebssystems und nur deshalb ein
Problem, weil MS so etwas eben auf die Anwender abwälzt. An "WannaCry"
ist inzwischen ja auch die NSA schuld (weil die die Lücke nicht
veröffentlich haben) und nicht MS (obwohl die die Lücke programmiert
haben)... :o/

Stefan Kanthak

2017-07-03 14:23:27 UTC

Post by Edzard Egberts
Garantiert mir Microsoft, dass so eine Aktualisierung mein
Programm nicht kaputt macht?

Gute Frage. Nächste Frage: Garaniert Dir irgendjemand, dass diese
DLLs keine Sicherheitslücken enthalten und deshalb nicht gepflegt
werden müssen? Garantierst Du das Deinen Kunden? Übernimmst Du
die volle Verantwortung dafür?

Dafür, dass ich nicht alle Sicherheitslücken beheben muss, benutze
ich ein OS, statt barebone zu Programmieren.

Dann informiere Dich ENDLICH ueber die Funktionsweise und die daraus
resultierenden Schwachstellen des von Dir missbrauchten OS: eine
GANZE Reihe von Sicherheitsluecken baust Du durch Ignoranz in Deine
Programme ein.

Hierzufred geht's NICHT um triviale (und in SICHEREN Verzeichnissen
installierte) Programme, sondern um Installations-Programme, die
typischerweise mit Administratorrechten laufen und in UNSICHEREN
Verzeichnissen gestartet werden.

Post by Edzard Egberts
Warum soll es das Problem des Programmierers sein, wenn ein Programm
ohne sicherheitsrelevante Funktionen, das ganz normal mit Userrechten
läuft, irgendwelche Sicherheitslücken erzeugen kann?

Seit Anbeginn der Zeiten von MS-DOS und dessen Nachfolger Windows ist
. alias CWD im Suchpfad.
Die daraus resultierenden Schwachstellen sind seit ueber 20 Jahren
wohlbekannt und wohldokumentiert, u.a. im Auftrag der NSA: siehe
<http://www.blacksheepnetworks.com/security/info/nt/ntintrotosec.htm>.

Spaetestens nach <http://www.guninski.com/officedll.html> alias
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0854> alias
<https://cwe.mitre.org/data/definitions/426.html> alias
<https://cwe.mitre.org/data/definitions/427.html> sowie
<https://capec.mitre.org/data/definitions/471.html>,
<https://blogs.msdn.microsoft.com/david_leblanc/2008/02/20/dll-preloading-attacks/>
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>
<https://blogs.technet.microsoft.com/srd/2009/04/14/ms09-014-addressing-the-safari-carpet-bomb-vulnerability/>,
<https://blogs.technet.microsoft.com/srd/2010/08/23/more-information-about-the-dll-preloading-remote-attack-vector/>,
<https://blogs.technet.microsoft.com/srd/2010/08/31/an-update-on-the-dll-preloading-remote-attack-vector/>,
<https://support.microsoft.com/en-us/kb/2264107> und
<http://www.binaryplanting.com/> sollte sie JEDER Windows-Programmierer
kennen.

Ebenso wohlbekannt und wohldokumentiert ist, dass das Anwendungsverzeichnis
an erster Stelle im Suchpfad steht.
Siehe <https://msdn.microsoft.com/en-us/library/ff919712.aspx>,
<https://msdn.microsoft.com/en-us/library/ms682586.aspx>,
<https://technet.microsoft.com/en-us/library/2269637.aspx>,
<https://support.microsoft.com/en-us/kb/2389418>,
<https://support.microsoft.com/en-us/kb/2533623> und
<https://blogs.technet.microsoft.com/srd/2014/05/13/load-library-safely/>
plus
<https://insights.sei.cmu.edu/cert/2016/06/bypassing-application-whitelisting.html>

Bei INSTALLIERTEN Programmen ist das Anwendungsverzeichnis sicher, bei
Installations-Programmen dagegen (typischerweise) NICHT!
Fuer letzteres siehe <http://seclists.org/bugtraq/2016/Jul/110> alias
<http://seclists.org/fulldisclosure/2016/Jul/63> sowie
<http://seclists.org/fulldisclosure/2017/Jun/34> und dessen FUENFZIG
Vorgaenger.
Findest Du CVE-2010-3190, CVE-2014-0315, CVE-2015-8264, CVE-2016-0014,
CVE-2016-0602, CVE-2016-0603, CVE-2016-1014, CVE-2016-1281, CVE-2016-1742,
CVE-2016-4247, CVE-2016-6804, CVE-2016-7085, CVE-2016-1000331,
CVE-2016-1000332, CVE-2016-7804, CVE-2017-2107 und CVE-2017-5688 selbst?
Oder <https://cwe.mitre.org/data/definitions/377.html> und
<https://cwe.mitre.org/data/definitions/379.html>?

Post by Edzard Egberts
Das ist doch einfach nur ein Komplettversagen des Betriebssystems und
nur deshalb ein Problem, weil MS so etwas eben auf die Anwender abwälzt.

Es ist DOKUMENTIERTES Verhalten, das Programmierer beachten MUESSEN und
beeinflussen KOENNEN: <https://skanthak.homepage.t-online.de/!execute.html>
beschreibt letzteres, auch fuer Dich!
Unter <https://skanthak.homepage.t-online.de/sentinel.html> und
<https://skanthak.homepage.t-online.de/verifier.html> findest Du mehr.

Post by Edzard Egberts
An "WannaCry" ist inzwischen ja auch die NSA schuld (weil die die Lücke
nicht veröffentlich haben) und nicht MS (obwohl die die Lücke programmiert
haben)... :o/

Falsch.
Microsoft hat diesen Fehler NICHT mit Absicht eingebaut; die NSA dagegen
hat den Fehler mit ABSICHT ausgenutzt und mit ABSICHT nicht an Microsoft
gemeldet. Anschliessend war die NSA unfaehig, ihre "Waffen" zu sichern.

Von WannaCry betroffen sind nur Leute, die ihre Systeme nicht ordentlich
warten: nach Veroeffentlichung der Luecke durch die "Shadow Brokers" war
voellig klar, dass diese ausgenutzt werden wuerde.

Microsoft hat die Korrektur VOR dieser Veroeffentlichung herausgegeben,
zwei Monate bevor WannaCry in Umlauf gebracht wurde.
Microsoft empfiehlt schon ETWAS laenger, SMB/CIFS nicht ueber's Internet
freizugeben, sowie SMB1 abzuschalten.

Stefan
[

Edzard Egberts

2017-07-04 06:24:25 UTC

Post by Stefan Kanthak
Dann informiere Dich ENDLICH ueber die Funktionsweise und die
daraus resultierenden Schwachstellen des von Dir missbrauchten
OS: eine GANZE Reihe von Sicherheitsluecken baust Du durch
Ignoranz in Deine Programme ein.

Aha und in dem Zustand könnte das Windows "geentert" werden.

Post by Edzard Egberts
Warum soll es das Problem des Programmierers sein, wenn ein
Programm ohne sicherheitsrelevante Funktionen, das ganz normal mit
Userrechten läuft, irgendwelche Sicherheitslücken erzeugen kann?

Stimmt, bei Linux geht das nicht - Du meinst MS versäumt es seit 20
Jahren, diese Lücke zu schließen?

Post by Stefan Kanthak
Spaetestens nach <http://www.guninski.com/officedll.html> alias

Doppelclick auf Anhänge? Der Klassiker, eine der schlimmsten Sachen, die
MS jemals verbockt hat, aber ist ja soooo bequem und den Ärger hat
sowieso nur der User, der es ja sooo bequem haben muss. Jetzt alle eine
Runde Mitleid?

<snip>

Das ist alles so viel, ich arbeite hier nicht für MS, weißt Du. Und
entschuldige bitte, so viel Mühe solltest Du Dir wirklich nicht machen!
Ich will ja gar nicht mehr für diese Plattform entwickeln und das Ende
ist langsam in Sicht. :o)

Ich bin aber trotzdem einigen Links nachgegangen und habe sogar die
MSI-Beschreibung von Microsoft gefunden - ist ja recht detailliert.
Bei der Wikipedia sind mir aber wieder die Gesichtszüge entgleist:

"Es gibt Hersteller, die Editoren für MSI-Dateien bereithalten, wie z.
B. Flexera Software mit dem Produkt InstallShield. Weitere Produkte sind
Advanced Installer von Caphyon, Wise Installer von Symantec,
AKInstallerMSI von AKApplications und InstallAware von InstallAware
Software Corporation. Auch die Entwicklungsumgebungen Visual Studio (ab
Version 2002) von Microsoft erlauben im begrenzten Umfang die Erstellung
von Windows-Installer-Paketen."

Also weißt Du, so wichtig kann das gar nicht sein, wenn Microsoft selber
es nicht nötig hat, für so etwas Systemwerkzeuge bereit zu stellen. Man
soll sich also ein Produkt kaufen, damit die Windows-Installation sicher
ist? War ja klar, geht nicht um Sicherheit, sondern nur um die Kohle.

Post by Edzard Egberts
An "WannaCry" ist inzwischen ja auch die NSA schuld (weil die die
Lücke nicht veröffentlich haben) und nicht MS (obwohl die die Lücke
programmiert haben)... :o/

Falsch. Microsoft hat diesen Fehler NICHT mit Absicht eingebaut;

Ach ja, der eiserne Rechtsgrundsatz, dass man nur für absichtliche
Fehler haften muss! Finde ich gut, sonst könnte man auch keine
Atomkraftwerke mit Rissen im Containment betreiben, wie das in
Flamanville geplant ist.

Post by Stefan Kanthak
Microsoft hat die Korrektur VOR dieser Veroeffentlichung
herausgegeben, zwei Monate bevor WannaCry in Umlauf gebracht wurde.

Danach haben sie sogar ein Update für XP herausgegeben, weil es
scheinbar nicht richtig geklappt hat, zigtausend Rechner zu bricken,
damit die Leute endlich eine neue Windows-Version kaufen.

Stefan Kanthak

2017-07-04 15:51:52 UTC

[...]

Post by Stefan Kanthak
Hierzufred geht's NICHT um triviale (und in SICHEREN Verzeichnissen
installierte) Programme, sondern um Installations-Programme, die
typischerweise mit Administratorrechten laufen und in UNSICHEREN
Verzeichnissen gestartet werden.

Aha und in dem Zustand könnte das Windows "geentert" werden.

Nicht Windows, sondern das DEFEKTE Installationsprogramm!

Post by Edzard Egberts
Warum soll es das Problem des Programmierers sein, wenn ein
Programm ohne sicherheitsrelevante Funktionen, das ganz normal mit
Userrechten läuft, irgendwelche Sicherheitslücken erzeugen kann?

Stimmt, bei Linux geht das nicht

Wie ueblich: AHNUNGSLOSER DUMMSCHWATZ!
Selbstverstaendlich geht das bei Linux und UNIX: dort kann JEDER Benutzer
export PATH=.:$PATH
ausfuehren!

Post by Edzard Egberts
- Du meinst MS versäumt es seit 20 Jahren, diese Lücke zu schließen?

Nein. LIES ENDLICH DIE VERLINKTE DOKUMENTATION!

Post by Stefan Kanthak
Spaetestens nach <http://www.guninski.com/officedll.html> alias

Doppelclick auf Anhänge?

Wieder falsch: Doppelklick auf beliebige Dateien.
Genau wie in JEDER grafischen Oberflaeche anderer Betruebssysteme!

JFTR: bevor Du jetzt wieder ahnungslos "mit *x waer das nicht passiert"
herumpupst:
<https://www.google.de/search?num=100&newwindow=1&q=patrick+wardle+dll+hijacking>

[ Dummschwatz entsorgt ]

Post by Edzard Egberts
Ich bin aber trotzdem einigen Links nachgegangen und habe sogar die
MSI-Beschreibung von Microsoft gefunden - ist ja recht detailliert.

[...]

Post by Edzard Egberts
Also weißt Du, so wichtig kann das gar nicht sein, wenn Microsoft selber
es nicht nötig hat, für so etwas Systemwerkzeuge bereit zu stellen.

Wie ueblich: AHNUNGSLOSER DUMMSCHWATZ!
Microsoft stellt seit dem letzten Jahrtausend Systemwerkzeuge zum Bauen
und Umbauen von *.MSI, *.MSP und *.MST bereit: die findest auch Du in
den kostenlosen "Software Development Kits" fuer Windows!

Wie waer's, Du lernst ENDLICH, selbst zu recherchieren, statt Dummschwatz
der Wikipedia zum Schlechtesten zu geben?

Post by Edzard Egberts
Man soll sich also ein Produkt kaufen, damit die Windows-Installation
sicher ist? War ja klar, geht nicht um Sicherheit, sondern nur um die
Kohle.

Wie ueblich: AHNUNGSLOSER DUMMSCHWATZ!
Es existieren mehrere kostenlose und "open source" MSI-Editoren!

Stefan
[

Stefan Kanthak

2017-06-30 22:01:36 UTC

Post by Matthias Hanft
Hallo,
ich liefere meine eigene Software per InstallShield-Setup-Paket an
den Anwender aus.

AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design und
ALLE kaputt: siehe
<https://skanthak.homepage.t-online.de/~execute.html>

http://skanthak.homepage.t-online.de/!execute.html
Echt jetzt, das muss man alles beachten, um irgend ein Programm auf
Windows zu installieren?

Nein. Das musst Du nur beachten, wenn Du Installationspakete OHNE
triviale Anfaengerfehler bauen willst.

Post by Edzard Egberts
Ist ja wohl eine Zumutung!

Falsch: MINIMAL ART!
Weniger ist UNSICHER!
JFTR: niemand zwingt Dich, kaputte Software fuer Windows zu verbrechen!

AUTSCH! Dort werden sie von Windows Update nicht entdeckt und nicht
aktualisiert; siehe <https://support.microsoft.com/kb/835322>

Garantiert mir Microsoft, dass so eine Aktualisierung mein Programm
nicht kaputt macht?

Laut Microsoft sind MSVCRT abwaertskompatibel; falls nicht haben sie
einen Fehler gemacht, den sie wiederum laut eigener Aussage kostenlos
korrigieren.

[...]

Durch Bauen eines *.MSI

Warum macht MS selber das nicht, sondern gibt den vcredist-Krempel als
"Executable installer" heraus?

Weil die linke Hand des Teufels nicht weiss was die rechte macht!

Post by Edzard Egberts
Du willst uns doch veräppeln! ;o)

Nur Ru^Hosse taeuschen!

Stefan
[

Edzard Egberts

2017-07-03 06:28:03 UTC

Post by Matthias Hanft
ich liefere meine eigene Software per InstallShield-Setup-Paket
an den Anwender aus.

AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design
und ALLE kaputt: siehe
<https://skanthak.homepage.t-online.de/~execute.html>

http://skanthak.homepage.t-online.de/!execute.html
Echt jetzt, das muss man alles beachten, um irgend ein Programm
auf Windows zu installieren?

Nein. Das musst Du nur beachten, wenn Du Installationspakete OHNE
triviale Anfaengerfehler bauen willst.

Gibt es da denn kein schrittweises HowTo oder gar einen Assistenten? Für
jeden popeligen Scheiß, wo man zwei oder drei Häkchen setzen müsste,
gibt es doch einen - warum ist so eine wichtige Sache so unsinnig
kompliziert?

Post by Edzard Egberts
Garantiert mir Microsoft, dass so eine Aktualisierung mein
Programm nicht kaputt macht?

Laut Microsoft sind MSVCRT abwaertskompatibel; falls nicht haben sie
einen Fehler gemacht, den sie wiederum laut eigener Aussage
kostenlos korrigieren.

Würde ich auch sagen, wo finde ich diese Garantie? Meiner Erfahrung
nach, steht man dann einfach im Regen und muss sehen, wo man bleibt.
Oder man hat sich gerade ein schönes neues Vista gekauft und muss direkt
ein Downgrade machen... ;o)

Stefan Kanthak

2017-07-03 11:56:17 UTC

Post by Matthias Hanft
ich liefere meine eigene Software per InstallShield-Setup-Paket
an den Anwender aus.

AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design
und ALLE kaputt: siehe
<https://skanthak.homepage.t-online.de/~execute.html>

http://skanthak.homepage.t-online.de/!execute.html
Echt jetzt, das muss man alles beachten, um irgend ein Programm
auf Windows zu installieren?

Nein. Das musst Du nur beachten, wenn Du Installationspakete OHNE
triviale Anfaengerfehler bauen willst.

Gibt es da denn kein schrittweises HowTo oder gar einen Assistenten?

Wozu?
InstallationsPROGRAMME sind Mist, da sie von unbedarften Benutzern in
UNSICHERER Umgebung ausgefuehrt werden.

JFTR: Installationsprogramme sind keine Benutzerprogramme, sondern
SYSTEM-Programme.

JEDES Betruebssystem kennt mindestens ein NATIVES Format fuer
NICHT-ausfuehrbare Installationspakete und bringt alles Notwendige mit,
um diese Pakete SICHER zu installieren.
Bei Windows ist das seit ueber 20 Jahren das SetupAPI, das (in *.CAB
eingepackte und komprimierte) Dateien per *.INF installiert; seit dem
letzten Jahrtausend gibt's ausserdem den Windows Installer, der *.MSI
in EINER Transaktion installiert.

Post by Edzard Egberts
Für jeden popeligen Scheiß, wo man zwei oder drei Häkchen setzen müsste,
gibt es doch einen - warum ist so eine wichtige Sache so unsinnig
kompliziert?

Wer InstallationsPROGRAMME verbricht hat sein OS nicht kapiert!
Bau ein Installationspaket in dem vom OS unterstuetzten Paketformat.