log4j CVE-2021-44228

[EOL63]

https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile&v=3

Weiss jemand ob Applications bei Synology und QNAP davon betroffen sind oder sogar der Corecode?

 

[tiermutter]

Bei QNAP wohl nicht, wenn dann hätte QNAP auch ganz fix die entsprechende Info rausgegeben.

 

[tiermutter]

Wie @dolbyman soeben berichtet könnte Qsirch betroffen sein: https://www.reddit.com/r/qnap/comments/re8y34/log4shell_mitigation/

Ich bin da ganz entspannt, egal auf welchem System der Dienst im Einsatz sein könnte: Sie sind nicht von außen erreichbar, außer meine Firewall und die ist nicht betroffen.

 

[EOL63]

nicht von außen erreichbar,

Oft sind es unzufriedene interne Mitarbeiter die aus welchen Gruenden auch immer interne Systeme attackieren ...

 

[tiermutter]

Ja ok, sowas soll es auch geben. Bei mir aber nicht

 

[EOL63]

Bei mir aber nicht

Du hast also nur zufriedene Mitarbeiter bei Dir. So sollte es sein

 

[tiermutter]

Allenfalls eine unzufriedene Frau daheim... scheiße. Ich geh dann mal Wäsche machen und den Geschirrspüler ausräumen...

 

[rednag]

Default glaube ich ist QTS nicht direkt davon betroffen.
Wäre beispielsweise was anderes wenn man Java auf einer NAS installiert, oder aber dies eine App per Abhängigkeit erfordert.

 

[EOL63]

Jupp. Es sind nur Javaprogramme betroffen. Ich habe log4j auch intensiv genutzt.

Das blöde ist man weiss als Anwender i.d.R. nicht ob und das Java genutzt wird. Deshalb meine Frage in die Runde ob es Java Applications bei Syno und/oder QNAP gibt.

 

[tiermutter]

Bei QNAP ist mir noch keine offensichtliche Java App untergekommen, wenn dann war es Python. JRE gibt es bei QNAP aber zumindest offiziell als Download, solange das nicht installiert ist dürfte ja eigentlich auch keine Java Anwendung existieren bzw. funktionieren.

 

[Mavalok2]

Wäre schön, wenn dies so wäre. Javabestandteile können in Programmen enthalten sein, ohne dass man dies als Nutzer merkt. Dafür ist keine separate Installation von einer Java Runtime mehr notwendig. Das wird einfach mit ins Programm gepackt. Von Java gab / gibt es ja bald jede Woche ein Update und ziemlich häufig neue Versionen. War wohl löchriger als ein Schweizer Käse. (War deshalb: Java ist für mich schon lange gestorben. Habe alle Runtimes von den Systemen verbannt. Aber leider nutzt dies nichts. Ist auf vielen Geräten / Systemen / Software noch vorhanden.)
Vermutlich haben deshalb die Hersteller begonnen die Java-Runtimes mit in die Software zu integrieren. War wohl billiger und einfacher so, Jahre lang die selbe Java-Version verwenden. Und für die Sicherheitslücken ist dann der Kunde selbst verantwortlich. Wäre es anders, könnte man jetzt einfach ganz entspannt Java auf den letzten Stand bringen, und alle Software eines System wäre geschützt, auf einen Schlag. Aber so muss man eigentlich alle Software, Dienst etc. einzeln prüfen und gegebenen Falls updaten.

Ebenfalls angenehm wäre ein Update-Center, wie man es z.B. von den Handys kennt. Sobald die Hersteller nachgebessert haben kommt das Update automatisch. Ein Suchen und prüfen würde entfallen. Gibt es z.B. auch auf den meisten Linux Distributionen. Aber Windows - und so viel ich weiß auch bei Mac - gibt es dies in der Form nicht. Da muss jeder selber ran.

Ich geh dann mal Wäsche machen und den Geschirrspüler ausräumen...

Solange Deine Regierung das Passwort hat, muss Du Dir bezüglich internen Sicherheitslücken sicher keine Gedanken machen. Aber gut stellen mit Abwaschen kann sicher nie schaden, und sei es nur Prävention für den nächsten Mist den man selbst macht.

 

[EOL63]

Vermutlich haben deshalb die Hersteller begonnen die Java-Runtimes mit in die Software zu integrieren.

Es ist ein allgemeines Problem von common libraries dass alle Anwendungen, die sie nutzen von ihr abhaengig sind und wenn es incompatible Interfaceaenderungen der Library gibt wird der Ersteller der Anwendung vom Anwender beschuldigt obwohl er eigentlich unschuldig ist oder durch neue Librarystaende Fehler reinkommen und auch dann ist der Ersteller der Anwendung unschuldig.

So gut der Gedanke einer common library ist - dadurch koennte man schnell den log4j Bug in allen Javaanwendungen fixen - so viele Probleme haben Javaanwender mit den Libraries und Updates erfahren dass sie dazu uebergegangen sind die Libraries und Runtime mit der Anwendung zu bundeln. Und somit hat man dann auf einem System haeufig zig verschiedene Versionen von Javalibraries und Runtimes da eine jede Anwendung ihren eigenen Stand mitbringt

Ich moechte noch darauf hinweisen dass dieses Problem mit den Libraries kein javaspezifischen Problem ist. Nicht umsonst gibt es in den OSen static und dynamic Libraries

 

[Mavalok2]

Ganz klar, keine Vorteile ohne Nachteile. Meiner einer ist einfach grundsätzlich kein Freund von Java, egal ob integriert oder als Runtime Installation. Hatte über die Jahre (oje, sind wohl schon Jahrzente) einfach zu viele Probleme damit. Und ganz klar, gibt auch mit anderen Runtimes und Bibliotheken die selben Probleme. Aber manche stechen einfach immer hervor, vermutlich einfach auch deswegen, denn je größer die Verbreitung, desto größer die wahrgenommen Probleme. Deshalb mag ich eigentlich die "unbekannteren" Produkte. Da fällt der Bombeneinschlag meist nicht so schwer aus. Kleinere Hersteller sind meist auch noch flexibler. Da kann man oft noch als Kunde Wünsche anbringen, die dann auch umgesetzt werden, wenn möglich. Versuch dies mal bei MS, oder im Fall von Java, bei Oracle.

 

[blurrrr]

Default glaube ich ist QTS nicht direkt davon betroffen.

Gibt auch einen Artikel von QNAP dazu: https://www.qnap.com/de-de/security-advisory/qsa-21-58