Updatemechanismus... Prinzipielle Bedenken? [==> Ja]

Hi!
Folgenden Updatemechanismus habe ich In C# umgesetzt. Gibt es prinzipielle Bedenken? Gibt es da eine andere simple Lösung?

1. in der Anwendung einen neuen Thread starten:
2. eine Textdatei runterladen welche die neuste Version auf dem Server angibt
3. Version aus der Textdatei mit der Version der lokalen Anwendung vergleichen, wenn unterschiedlich:
4. neue Version runterladen (nach "temp")
5. lokale Anwendung während der Laufzeit nach "temp2" verschieben (geht)
6. update.bat erstellen welche die neue Version ins aktuelle Verzeichnis kopieren soll ("MOVE ...")
7. die .bat nach Beenden der Anwendung starten ( Process.Start(update.bat); Appliation.Exit(666); )
8. beim Start der Anwendung "temp2", update.bat und die Textdatei löschen

Hi,

schöner Fall für die Forensuche:

Gugg mal unter Projekte

Gruß
Achim

Hallo userid9077,

das geht prinzipiell so.

Statt nach "temp2" zu verschieben könnte man die Datei auch umbenennen, dann braucht der Anwender keine Berechtigung im Verz. temp2.

Anstatt Batchdatei kann sich eine Applikation nach dem kopieren der neuen Version auch selbst neu starten.

Leider klappt deine Lösung nicht auf Windows 7, wenn die Exe mehrfach gestartet ist, oder wenn die Exe auf einer Netzwerkfreigabe liegt und noch von anderen Usern in Benutzung ist.

In diesem Fall müsste eine Meldung kommen "Alle Benutzer müssen das Programm ... verlassen".

Grüße Bernd

Hallo userid9077,

automatische Updates sind schwer in Mode. Ich bin allerdings überhaupt kein Freund davon.

Ich nutze viele Programme, die bewusst nicht auf der aktuellen Version sind, weil die aktuelle Version mehr Fehler enthält, als die alte; die Benutzeroberfläche sich zum schlechten geändert hat; Funktionen, die mir wichtig sind, entfallen sind; störendes Verhalten hinzugekommen ist und ähnliches mehr.

Über automatische reine Sicherheitsupdates, die nichts an Oberfläche und Funktionalität der Software ändert, könnte man natürlich nachdenken, denn natürlich könn(t)en ältere Versionen mehr Sicherheitslücken enthalten als neuere, aber was m.E. vollkommen übersehen wird, sind die Sicherheitslücken, die durch eine Update-Funktion entstehen können.

Immerhin wird durch eine Update-Funktion ein ausführbares Programm auf die Platte gebracht, das dann üblicherweise sogar sofort und automatisch gestartet wird. Ein Traum für jeden, der Schadsoftware auf Rechner bringen möchte!

Er könnte sich z.B. in die Kommunikation beim Update-Prozess einklinken. Das ist zwar nicht ganz trivial, kann sich aber bei verbreiteten Programmen (und bei einem attraktiven Ziel sogar für wenig verbreitete Spezialanwendungen) durchaus lohnen. Ein Ansatz wäre, durch DNS-Spoofing die Zugriffe des Programms auf den Update-Server auf einen eigenen Server umzuleiten. Spätestens wenn beim Update-Prozess ohne Signaturen gearbeitet wird, kann der Angreifer dann eine beliebige EXE an den Zielrechner schicken ... boom.

Aber selbst wenn mit Signaturen gearbeitet wird, heißt das nicht, dass alles sicher ist, wie die Sicherheitslücken bei der Personalausweisapp gezeigt haben. Wenn man bei der Programmierung nicht ganz genau weiß, was man tut und außerdem nicht höllisch genau aufpasst, wird es trotz Signierung möglich sein, Schadcode auf den Zielrechner zu bringen und auszuführen.

Aber selbst wenn man ganz genau aufgepasst hat, Signaturen verwendet und die Update-Funktion auch sonst sicher programmiert ist, kann immer noch der Update-Server selbst kompromittiert werden. Dann stellt der Angreifer seinen Schadcode direkt und korrekt signiert auf die Original-Update-Server. Und kein Server ist so sicher, dass er nicht kompromittiert werden kann. Der erfolgreiche Angriff auf die Server der Sicherheitsfirma RSA und die dort entwendeten hochbrisanten Zertifikate zeigen, was ich meine.

Natürlich kann man sagen, wenn der Update-Server kompromittiert wird, dann kann auch der normale Download-Server kompromittiert werden. Nehmen wir mal an, die kompromittieren Server wären beide einen Tag online, bevor die Kompromittierung bemerkt und die Server vom Netz genommen werden. Beim Download-Server wären nur die Personen betroffen, die die Software neu heruntergeladen haben, entweder als Neukunden/Neuuser oder um manuell ein Update vorzunehmen. Das ist vielleicht ein Promille der Nutzerbasis, wenn es hoch kommt. Bei einem (stillschweigenden) automatischen Update wäre aber im schlimmsten Fall die gesamte bestehende Nutzerbasis betroffen.

In deinem Prozess ist ist nicht mal von Signaturen die Rede. Insofern bestehen also begründete schwere prinzipielle Bedenken.

herbivore

Suchhilfe: 1000 Worte, automatisches Update, Updater, Software-Aktualisierung

Hallo!

Bzgl. automatischer Updates evtl. noch einige zusätzliche Anmerkungen:

Erstmal wollen viele User einfach nur wissen, ob was geändert wird. Im schlimmsten Fall geht die Anwendung nach einem stillen Update nicht mehr, und der User weis nicht wraum.
Zudem war in einer der letzten c't-Editorale eine nette Geschichte von einem Redakteur, welcher eben nur schnell eine e-Mail lesen, anschließend etwas im Internet nachschlagen und daraufhin ein Dokument anpassen wollte.
Wenn nun in allen drei Fällen die Software zunächst ein Update einspielen will bzw. es einfach tut (wie dies z.B. TB und FF so machen), kann das ziemlich nervig werden.
Das ist zwar ein extremes Beispiel, aber man sollte bei Updates immer die Möglichkeit bieten, diese zu einem späteren Zeitpunkt installieren zu können.

Und um herbivores Beitrag aufzugreifen: Ideal wäre die Anzeige (wie z.B. bei MS/Windows), ob das Update sicherheitsrelevant ist und/oder was an der Funktionalität/UI angepasst wurde.

Dake für die Antworten.
Besonders an Herbivore für die ausführliche Antwort.

Ich werde mir mal Signaturen angucken um wenigstens etwas an Sicherheit zu bekommen.
Was den Automatismus von Updats angeht werde ich mal überlegen wie ich das mache.