Ergebnis 1 bis 15 von 15

Thema: JAVA JRE und die Sicherheit...

  1. #1
    Zeitreisender

    Administrator

    Avatar von drfuture
    Registriert seit
    Jul 2013
    Ort
    in der Zukunft
    Beiträge
    6.768
    ngb:news Artikel
    17

    JAVA JRE und die Sicherheit...

    Hat einer von euch eine Idee Bzw. eine Quelle wie es mit nicht installirten JREs aussieht die mit div. Programmen als Laufzeitumgebung mitgeliefert werden?
    Diese Laufzeitumgebungen sind oft extrem veraltet.

    Eine aktuelle Laufzeitumgebung rein zu kopieren "könnte" natürlich erfolgreich sein - macht aber ja inzwischen zumindest im Gewerblichen Umfeld Lizenzprobleme insofern man nicht auch noch von Oracle JRE (JDK) auf eine alternative JRE geht.

    Ganz davon abgesehen versagt dann eventuell der Support für die Anwendung selber.
    Wenn nun die Firma nicht gewillt ist die ausgelieferte JRE zu aktualisieren bleibt natürlich der Weg das Produkt zu wechseln - das ist aber nicht immer "einfach so" möglich.

    Daher stellst sich mir allgemein die Frage ob eine JRE mit bekannten Sicherheitslücken, wenn sie irgendwo im Dateisystem liegt, wirklich eine Auswirkung hat - oder "eher" nicht. Dazu kenne ich mich auch zu wenig mit Java und der Ausnutzbarkeit derer Lücken aus.
    |_|D *`~{ Ich kenne deine Zukunft }~´* |_|D

  2. #2
    Mitglied
    Registriert seit
    Jul 2013
    Beiträge
    369
    ngb:news Artikel
    1

    Re: JAVA JRE und die Sicherheit...

    Nach einem kurzen Blick über die bekannten Schwachstellen von Java scheinen die meisten Schwachstellen sich auf die Java-Sandbox (SecurityManager etc) zu beziehen.
    Das heißt: wenn du nicht vertrauenswürdigen Java-Code ausführst und Java-Features nutzt um ihn zu beschränken, dann könnte dieser Code versuchen sich zusätzliche Privilegien zu verschaffen. Klassischer Fall dafür wären die Java-Applets, die im Browser laufen und Java-Code aus dem Internet ausführen. Standalone-Anwendungen die auf Java basieren nutzen die Sandbox meist nicht mal, und sollten zu 99% auch keinen Java-Code aus dem Internet nachladen. Solange deine Anwendungen also kein Browser-Plugin installieren brauchen die dich nicht zu interessieren.
    Natürlich ist nicht auszuschließen dass da auch mal ne Lücke in der API dabei ist, die sich unter Umständen sogar ausnutzen lässt wenn das Programm die entsprechende API benutzt. Aktuell sehe ich da drei CVE's (CVE-2018-14048, CVE-2018-13785, CVE-2018-11212) bei denen eine speziell präparierte png- oder jpeg-Datei die Anwendung zum Absturz bringen kann, wenn dein Java-Programm versuchen sollte dieses Bild zu laden.
    Die meisten Lücken sind aber wie gesagt mehr Privilege Escalation aus der Java-Sandbox - daher kam auch der Ruf von Java "unsicher" zu sein, interessiert dich aber wohl "eher nicht".

    Andererseits kannst du natürlich einfach mal versuchen die alten JRE durch ein aktuelles OpenJDK zu ersetzen. Die Chancen stehen gut dass das klappt, falls Probleme auftreten kannst du ja einmal mit der alte JRE gegen-testen bevor du den Support anrufst.
    Für diesen Beitrag bedankt sich BurnerR

  3. #3
    Vereinsheimer Avatar von Laui
    Registriert seit
    Jul 2013
    Beiträge
    20.584
    ngb:news Artikel
    2

    Re: JAVA JRE und die Sicherheit...

    Wie sieht es mit einem alten JRE aus, das in einem Webclient emuliert wird? Hatte da letztens so was?

    Andererseits kannst du natürlich einfach mal versuchen die alten JRE durch ein aktuelles OpenJDK zu ersetzen. Die Chancen stehen gut dass das klappt, falls Probleme auftreten kannst du ja einmal mit der alte JRE gegen-testen bevor du den Support anrufst.
    Also wie sich das beruflich zeigt, kann ich nicht beurteilen, das ist von Fall zu Fall unterschiedlich. Aus eigener Erfahrung z.B. auch Java in Linux kann ich sagen, dass quasi das Aktualisieren der JRE (offiziell das 8er, was immer noch gepflegt wird) keine negativen Auswirkungen hat, im Gegenteil alle Anwendungen laufen.

    Als Beispiel hatte ich hier ein ArchiCAD was vom Installer her immer das Java 1.x mitliefert, uralt und nicht mehr aktuell. Die Installation konnte ich austricksen, indem ich vorher das aktuelle JRE installiert habe. Der Installer übersprang dann den Part und schlussendlich hat ArchiCAD funktioniert im volllen Umfang.

  4. #4
    Defender of Freedom

    Administrator

    Avatar von Metal_Warrior
    Registriert seit
    Aug 2013
    Ort
    /dev/mapper/home
    Beiträge
    5.958
    ngb:news Artikel
    7

    Re: JAVA JRE und die Sicherheit...

    @Laui: OpenJDK-11 frisst nicht alle Java-8-Anwendungen, das hab ich grad hier im Test.

    @drfuture
    Bei Windows kann man doch auch mit Pfadvariablen/Umgebungsvariablen arbeiten; wenn du da den aktuellen Java-Client einpackst, dürften alle Java-Anwendungen, die nicht explizit anders konfiguriert sind, genau den verwenden, was dir die Möglichkeit von Parallelinstallationen offen halten sollte.
    GCM/IT/S/O d-(--) s+:- a? C++(+++) UL+++(++++)$ P L+++>++++ W++ w@$ M--$ PS+(++) PE(-) Y+(++) PGP++(+++) t+ 5(+) R* !tv b+(++++) DI(++) G++ e+>++++ h(--) y?
    Das Ende ist nahe: Dem Harleyschen Kometen folgt der Gammablitz beim Scheißen.

  5. #5
    Zeitreisender

    Administrator

    (Threadstarter)

    Avatar von drfuture
    Registriert seit
    Jul 2013
    Ort
    in der Zukunft
    Beiträge
    6.768
    ngb:news Artikel
    17

    Re: JAVA JRE und die Sicherheit...

    Oh ganz vergessen hier wieder zu antworten.

    @Metal_Warrior,
    ja man kann mit Umgebumgsvariablen arbeiten - wird auch gemacht. Die "Installierte" version mit Umgebungsvariablen ist auch aktuell. Das Problem sind eben eher die mitgelieferten die Div. Hersteller im Programmverzeichnis liegen haben. Diese nehmen leider nicht die globale (Vermutlich schon absichtlich da eh inkompatibel)

    @Rakorium-M
    Vielen Dank - so ähnlich hätte ich es ebenfalls verstanden - nur eben mangels Detailwissen etwas unsicher.

    @Java allgemein
    Es gibt zwischen Java 8 und >8 ja div. Unterschiede z.B. Wegfall von Java Jumpstart - was "glaube" ich auch bei den OpenJDK 8 Versionen ebenfalls je nach "Hersteller" nicht mehr dabei ist.
    Alle Anwendungen die das nutzen haben hier schon einmal ein Problem und lassen sich nicht aktualisieren :/

    Mit dem "Einfach mal ein neues nutzen" ... mag im grunde Stimmen. Wenn aber z.B. Datenbanken dahinter liegen die eventuell, könnte ich mir vorstellen, falsch kodierten Inhalt bekommen können - oder wie unter anderem bei uns gegeben so "nette" Anwendungen wie Brandmeldeanlagen-Überwachung / Verwaltung über eine Java-Anwendung laufen - dann ist es mir doch bei so mancher Software zu unsicher mal die Java-Version zu tauschen und drauf zu hoffen das "alle" Funktionen die dort programmiert sind so laufen wie dies zuvor der Fall war.
    Nur weil die Anwendung startet heißt es ja nicht das alles so wie vom Programmierer gedacht läuft - dabei muss die Anwendung noch nicht einmal zwingend einen Fehler werfen?
    |_|D *`~{ Ich kenne deine Zukunft }~´* |_|D

  6. #6
    Mitglied
    Registriert seit
    Jul 2013
    Ort
    /dev/null
    Beiträge
    2.772

    Re: JAVA JRE und die Sicherheit...

    Wir haben bei uns den konkreten Fall mit Netbackup. Das liefert eine uralte JRE-Version mit aus. Nimmt man eine neuere oder eine aktuelle OpenJDK, gibt's keinen Support mehr. Ich glaub mich auch dunkel zu erinnern, dass die Anwendung damit nicht mehr funktionieren wollte. Glücklicherweise ist davon nur die Desktop-GUI betroffen.

    Der SQLDeveloper von Oracle läuft übrigens auch nur mit dem 1.8-er Java. Die 11-er Version funktioniert nicht damit.

    Aber über die Pfade (beim Applikationsaufruf) kannst du wenigstens die löcherigen Versionen soweit isolieren, dass sie nur von der jeweiligen Anwendung benutzt werden. So machen wir das auch.

    Und die Erkenntnis, ob die jeweilige Anwendung, die mit der 8-er auch mit höheren Versionen funktioniert, ist halt Trial & Error.

  7. #7
    Zeitreisender

    Administrator

    (Threadstarter)

    Avatar von drfuture
    Registriert seit
    Jul 2013
    Ort
    in der Zukunft
    Beiträge
    6.768
    ngb:news Artikel
    17

    Re: JAVA JRE und die Sicherheit...

    @musv: "Aber über die Pfade (beim Applikationsaufruf) kannst du wenigstens die löcherigen Versionen soweit isolieren, dass sie nur von der jeweiligen Anwendung benutzt werden. So machen wir das auch."

    So wirklich isolieren tut man damit ja nichts - daher ja auch die Befürchtugen. Jeder "Angreifer" auf dem PC kann insofern er in irgend einer Weise zugriff auf den PC bekommt - und da reichen Benutzerrechte ja voll aus - eine eigene "Starte-Anwendung.bat" schreiben in der er die unsere jre mit seinem - oder einer beliebigen Java-Anwendung auf dem PC verwendet.
    ... klar im zweifel kann man eine alte jre auch downloaden und dann verwenden. Insofern alte JRE versionen nicht mehr verwendet werden (müssen) könnte man deren Ausführung aber unternehmensweit per Application-Controle auch unterbinden.
    |_|D *`~{ Ich kenne deine Zukunft }~´* |_|D

  8. #8
    Defender of Freedom

    Administrator

    Avatar von Metal_Warrior
    Registriert seit
    Aug 2013
    Ort
    /dev/mapper/home
    Beiträge
    5.958
    ngb:news Artikel
    7

    Re: JAVA JRE und die Sicherheit...

    @drfuture: Ich meinte irgendwo gelesen zu haben, dass man mit GroupPolicies Anwendungen einschränken kann bzw. Usern explizite Anwendungen zu verbieten. Wenn du es also schaffst, dem User den Aufruf der alten Binary nur noch mit einem Befehl zu erlauben (der die alte Anwendung startet), bist du so sicher, wie du nur sein kannst. Wenn der User in der Lage ist, die Binaries zu ändern, ist der Rechner eh übernommen.
    GCM/IT/S/O d-(--) s+:- a? C++(+++) UL+++(++++)$ P L+++>++++ W++ w@$ M--$ PS+(++) PE(-) Y+(++) PGP++(+++) t+ 5(+) R* !tv b+(++++) DI(++) G++ e+>++++ h(--) y?
    Das Ende ist nahe: Dem Harleyschen Kometen folgt der Gammablitz beim Scheißen.

  9. #9
    Zeitreisender

    Administrator

    (Threadstarter)

    Avatar von drfuture
    Registriert seit
    Jul 2013
    Ort
    in der Zukunft
    Beiträge
    6.768
    ngb:news Artikel
    17

    Re: JAVA JRE und die Sicherheit...

    Ja ich kann Usern erlauben Binarys zu starten oder nicht - aber nicht inkl. Parametern. Die Ausführung wird eingeschränkt und die Intigrität der Binary kann damit geprüft und sichergestellt werden. Da die Java-Runtime aber einfach über Parameter aufgerufen wird / werden kann wird das glaube ich nicht funktionieren - bzw. lässt sich nicht auf den gesamten Aufruf prüfen da die Ausführung der Anwendung als solches blockiert wird und nicht eine "Aufruf-Zeichenkette". - werde Das aber einmal prüfen... da das wirklich praktisch wäre.

    Ganz nebenbei ist das "Problem" ja im Grunde Plattform-Unabhängig ...
    |_|D *`~{ Ich kenne deine Zukunft }~´* |_|D

  10. #10
    Defender of Freedom

    Administrator

    Avatar von Metal_Warrior
    Registriert seit
    Aug 2013
    Ort
    /dev/mapper/home
    Beiträge
    5.958
    ngb:news Artikel
    7

    Re: JAVA JRE und die Sicherheit...

    @drfuture: Eigentlich nicht - Linux hat da genug Möglichkeiten.
    GCM/IT/S/O d-(--) s+:- a? C++(+++) UL+++(++++)$ P L+++>++++ W++ w@$ M--$ PS+(++) PE(-) Y+(++) PGP++(+++) t+ 5(+) R* !tv b+(++++) DI(++) G++ e+>++++ h(--) y?
    Das Ende ist nahe: Dem Harleyschen Kometen folgt der Gammablitz beim Scheißen.

  11. #11
    Zeitreisender

    Administrator

    (Threadstarter)

    Avatar von drfuture
    Registriert seit
    Jul 2013
    Ort
    in der Zukunft
    Beiträge
    6.768
    ngb:news Artikel
    17

    Re: JAVA JRE und die Sicherheit...

    Ich meine nicht die Blockade, sondern das im Grunde alte Programme aufgerufen werden können.

    Wie man Befehlsketten unter Linux Global sperren kann klingt aber auch interessant und würde mich interessieren.
    |_|D *`~{ Ich kenne deine Zukunft }~´* |_|D

  12. #12
    Defender of Freedom

    Administrator

    Avatar von Metal_Warrior
    Registriert seit
    Aug 2013
    Ort
    /dev/mapper/home
    Beiträge
    5.958
    ngb:news Artikel
    7

    Re: JAVA JRE und die Sicherheit...

    @drfuture: Naja, du installierst die Software unter einen bestimmten Pfad, in dem nur eine bestimmte Gruppe Ausführungsrechte hat, und lässt sudo -g $GRUPPE nur für bestimmte Befehle zu. Oder du schreibst Bash-Scripte, die intern auf einen bestimmten User wechseln, der Ausführungsrechte auf dem Programm hat, und von einer Gruppe an Leuten als root ausgeführt werden dürfen (wieder mit sudo).
    GCM/IT/S/O d-(--) s+:- a? C++(+++) UL+++(++++)$ P L+++>++++ W++ w@$ M--$ PS+(++) PE(-) Y+(++) PGP++(+++) t+ 5(+) R* !tv b+(++++) DI(++) G++ e+>++++ h(--) y?
    Das Ende ist nahe: Dem Harleyschen Kometen folgt der Gammablitz beim Scheißen.

  13. #13
    Zeitreisender

    Administrator

    (Threadstarter)

    Avatar von drfuture
    Registriert seit
    Jul 2013
    Ort
    in der Zukunft
    Beiträge
    6.768
    ngb:news Artikel
    17

    Re: JAVA JRE und die Sicherheit...

    Das die Software ausgeführt werden darf ist ja gerade das Problem?

    Kann ich in einem Bash-Script zu einem Benutzer wechseln auf den der Benutzer selber eigentlich keine Rechte hat? Also im Bashscript "RunJavaApp2" kann sudo für "javauser1" genutzt werden aber Max kann kein sudo auf javauser1 machen?

    Weil sonst verstehe ich gerade nicht wie die Limitierung der Ausführung etwas bringt.

    Nehmen wir an ich habe einen Benutzer "Max"
    und eine Software in

    /usr/bin/monsterapp/monsterapp.jar
    und einer jre
    /usr/bin/monsterapp/jre

    Der Benutzer Max soll nun die Anwendung ausführen dürfen...
    Startet also /usr/bin/monsterapp/jre/bin/java -jar /usr/bin/monsterapp/monsterapp.jar

    Max bekommt nun execute rechte auf /usr/bin/monsterapp/jre/bin/java
    Warum kann Max dann nicht /usr/bin/monsterapp/jre/bin/java -jar /home/max/special.jar
    starten?
    |_|D *`~{ Ich kenne deine Zukunft }~´* |_|D

  14. #14
    Defender of Freedom

    Administrator

    Avatar von Metal_Warrior
    Registriert seit
    Aug 2013
    Ort
    /dev/mapper/home
    Beiträge
    5.958
    ngb:news Artikel
    7

    Re: JAVA JRE und die Sicherheit...

    @drfuture: Weil du mit Sudo ganze Kommandozeilen mitsamt Parameter angeben kannst. Also ja, das geht.

    Zum Beispiel können unsere Kunden sudo systemctl restart apache2 ausführen, aber nicht sudo systemctl daemon-reload, sudo systemctl status apache2 oder sudo systemctl restart dnsmasq.

    Und nein, Max bekommt keine Execute-Rechte auf /usr/bin/monsterapp/jre/bin/java, die bekommt javauser1.
    Max darf aber sudo -u javauser1 /usr/bin/monsterapp/jre/bin/java -jar /usr/share/monsterapp/monsterapp.jar ausführen. Der User, der also letztlich die Binary ausführt, ist javauser1.
    GCM/IT/S/O d-(--) s+:- a? C++(+++) UL+++(++++)$ P L+++>++++ W++ w@$ M--$ PS+(++) PE(-) Y+(++) PGP++(+++) t+ 5(+) R* !tv b+(++++) DI(++) G++ e+>++++ h(--) y?
    Das Ende ist nahe: Dem Harleyschen Kometen folgt der Gammablitz beim Scheißen.

  15. #15
    Zeitreisender

    Administrator

    (Threadstarter)

    Avatar von drfuture
    Registriert seit
    Jul 2013
    Ort
    in der Zukunft
    Beiträge
    6.768
    ngb:news Artikel
    17

    Re: JAVA JRE und die Sicherheit...

    Ah ok verstanden
    |_|D *`~{ Ich kenne deine Zukunft }~´* |_|D

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •