Flashplayer – eigener interner Update Service
Die Anzahl gefährlicher Sicherheitsücken im Flashplayer zwingt Hersteller Adobe immer wieder, selbst zwischen den festgelegten Patchdays, Korrekturen für den Flashplayer zu veröffentlichen. Um diese schnellstmöglichst weitgehend automatisiert auszurollen, nutz(t)e ich für die Updates auf den Rechnern im Unternehmen die Funktion des Flashplayers, einen internen Webserver ansprechen zu können. In diversen Anleitungen und Dokus seitens Adobe wird dieses Szenario mehr oder weniger (eigentlich eher weniger) ausführlich beschrieben. Darum bereite ich das hier mal etwas auf.
Konfiguration des Flashplayers:
Der Flashplayer läßt sich mittels einer lokalen Konfigurationsdatei namens mms.cfg konfigurieren. Diese Datei befindet sich, je nach Ausführung des Flashplayers und der Windowsversion, ob 32 oder 64 bit , im Verzeichnis C:\Windows\SysWOW64\Macromed\Flash\mms.cfg (32 bit Flashplayer auf 64 bit Windows) oder C:\Windows\System32\Macromed\Flash\mms.cfg (64 bit Flashplayer oder 32 bit Flashplayer auf 32 bit Windows). Ist sie nicht vorhanden, kann man sie mittels Texteditor erstellen.
Folgende Parameter gehören in die Datei:
AutoUpdateDisable=0 SilentAutoUpdateEnable=1 SilentAutoUpdateServerDomain=Updateservername
AutoUpdateDisable setzt man auf 0 und aktiviert somit AutoUpdate. SilentAutoUpdateEnable bedeutet dem Updatedienst, seine Dienste unauffällig im Hintergrund zu erledigen, SilentAutoUpdateServerDomain betitelt schließlich den Server, auf welchem der Updatedienst nach Updates suchen soll. Dieser letzte Eintrag ist wichtig im Hinblick auf die folgende Beschreibung des Webservices.
Ein vorhandener Webserver stellt in einem fest von Adobe vorgegebenen Pfad die Dateien für das Update des Flashplayers zur Verfügung. Der Client spricht zwingend per https mit dem Webserver was bei der Einrichtung etwas mehr Aufwand wg. einem vertrauenswürdigen Zertifikat mit sich bringt (Sofern keine eigene CA im Einsatz, ggf. selbst signiert und über AD auf die Clients verteilt, es darf beim Aufruf der Serveradressen KEIN ssl Fehler auftreten).
Im Webrootverzeichnis muss folgender Ordnerpfad angelegt werden:
/pub/flashplayer/update/current/sau
Ein Aufruf mittels Browser sollte keine Fehlermeldung (auch keinen SSL-Fehler) produzieren:
https://Updateservername/pub/flashplayer/update/current/sau
In diesen Ordner muss nun ein Updatepaket von Adobe entpackt werden. Adobe verteilt es über die Seite https://www.adobe.com/de/products/flashplayer/distribution3.html und nennt das Paket dort „Ressourcen für Updates im Hintergrund herunterladen“. Gemeint ist das .cab Archiv fp_background_update.cab. Diese Datei lädt man also herunter, entpackt sie und lädt die entpackten Daten dann samt Unterordnerstruktur in o.g. Pfad. Die Pfadstruktur sieht dann in etwa so aus (Stand Nov. 2015, Versionen variieren):
https://Updateservername/pub/flashplayer/update/current/sau/currentmajor.xml https://Updateservername/pub/flashplayer/update/current/sau/11/install/install_all_mac_pl_sgn.z https://Updateservername/pub/flashplayer/update/current/sau/11/install/install_all_win_ax_sgn.z https://Updateservername/pub/flashplayer/update/current/sau/11/install/install_all_win_pl_sgn.z https://Updateservername/pub/flashplayer/update/current/sau/11/xml/version.xml https://Updateservername/pub/flashplayer/update/current/sau/18/install/install_all_win_ax_sgn.z https://Updateservername/pub/flashplayer/update/current/sau/18/install/install_all_win_pl_sgn.z https://Updateservername/pub/flashplayer/update/current/sau/18/xml/version.xml https://Updateservername/pub/flashplayer/update/current/sau/19/install/install_all_win_ax_sgn.z https://Updateservername/pub/flashplayer/update/current/sau/19/install/install_all_win_pl_sgn.z https://Updateservername/pub/flashplayer/update/current/sau/19/xml/version.xml
Der Webserver läuft bei mir auf einer vorhandenen Ubuntu VM mit. Ein Shellscript prüft jede Nacht ob eine neue Updatedatei (fp_background_update.cab) bei Adobe zum Download bereit liegt. Das erledigt das Tools wget mit der Option –spider welche Dateien nicht herunterlädt sondern nur deren Existenz überprüft. Das Ergebnis wird nach dem String „Last-Modified“ geparst und eigentlich wird nicht das Datum sondern nur der Ergebnisstring verglichen. Das reicht aber aus um festzustellen, daß sich etwas an der Datei geändert hat. Ist dies der Fall, wird diese heruntergeladen, entpackt und ersetzt die alten Dateien auf dem Webserver.
Mein Script downloadflash.sh welches jede Nacht ausgeführt wird:
#!/bin/bash
#
# Update der Adobe Flashkomponenten fuer internen Update Service
# Die Fortschrittsanzeige beim Download, für Testzwecke , stammt von:
# http://fitnr.com/showing-file-download-progress-using-wget.html
#
# 02.11.2015, kw
#
#aktuelles Datum
currentDate= date
#Logfile
log=/flashupdate/update.log
#Downloadfunktion zeigt einen prozentualen Downloadfortschritt an
download()
{
local url=$1
local targ=$2
echo -n " "
wget --progress=dot $url -O $targ 2>&1 | grep --line-buffered "%" | \
sed -u -e "s,\.,,g" | awk '{printf("\b\b\b\b%4s", $2)}'
echo -ne "\b\b\b\b"
echo " DONE"
}
#Pruefung aktueller Status der Updatedatei und Bindung an Variable $adobecabdate -> Suche (grep) nach "Last Modified" -> xargs entfernt ggf. Leerzeichen/Tabs vor und nach String
adobecabdate=$(wget --server-response --spider http://download.macromedia.com/pub/flashplayer/current/licensing/win/fp_background_update.cab 2>&1 |grep Last-Modified | xargs)
#Prüfung aktueller Status der Updatedatei auf dem lokalen Server und Bindung an Variable $localcabdate
localcabdate=$(wget --server-response --spider http://localhost/pub/flashplayer/update/current/sau/fp_background_update.cab 2>&1 |grep Last-Modified | xargs)
# Zugriff Logfile
touch $log
# Vergleich letzter Status gg. aktueller Status. Wenn gleich, Scriptende. Wenn nicht gleich, Download.
if [ "$adobecabdate" = "$localcabdate" ]
then
echo $currentDate >>$log 2>1
echo "Aktueller Wert Adobe: " $adobecabdate " - Letzer Wert lokal: " $localcabdate >>$log 2>1
echo "Keine neue Version." >>$log 2>&1
exit 1
else
# Zielordner bereinigen
echo $currentDate >>$log 2>1
echo "Aktueller Wert Adobe: " $adobecabdate " - Letzer Wert lokal: " $localcabdate >>$log 2>1
echo "Neue Version Adobe: " $adobecabdate >>$log 2>&1
echo "Zielordner bereinigen" >>$log 2>&1
rm -rf /var/www/html/pub/flashplayer/update/current/sau/* >>$log 2>&1
download http://download.macromedia.com/pub/flashplayer/current/licensing/win/fp_background_update.cab /var/www/html/pub/flashplayer/update/current/sau/fp_background_update.cab
fi
# Datei entpacken (-d = Zielverzeichnis)
cabextract -d /var/www/html/pub/flashplayer/update/current/sau/ /var/www/html/pub/flashplayer/update/current/sau/fp_background_update.cab >>$log 2>1
Und damit wars das auch schon mit der Konfiguration. Ein simpler https erreichbarer Webspace genügt um dem Flashplayer mittels einer Konfigdatei das leise Updaten über einen internen Server zu vermitteln. Das macht dann Sinn, wenn die Clients nicht ungezügelt externe Updatedienste im Internet kontaktieren sollen oder dürfen.
Stolpersteine:
Es gibt für dieses Szenario ein paar kleine Hürden.
Wie konfiguriere ich den Webserver bzw. die Clients für den fehlerfreien https Zugriff .
Eine hilfreiche Anleitung, wie man selbstsignierte Zertifikate erstellt und auch verteilt bietet dieser Artikel von Mark Heidbrink auf faq-o-matic.net. Wichtig hierbei ist, daß der gewählte Common Name (CN) für das Zertifikat dem Wert von SilentAutoUpdateServerDomain aus der mms.cfg entspricht. Erstellt man ein Zertifikat mittels selfcert, gehört dieses auf jedem PC in den Speicher für Vertrauenswürdige Stammzertifizierungsstellen. Darum bietet sich ein Rollout per Gruppenrichtlinie an.
Wie bekomme ich die Datei mms.cfg auf die Clients
Die mms.cfg kann man manuell, per Loginscript oder bspw. Clientmanagement, in meinem Fall OCS Inventory, auf die Clients kopieren.
Wie zwinge ich den Flashplayer JETZT ein Update zu suchen.
Zum Update des Flashplayers wird zusammen mit diesem ein Dienst namens „Adobe Flash Player Update Service“ installiert. Dieser steht auf Startart Manuell und ist beendet. Startet man ihn von Hand, beendet er sich augenblicklich wieder. Dieser Dienst startet standardmäßig jede Stunde. Dabei prüft er aber nicht, ob ein Update vorliegt sondern er prüft nur ob es mal wieder an der Zeit ist, nach neuen Updates zu suchen. Ich meine irgendwo gelesen zu haben, daß er erst nach mind 24 Std. seit dem letzten Update erneut nach Updates sucht. Daher verbraucht der Dienst sehr wenig Resourcen. Er prüft lediglich anhand eines Zeitstempels in der Registry ob die Zeit für eine neue Updatesuche gekommen ist.
Um nun nach der Einrichtung oder bei einer evtl. Fehlersuche den Flashplayer Update Service zum Update zu zwingen, genügt es, den Wert des Registrykeys
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Macromedia\FlashPlayerSAU\LastUpdateCheck
zu löschen (32 bit Flashplayer auf 64 bit Win). Wenn man anschließend den Update Service einmal von Hand startet, lößt dieser eine echte Updatesuche aus.
Hi Kai,
ich patche bei uns den Flash Kram über den WSUS mit.
Die Pakete lassen sich mit dem WPP sehr einfach integrieren.
http://wsuspackagepublisher.codeplex.com/
Wie man diesen einrichtet – ist hier schön beschrieben:
http://www.gruppenrichtlinien.de/artikel/wsus-package-publisher-software-ueber-windows-server-update-service-bereitstellen/
MfG
Denis
Hi,
ich habe versucht, die hier dargestellte Lösung auf Microsoft IIS und das Script zu PowerShell zu migrieren. Nun scheitert es aber dabei, dass der Update Service versucht, aus der geladenen und entpackten .cab Datei eine Patch.xml herunterzuladen, die auf dem Webserver nicht vorhanden ist.
Hat jemand eine Idee, woran das liegt und welche Bewandnis die Patch.xml Datei hat?
Ansonsten ein sehr schöner Artikel 😉
Ich glaube in früheren Versionen wurde die patch.xml verwendet. Ich vermute aus Abwärtskompatibilitätsgründen wird die vielleicht noch abgefragt. Habe gerade mal im ssl_log nachgeschaut. Der Aufruft taucht hier auch regelmäßig mit 404 auf. Denke, das kann man ignorieren.
Ich habe auch ein Powershellscript erstellt um das ganze auf einem Windowsserver umzusetzen. Allerdings ist es noch nicht ganz fertig (Fehlerbehandlung etc). Das reiche ich demnächst mal nach.
Hi,
vielen Dank für den tollen Artikel.
Frage, wäre es nicht eigentlich sinniger, das Entpacken im Script nur dann auszuführen, wenn es eine neue Version gibt?
Weiter bekomme ich unter Ubuntu immer folgende Ausgabe zu Anfang:
��#!/bin/bash
Eine Idee was das sein kann?
Die Ausgabe „echo „Keine neue Version.“ >>$log 2>&1″ wird ignoriert und er läuft automatisch zur Zeile 56 dem Entpacken per cabextract.
Hier mal der Auszug:
Aktueller Wert Adobe: Last-Modified: Fri, 01 Jan 2016 23:33:26 GMT – Letzer Wert lokal:
Neue Version Adobe: Last-Modified: Fri, 01 Jan 2016 23:33:26 GMT
Zielordner bereinigen
Extracting cabinet: /var/www/flashplayer/pub/flashplayer/update/current/sau/fp_background_update.cab
extracting /var/www/flashplayer/pub/flashplayer/update/current/sau//currentmajor.xml
extracting /var/www/flashplayer/pub/flashplayer/update/current/sau//11/install/install_all_mac_pl_sgn.z
extracting /var/www/flashplayer/pub/flashplayer/update/current/sau//11/install/install_all_win_pl_sgn.z
extracting /var/www/flashplayer/pub/flashplayer/update/current/sau//11/install/install_all_win_ax_sgn.z
extracting /var/www/flashplayer/pub/flashplayer/update/current/sau//11/xml/version.xml
extracting /var/www/flashplayer/pub/flashplayer/update/current/sau//19/install/install_all_win_pl_sgn.z
extracting /var/www/flashplayer/pub/flashplayer/update/current/sau//19/install/install_all_win_ax_sgn.z
extracting /var/www/flashplayer/pub/flashplayer/update/current/sau//19/xml/version.xml
extracting /var/www/flashplayer/pub/flashplayer/update/current/sau//20/install/install_all_win_pl_sgn.z
extracting /var/www/flashplayer/pub/flashplayer/update/current/sau//20/install/install_all_win_ax_sgn.z
extracting /var/www/flashplayer/pub/flashplayer/update/current/sau//20/xml/version.xml
All done, no errors.
Danke für die Hilfe und beste Grüße
Helge Lehmann
Ergänzung:
So, habe noch einmal alles in Einzelschritten gestartet. Es wird immer ein Download gestartet, obwohl das Datum ja eigentlich identisch ist.
Hallo Helge,
wie es aussieht ist die Variable $localcabdate bei Dir leer. Es klappt also scheinbar nicht die Abfrage der lokalen Datei. Das ist beim ersten mal auch ok. Ab dann sollte die heruntergeladene Datei aber dort liegen und bei der nächsten Abfrage erkannt werden. Du kannst ja mal die Zeile 31 localcabdate=…. in die console kopieren und hinterher mit echo $localcabdate den Wert anzeigen. Klappt das? Befindet sich der Server ggf. hinter einem Proxy? Bei meinem Server ist bspw standardmäßig wget mit Proxy konfiguriert. Im Script setze ich dann aber eine Ausnahme für localhost. Dafür in die leer Zeile 29 folgendes eintragen: export no_proxy=localhost
Aber wie gesagt, nur für denn Fall, daß Du standardmäßig einen Proxy nutzt.
Beste Grüße
Kai
Zum Fix des bin/bash noct found:
root@servername:/home/administrator# dos2unix downloadflash.sh
dos2unix: Datei downloadflash.sh wird ins Unix-Format umgewandelt …
Dann der neue Output:
root@servername:/home/administrator# sh downloadflash.sh
Do 21. Jan 09:03:57 CET 2016 100 %-ne
DONE
root@servername:/home/administrator#
Du kannst auch gerne die Kommentare löschen von vorher 😉
Und müsste es in der Zeile 23:
echo -ne „\b\b\b\b“
nicht wie in Zeile 20 lauten:
echo -n “ „
Hi,
und die Zeile 11 sollte angepasst werden:
currentDate=$(date)
Den Downloadprogress habe ich nur kopiert (siehe scriptheader). Für den normalen Betrieb ist der eigentlich gar nicht notwendig weil man das ja automatisiert laufen lässt und die Console interessiert der Downloadfortschritt vermutlich eher weniger. 😉
Ich bekomme da einen Fehler und die Datumsprüfung funktioniert dann nicht mehr.