Aussehen
Suche Einloggen
[c] [meta] [fefe] [erp]

/c/ – Eine der letzten echten Webseiten


Antwort erstellen

(≤ 4)



[Zurück]

  • [l] Effe##Mod Fri, 22 May 2026 05:45:50 GMT Nr. 162836
    JPG 424×323 18.7k
    Benutzt hier jemand nginx? [0] [1] [2] [3] [4] [5]

    Es handelt sich hier um zwei verschiedene Sicherheitslücken, die kurz hintereinander gefunden wurden. Die erste, CVE-2026-42945, ist mittlerweile ca. eine Woche alt, und "behoben", allerdings wurde das zugrundeliegende Problem nicht behoben. Nun gibt es eine weitere, die sich "nginx-poolslip" nennt und auf der ersten aufbaut. Diese hat anscheinend noch keine CVE und auch keinen Flicken, also eine echte 0-day, die auch bereits ausgenutzt wird.

    >Mitigation Measures
    >
    >Until an official fix is released, security teams are advised to take immediate precautionary steps:
    >
    > * Monitor NebSec and F5 security advisories for updates and patch releases
    > * Restrict exposure of NGINX administrative interfaces to reduce the attack surface
    > * Deploy Web Application Firewall (WAF) rules to filter malicious traffic
    > * Ensure ASLR is fully enabled (randomize_va_space set to 2)
    > * Audit configurations involving rewrite, if, and set directives, particularly those using unnamed PCRE capture groups
    > * Consider alternative architectures or memory-safe proxies for critical environments

    Mit Gatling wäre das nicht passiert

    [0] https://www.youtube.com/watch?v=vel8YW7eCzE
    [1] https://www.bleepingcomputer.com/news/security/18-year-old-nginx-vulnerability-allows-dos-potential-rce/
    [2] https://thehackernews.com/2026/05/nginx-cve-2026-42945-exploited-in-wild.html
    [3] https://cybersecuritynews.com/nginx-buffer-overflow-vulnerability/
    [4] https://cybersecuritynews.com/nginx-0-day-rce-nginx-poolslip/
    [5] 3 und 4 laden gerade selbst nicht, daher hier Sekundärquelle: https://gbhackers.com/new-nginx-0-day-rce-nginx-poolslip/amp/
  • [l] Felix Fri, 22 May 2026 07:57:03 GMT Nr. 162837
    i'm part of the global cybersecurity community
    i don fear no bugs i squash em
  • [l] Felix Fri, 22 May 2026 08:46:54 GMT Nr. 162838
    WEBM 1920×1040 0:23 9.8M
  • [l] Felix Fri, 22 May 2026 11:31:23 GMT Nr. 162844
    PNG 209×257 66.0k
    JPG 640×393 32.1k
    Die Quellen aus dem OP sind scheiße, weil da kein technischer Aufschrieb drin steckt.
    Felix will schon wissen, was genau wo, in welcher C-Funktion, aufgrund welcher Fehler da genau schief läuft.

    Eigentlich müsste man es mal zur zwingenden Bedingung machen, auch einen technischen Aufschrieb einreichen und veröffentlichen zu müssen, wenn man eine CVE-Nummer beantragen möchte.

    Für die erste Lücke (CVE-2026-42945) hat er das hier gefunden:
    https://depthfirst.com/research/nginx-rift-achieving-nginx-rce-via-an-18-year-old-vulnerability

    Für die zweite Lücke (keine CVE-Nummer?!) hat er nur gefunden:
    >We will release the full technical writeup with ASLR bypass 30 days after the patch on nebusec.ai.
    https://x.com/nebusecurity/status/2057071579876753643

    Es versteht sich von selbst, dass beide Finder natürlich die Lücke nutzen, um ihre KI-Weichware lüften.

    Die komplette Übersicht über alle Lücken in nginx gibt es hier (die neue ohne CVE-Nummer):
    https://nginx.org/en/security_advisories.html

    Dankt mir später.
  • [l] Felix Fri, 22 May 2026 17:15:17 GMT Nr. 162847
    >>162844
    Danke Felix, gleich mal aktualisiert.
    Die Tatsache, dass in "nginx-poolslip" die verwundbare Binärdatei mit -O1 -g kompiliert wurde, ist schon einmal aromatisch – wäre amüsant, wenn GCC bzw. LLVM auf üblichem Optimierungslevel den Exploit einfach wegoptimieren und er nicht bloß z. B. vom Stack-Protector gefressen wird.

    Gatling hätte grundsätzlich dasselbe Problem, da der Gabelsklave sich nicht erneut ausführt, um ein anderes Speicherlayout als der Hauptprozess zu erhalten. Allerdings ist er auch nur für CGI und nicht wie bei nginx für alles verantwortlich und würde auch nicht neu gestartet werden, wenn er stirbt.
  • [l] Felix Fri, 22 May 2026 18:15:03 GMT Nr. 162848
    >>162847
    >und würde auch nicht neu gestartet werden, wenn er stirbt.
    Richtig, denn wenn es abschmiert, dann muss es so richtig krachen!

    Außerdem hat Gatling selbstverständlich keine Bugs.


[Zurück]
[c] [meta] [fefe] [erp]