11
Java JRE Sicherheitsbetrachtung auf Windows Clients
Aloa in die Runde,
in der Regel sind doch alle EXE Dateien die man starten kann exploitbar, wenn dort Sicherheitslücken noch nicht gepatched wurden oder?
Da ist doch am Ende der Kampf gegen Windmühlen aussichtslos, wenn man die verteilte und installierte JRE auf dem aktuellen Patchlevel hält und auf der restlichen Wiese 100 verschiedene eingebettete JREs rumschwirren von 11- runter zur Version 5.
Wie kritisch betrachtet Ihr Anwendungen die eingebettete JREs mitbringen?
Kapselt ihr Anwendungen (Stichwort: Sandboxing) oder sagt ihr euch "die Version ist vorhanden und die Anwendung wird noch benötigt" oder gibt es noch andere Möglichkeiten?
VG
in der Regel sind doch alle EXE Dateien die man starten kann exploitbar, wenn dort Sicherheitslücken noch nicht gepatched wurden oder?
Da ist doch am Ende der Kampf gegen Windmühlen aussichtslos, wenn man die verteilte und installierte JRE auf dem aktuellen Patchlevel hält und auf der restlichen Wiese 100 verschiedene eingebettete JREs rumschwirren von 11- runter zur Version 5.
Wie kritisch betrachtet Ihr Anwendungen die eingebettete JREs mitbringen?
Kapselt ihr Anwendungen (Stichwort: Sandboxing) oder sagt ihr euch "die Version ist vorhanden und die Anwendung wird noch benötigt" oder gibt es noch andere Möglichkeiten?
VG
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 399850
Url: https://administrator.de/contentid/399850
Ausgedruckt am: 04.12.2024 um 08:12 Uhr
11 Kommentare
Neuester Kommentar
Moin,
leider laufen aktuell an den Arbeitsplätzen einige Fachverfahren, die noch zwingend eine installierte JRE voraussetzen, hier hilft m.E. nur das sofortige Updaten der JRE, bis hoffentlich in Zukunft auch die Fachverfahren ohne JRE laufen.
An einem Server ist ebenfalls ein Fachverfahren im Einsatz, das lt. Systemhaus b.a.w. immer mit der mitausgelieferten JRE betrieben werden muss.
Hier muss ich mich darauf verlassen, dass entweder in Zukunft die JRE entfallen kann oder der Softwarelieferant stets bei Updates eine aktulisierte JRE mitliefert.
Gruß
Edit: Bietet Windows Server von Herstellerseite her die Möglichkeit, ein Sandboxing aufzusetzen?
Für die nächste Windows 10-Version ist ja so etwas von MS angekündigt worden.
leider laufen aktuell an den Arbeitsplätzen einige Fachverfahren, die noch zwingend eine installierte JRE voraussetzen, hier hilft m.E. nur das sofortige Updaten der JRE, bis hoffentlich in Zukunft auch die Fachverfahren ohne JRE laufen.
An einem Server ist ebenfalls ein Fachverfahren im Einsatz, das lt. Systemhaus b.a.w. immer mit der mitausgelieferten JRE betrieben werden muss.
Hier muss ich mich darauf verlassen, dass entweder in Zukunft die JRE entfallen kann oder der Softwarelieferant stets bei Updates eine aktulisierte JRE mitliefert.
Gruß
Edit: Bietet Windows Server von Herstellerseite her die Möglichkeit, ein Sandboxing aufzusetzen?
Für die nächste Windows 10-Version ist ja so etwas von MS angekündigt worden.
Hallo.
Die Java RE systemseitig aktuell zu halten ist in der Tat nicht die Kunst. Bei uns sind diesbezüglich immer alle Rechner aktuell.
Doch bei Embedded Java in Fachanwendungsprogrammen bleibt auch uns in mehreren Fällen keine Wahl, als die Kröte zu schlucken.
Kapseln oder Sandboxen? Vielleicht geht das irgendwie, aber ich wüßte nicht wie. Hab' noch nicht mal eine Vorstellung davon, wie sich ein "gesandboxtes" Programm dann im Zusammenspiel mit Freigaben, Pfaden, DB-Verbindungen, Drucken u. v. w. m. verhält.
Ich denke mir, wenn ich hier vor lauter Ohnmacht (weil bzgl. Java auf den Hersteller angewiesen) direkt keine höhere Sicherheit erlangen kann, dann muß ich halt die Sicherheit meines "Drumherum" in bester Ordnung haben. Firewall, professioneller Malwareschutz inkl. Schutz vor Erpressungstrojanern, Userschulung-/sensibilisierung, Systeme ansonsten Up-To-Date halten usw. undsofort.
Ich fürchte, viel mehr kannst Du nicht tun
.
Viele Grüße
von
departure69
Die Java RE systemseitig aktuell zu halten ist in der Tat nicht die Kunst. Bei uns sind diesbezüglich immer alle Rechner aktuell.
Doch bei Embedded Java in Fachanwendungsprogrammen bleibt auch uns in mehreren Fällen keine Wahl, als die Kröte zu schlucken.
Kapseln oder Sandboxen? Vielleicht geht das irgendwie, aber ich wüßte nicht wie. Hab' noch nicht mal eine Vorstellung davon, wie sich ein "gesandboxtes" Programm dann im Zusammenspiel mit Freigaben, Pfaden, DB-Verbindungen, Drucken u. v. w. m. verhält.
Ich denke mir, wenn ich hier vor lauter Ohnmacht (weil bzgl. Java auf den Hersteller angewiesen) direkt keine höhere Sicherheit erlangen kann, dann muß ich halt die Sicherheit meines "Drumherum" in bester Ordnung haben. Firewall, professioneller Malwareschutz inkl. Schutz vor Erpressungstrojanern, Userschulung-/sensibilisierung, Systeme ansonsten Up-To-Date halten usw. undsofort.
Ich fürchte, viel mehr kannst Du nicht tun
.Viele Grüße
von
departure69
Moin,
Wie sicherheitsrelevant ist den die JRE, wenn sie lokal installiert ist, aber das Browser-Plugin deaktiviert wurde? Das Plugin funktioniert doch eh in fast keinem aktuellen Browser mehr.
Ob der Trojaner, den man sich irgendwie einfaengt, nun in Java, .NET oder nativ geschrieben ist, ist meines Wissens doch irrelevant.
Das Problem bei Java waren doch eigenlich immer die Applets, die aus ihrem Container ausbrechen konnten, aber lokal gestartete (auch bei Webstart?) Java Applikationen laufen doch eh nicht in einem separaten Container, oder wurde das mal geaendert?
Gruss,
rana-mp
Wie sicherheitsrelevant ist den die JRE, wenn sie lokal installiert ist, aber das Browser-Plugin deaktiviert wurde? Das Plugin funktioniert doch eh in fast keinem aktuellen Browser mehr.
Ob der Trojaner, den man sich irgendwie einfaengt, nun in Java, .NET oder nativ geschrieben ist, ist meines Wissens doch irrelevant.
Das Problem bei Java waren doch eigenlich immer die Applets, die aus ihrem Container ausbrechen konnten, aber lokal gestartete (auch bei Webstart?) Java Applikationen laufen doch eh nicht in einem separaten Container, oder wurde das mal geaendert?
Gruss,
rana-mp
Vielleicht male ich hier auch alles einfach zu schwarz.
Security technisch was Web angeht sind wir denke ich gut aufgestellt, die Bauchschmerzen habe ich eher auf der Seite der embedded Versionen.
Wären es nur 2-3 Fachanwendungen die auf alten Versionen rumreiten, hätte ich gesagt, Anzahl der Clients reduzieren und gut ist.
Da die Anzahl der unterschiedlichen Versionen fast ins 3stellige geht und wir hier von einer 5stelligen Clientanzahl reden liegt das etwas anders.
Daher auch meine Suche nach Anregungen und Erfahrung wie andere damit umgehen. =)
Thema Sandboxing:
Ging mir da z.B. App-V durch den Kopf, die Anwendung bekommt eine eigene Blase und ist doch somit abgekapselt vom Rest, d.h. keiner kann von Außen so ohne weiteres auf die JRE in der Bubble zugreifen.
Security technisch was Web angeht sind wir denke ich gut aufgestellt, die Bauchschmerzen habe ich eher auf der Seite der embedded Versionen.
Wären es nur 2-3 Fachanwendungen die auf alten Versionen rumreiten, hätte ich gesagt, Anzahl der Clients reduzieren und gut ist.
Da die Anzahl der unterschiedlichen Versionen fast ins 3stellige geht und wir hier von einer 5stelligen Clientanzahl reden liegt das etwas anders.
Daher auch meine Suche nach Anregungen und Erfahrung wie andere damit umgehen. =)
Thema Sandboxing:
Ging mir da z.B. App-V durch den Kopf, die Anwendung bekommt eine eigene Blase und ist doch somit abgekapselt vom Rest, d.h. keiner kann von Außen so ohne weiteres auf die JRE in der Bubble zugreifen.
Hi
idealerweise bei der Anschaffung, sofern möglich, Java Anwendungen direkt verbieten, hat bei uns fast immer zum Erfolg geführt. Da die meisten Java Anwendungen mit denen ich zu tun hatte immer eine spezielle Version vorausgesetzt haben, haben wir dafür gesorgt das so ein Müll nicht mehr bei uns zum Einsatz kommt - es ist und bleibt eine Seuche, genauso wie Flash (vCenter 6.5 und Motorola RFS Controller lassen grüßen)
95% der Java "Anwendungen" sind einfach so schei*** programmiert, ich habe aktuell nur eine einzige Anwendung im Einsatz gehabt der die installierte Java Version egal war und das war die Management Software von Brocade (Network Analyzer+FC Switche), selbst die deutsche Bank will am Portal immer eine spezielle Version haben die meistens 1-2 Patchstände hinter der aktuellen ist und man somit dort die Clients immer von Hand updaten muss weil sonst deren piss*iges Portal nicht mehr geht.
Wir haben auf 25% der Clients gezwungener Maßen Java installiert, gehört nicht zur Standardinstallation und wird nur im äußersten Bedarf installiert.
Just my 2 Cent
idealerweise bei der Anschaffung, sofern möglich, Java Anwendungen direkt verbieten, hat bei uns fast immer zum Erfolg geführt. Da die meisten Java Anwendungen mit denen ich zu tun hatte immer eine spezielle Version vorausgesetzt haben, haben wir dafür gesorgt das so ein Müll nicht mehr bei uns zum Einsatz kommt - es ist und bleibt eine Seuche, genauso wie Flash (vCenter 6.5 und Motorola RFS Controller lassen grüßen)
95% der Java "Anwendungen" sind einfach so schei*** programmiert, ich habe aktuell nur eine einzige Anwendung im Einsatz gehabt der die installierte Java Version egal war und das war die Management Software von Brocade (Network Analyzer+FC Switche), selbst die deutsche Bank will am Portal immer eine spezielle Version haben die meistens 1-2 Patchstände hinter der aktuellen ist und man somit dort die Clients immer von Hand updaten muss weil sonst deren piss*iges Portal nicht mehr geht.
Wir haben auf 25% der Clients gezwungener Maßen Java installiert, gehört nicht zur Standardinstallation und wird nur im äußersten Bedarf installiert.
Just my 2 Cent
Moin,
Gruß,
Dani
Ging mir da z.B. App-V durch den Kopf, die Anwendung bekommt eine eigene Blase und ist doch somit abgekapselt vom Rest, d.h. keiner kann von Außen so ohne weiteres auf die JRE in der Bubble zugreifen.
So ist es... das Gegenstück von VMWare wäre Thinapp. Den Weg gehen wir inzwischen damit alles in einer Kappsel läuft. Gerade das Thema Anwendung X braucht Java 6, Awendung Y braucht Java 7. Damit ist mit HickHack schluss.Gruß,
Dani
Moin,
Denke, ThinApp/ App-V sind hier die optimalsten Lösungen.
Ich vermute (oder eher hoffe) aber mal, dass durch die kommenden Lizenzgebühren seitens Oracle die eine oder andere Applikation dahingehend aktualisiert wird, dass auf Java verzichtet werden kann.
Spannend wird es aber, wenn man beispielsweise Switche von Brocade/ Ruckus hat. Die brauchen (für die GUI) ja weiterhin ein Java :/
Gruß
em-pie
Denke, ThinApp/ App-V sind hier die optimalsten Lösungen.
Ich vermute (oder eher hoffe) aber mal, dass durch die kommenden Lizenzgebühren seitens Oracle die eine oder andere Applikation dahingehend aktualisiert wird, dass auf Java verzichtet werden kann.
Spannend wird es aber, wenn man beispielsweise Switche von Brocade/ Ruckus hat. Die brauchen (für die GUI) ja weiterhin ein Java :/
Gruß
em-pie
Ich nehm das Kapseln mal mit auf die Agenda und suche mir intern Verbündete um das durchzubekommen. =)
Zitat von @em-pie:
Moin,
Denke, ThinApp/ App-V sind hier die optimalsten Lösungen.
Ich vermute (oder eher hoffe) aber mal, dass durch die kommenden Lizenzgebühren seitens Oracle die eine oder andere Applikation dahingehend aktualisiert wird, dass auf Java verzichtet werden kann.
Spannend wird es aber, wenn man beispielsweise Switche von Brocade/ Ruckus hat. Die brauchen (für die GUI) ja weiterhin ein Java :/
Gruß
em-pie
Moin,
Denke, ThinApp/ App-V sind hier die optimalsten Lösungen.
Ich vermute (oder eher hoffe) aber mal, dass durch die kommenden Lizenzgebühren seitens Oracle die eine oder andere Applikation dahingehend aktualisiert wird, dass auf Java verzichtet werden kann.
Spannend wird es aber, wenn man beispielsweise Switche von Brocade/ Ruckus hat. Die brauchen (für die GUI) ja weiterhin ein Java :/
Gruß
em-pie
wer braucht die GUI ... :D
Wir haben >100 Geräte von denen und bei keinem, außer den FC Switchen, die GUI freigeschaltet geschweige denn eingerichtet
Zitat von @clSchak:
Wir haben >100 Geräte von denen und bei keinem, außer den FC Switchen, die GUI freigeschaltet geschweige denn eingerichtet
Zitat von @em-pie:
Spannend wird es aber, wenn man beispielsweise Switche von Brocade/ Ruckus hat. Die brauchen (für die GUI) ja weiterhin ein Java :/
wer braucht die GUI ... :DSpannend wird es aber, wenn man beispielsweise Switche von Brocade/ Ruckus hat. Die brauchen (für die GUI) ja weiterhin ein Java :/
Wir haben >100 Geräte von denen und bei keinem, außer den FC Switchen, die GUI freigeschaltet geschweige denn eingerichtet
Und um genau die ging es mir...
Aber ansonsten hast du natürlich recht
Kleiner Hinweis zu APP-V: Braucht eine SA bei Microsoft, läßt sich anders nicht käuflich erwerben und/oder lizensieren. Größere Läden werden SA aber ohnehin schon haben, bei uns wär's eher schwierig, wir sind bisher nur normale VL-Kunden über einen Rahmenvertrag.
