The Security found one vulnerable packages

  • Affected Version
    WoltLab Suite 5.5

    Mahlzeit,

    bekomme von meiner Server Security immer wieder das folgende Package als Unsicher gemeldet, da es veraltet uns mit Sicherheitslücken behaftet ist.

    Packages:

    laminas/laminas-diactoros:2.4.1

    Dieses gehört scheinbar zum Core, ist es möglich hier in absehbarer Zeit eine neuere und Aktuelle Version zu implementieren?

    Die alte Version 2.4.1 scheint ebenfalls nicht mehr wirklich mit PHP 8.0 oder 8.1 zu funktionieren.

    Die aktuelle Version wäre wohl 2.24.0

    Greetz

    Dark

    Mit dem Ende naht der Anfang mit etwas Neuen, um dann wieder zu sagen „Nach dem Update ist vor dem Update“. :S

  • Hallo,

    in bestehenden Branches aktualisieren wir Abhängigkeiten grundsätzlich nicht. In diesem spezifischen Fall von Diactoros kann eine Aktualisierung in WoltLab Suite 5.5 auch gar nicht erfolgen, da die Mindestanforderungen neuerer Versionen zu hoch sind. Die Sicherheitslücke in Diactoros 2.4 ist für die Verwendung in WoltLab Suite 5.5 irrelevant / unreachable. Relevante Sicherheitskorrekturen backporten wir nach sorgfältiger Prüfung (so in der Vergangenheit bereits erfolgt mit Guzzle).

    WoltLab Suite 6.0 enthält bereits Diactoros 2.24. Alle Abhängigkeiten werden bis zum Release auch regelmäßig aktualisiert.

  • Tim Düsterhus February 23, 2023 at 12:01 PM

    Added the Label 6.0.0 Beta 1
  • Tim Düsterhus February 23, 2023 at 12:01 PM

    Added the Label Fixed
  • Hallo,

    was ich noch sagen wollte:

    ist für die Verwendung in WoltLab Suite 5.5 irrelevant / unreachable

    ↑ ist auch der Grund, warum stupide Scan-Tools auf Basis einer Versionsnummer, wie folgendes:

    bekomme von meiner Server Security immer wieder das folgende Package als Unsicher gemeldet, da es veraltet uns mit Sicherheitslücken behaftet ist.

    Kompletter Unsinn sind. Software wird nicht in einem Vakuum betrieben und die Beurteilung von Sicherheitslücken muss immer im Gesamtkontext erfolgen. Mir kommt beispielsweise diese „ReDoS“-Seuche (Regular Expression Denial of Service), bei denen selbsternannte „Sicherheitsforscher“ mit automatischen Tools einmal komplett npm nach potentiell verwundbaren regulären Ausdrücken abgrasen, ohne weitere Prüfung eine CVE-Nummer beantragen und damit alle Leute fickerig machen. ReDoS in einer reinen Entwickler-Abhängigkeit, mit der der Entwickler sich maximal selbst „DoS“en kann ist im Schweregrad sehr weit unten und kann kaum als Sicherheitslücke bezeichnet werden.

    Siehe auch:

    2022 - Era of the CVE
    With GitHub offering CVEs and a few more services able to reserve them - this is the year of the CVE.
    connortumbleson.com
  • ↑ ist auch der Grund, warum stupide Scan-Tools auf Basis einer Versionsnummer, wie folgendes:

    Es ist schon etwas merkwürdig, dass meistens das, was vom Kunden kommt, als falsch oder Unsinn bezeichnet wird, ich habe hier lediglich festgestellt, dass diese eingesetzte Version doch etwas mehr als veraltet ist und wollte wissen, ob diese zeitnah ersetzt wird.

    Doch scheinbar darf man als Kunde, der jedes Jahr eine Lizenz -Verlängerung kaufen soll, nicht erwarten eine Software zu erwarten, die zeitlich und auch Script technisch auf dem aktuellen Stand der Zeit ist.

    Sorry, aber das ist eine recht traurige und stupide Reaktion von dir. :thumbdown:

    Thema ist hiermit für mich erledigt, hab Besseres zu tun.

    Greetz

    Dark

    Mit dem Ende naht der Anfang mit etwas Neuen, um dann wieder zu sagen „Nach dem Update ist vor dem Update“. :S

  • Doch scheinbar darf man als Kunde, der jedes Jahr eine Lizenz -Verlängerung kaufen soll, nicht erwarten eine Software zu erwarten, die zeitlich und auch Script technisch auf dem aktuellen Stand der Zeit ist.

    ->

    In diesem spezifischen Fall von Diactoros kann eine Aktualisierung in WoltLab Suite 5.5 auch gar nicht erfolgen, da die Mindestanforderungen neuerer Versionen zu hoch sind

    dass meistens das, was vom Kunden kommt, als falsch oder Unsinn bezeichnet wird

    Das wurde so nicht gesagt und war auch nicht gemeint. Es geht bei der Aussage viel mehr um diese "Sicherheitslösungen", die oft umsonst Pferde scheu machen, wo es gar keinen Grund dazu gibt. Und das ist eben auch hier der Fall.

  • Doch scheinbar darf man als Kunde, der jedes Jahr eine Lizenz -Verlängerung kaufen soll, nicht erwarten eine Software zu erwarten, die zeitlich und auch Script technisch auf dem aktuellen Stand der Zeit ist.


    Sorry, aber das ist eine recht traurige und stupide Reaktion von dir. :thumbdown:


    Thema ist hiermit für mich erledigt, hab Besseres zu tun.

    Hast du schlecht geschlafen? Tim hat doch begründet, wieso ein Update dieser Abhängigkeit in Version 5.5 nicht möglich ist und dir darüber hinaus erklärt, dass sie dennoch die Sicherheit gewährleisten, indem sie notwendige Korrekturen backporten, falls notwendig - was hier nicht der Fall ist. Sein Einwand, dass Sicherheits-Tools, die einfach nur stumpf die Versionsnummer eingesetzter Abhängigkeiten prüfen, aber nicht, ob im konkreten Fall tatsächlich eine Gefährdung vorliegt, irreführend sein kann, ist außerdem berechtigt. Dafür kann weder Tim noch WoltLab etwas für. Deine Reaktion darauf ist unverhältnismäßig. :/

  • Hallo,

    nicht erwarten eine Software zu erwarten, die zeitlich und auch Script technisch auf dem aktuellen Stand der Zeit ist.

    in dem ersten Beitrag habe ich erklärt, warum Diactoros in Version 2.4 vorliegt, warum das kein Problem ist und, dass mit WoltLab Suite 6.0 die aktuelle Version genutzt wird. Selbstverständlich achten wir darauf, dass die Abhängigkeiten auf dem aktuellen Stand der Zeit sind bzw. dass Sicherheitslücken in älteren Versionen korrigiert werden, ohne das Verhalten anderweitig zu verändern.

    Und eben deshalb ist die Verwendung von „stupiden Scan-Tools“ (das Adjektiv bezieht sich explizit auf das Tool und nicht auf dich) Unsinn. Siehe auch: RE: jQuery UI wie updaten?. Das ist auch nicht nur bei unserer Software so. Im Docker-Umfeld gibt es ähnliche Scan-Tools, die bei irgendwelchen vermeintlichen Sicherheitslücken anschlagen, obwohl die unsichere Funktionalität im Container gar nicht genutzt wird. Gleiches bei Debian-Paketen, die auch nur Sicherheitskorrekturen backporten, ohne auf eine neue Version zu aktualisieren. Ein Vergleich der Versionsnummer meldet eine Sicherheitslücke, die real nicht existiert.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!