• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

JAVA JRE und die Sicherheit...

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.718
Ort
in der Zukunft
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.
 

Rakorium-M

NGBler

Registriert
14 Juli 2013
Beiträge
413
Nach einem kurzen Blick über die bekannten Schwachstellen von Java scheinen die meisten Schwachstellen sich auf die Java-Sandbox ([kw]SecurityManager[/kw] 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.
 

Steeve

Vereinsheimer
Barkeeper

Registriert
15 Juli 2013
Beiträge
41.121
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.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.829
Ort
/dev/mapper/home
@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.
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.718
Ort
in der Zukunft
  • Thread Starter Thread Starter
  • #5
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?
 

musv

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
3.453
Ort
/dev/null
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.
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.718
Ort
in der Zukunft
  • Thread Starter Thread Starter
  • #7
@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.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.829
Ort
/dev/mapper/home
@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.
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.718
Ort
in der Zukunft
  • Thread Starter Thread Starter
  • #9
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 ...
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.718
Ort
in der Zukunft
  • Thread Starter Thread Starter
  • #11
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.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.829
Ort
/dev/mapper/home
@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).
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.718
Ort
in der Zukunft
  • Thread Starter Thread Starter
  • #13
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?
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.829
Ort
/dev/mapper/home
@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.
 
Oben