h41msh1c0r
Goto Top

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

Content-ID: 399850

Url: https://administrator.de/contentid/399850

Printed on: December 2, 2024 at 17:12 o'clock

VGem-e
VGem-e Jan 30, 2019 updated at 10:21:29 (UTC)
Goto Top
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.
departure69
departure69 Jan 30, 2019 updated at 10:37:39 (UTC)
Goto Top
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 face-sad.


Viele Grüße

von

departure69
rana-mp
rana-mp Jan 30, 2019 at 10:40:50 (UTC)
Goto Top
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
H41mSh1C0R
H41mSh1C0R Jan 30, 2019 updated at 10:52:51 (UTC)
Goto Top
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.
clSchak
clSchak Jan 30, 2019 at 15:51:29 (UTC)
Goto Top
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
Dani
Dani Jan 30, 2019 at 18:46:26 (UTC)
Goto Top
Moin,
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
em-pie
em-pie Jan 30, 2019 at 21:40:18 (UTC)
Goto Top
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
H41mSh1C0R
H41mSh1C0R Jan 31, 2019 at 09:08:12 (UTC)
Goto Top
Ich nehm das Kapseln mal mit auf die Agenda und suche mir intern Verbündete um das durchzubekommen. =)
clSchak
clSchak Jan 31, 2019 at 09:57:50 (UTC)
Goto Top
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

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 face-smile
em-pie
em-pie Jan 31, 2019 at 10:15:08 (UTC)
Goto Top
Zitat von @clSchak:

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 ... :D

Wir haben >100 Geräte von denen und bei keinem, außer den FC Switchen, die GUI freigeschaltet geschweige denn eingerichtet face-smile

Und um genau die ging es mir...

Aber ansonsten hast du natürlich recht face-smile
departure69
departure69 Jan 31, 2019 at 10:52:37 (UTC)
Goto Top
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.