Beiträge

Flashplayer – eigener interner Update Service

flash-logoDie 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.

Flashplayer silent deinstallieren

Trotz dem netzwerkinternen Flashupdateservice, der das Patchen des Flashplayers nebenher automatisch erledigt, ist es an der Zeit sich von diesem Stück Software zu trennen. Auf allen Unternehmensrechnern fliegt der Flashplayer runter. Wie nur automatisieren?

Auf dieser Adobe Website findet sich ein passender Uninstaller. Der läßt sich mittels Parameter aufrufen, sodaß der Flashplayer unbemerkt im Hintergrund vom Rechner geräumt wird.

uninstall_flash_player.exe -uninstall

lautet die schlichte Syntax. Sehr effektiv.

Dieses läßt sich mittels aller möglichen Softwareverteilmechanismen ausrollen. Ein Beispeil für ein OCS Paket sieht bspw. so aus:

uninstall_flash_player.exe packen in uninstall_flash_player.zip und in ein neues Paket hochladen.

ocs_flashplayer_uninstall

Fehler beim Öffnen einer PDF-Datei per Doppleklick mit Adobe Reader X

Was es nicht alles gibt. Ein User meldet eine Fehlermeldung beim Öffnen eines PDFs.

„Before processing you must first launch Adobe Acrobat and accept the End User License Agreement.“

Andere PDFs lassen sie problemlos öffen. Auch dieses eine vermeintlich fehlerhafte Dokument läßt sich per Datei öffnen Dialog fehlerfrei öffnen. Nach kurzer Recherche (Gottseidank ist man mit solchen Problem selten allein) stellt sich ein kurioser Bug im Adobe Reader heraus. Wenn das PDF-Dokument die Buchstabenkombination CR im Dateinamen enthält, kommt es zu o.g. Fehler. Umbenennen hilft.