If a Jetty OpenIdAuthenticator uses the optional nested LoginService, and that LoginService decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated.

So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the LoginService.

Impact This impacts usages of the jetty-openid which have configured a nested LoginService and where that LoginService will is capable of rejecting previously authenticated users.

Original Report working on a custom OpenIdAuthenticator, I discovered the following: https://github.com/eclipse/jetty.project/blob/jetty-10.0.14/jetty-openid/src/main/java/org/eclipse/jetty/security/openid/OpenIdAuthenticator.java#L505 In the case where the LoginService does return that the authentication has been revoked (from the validate() call on line 463), the OpenIdAuthenticator removes the authentication from the session; however the current request still proceeds as if authenticated, since it falls through to "return authentication" on line 505. This is fixed by moving the line 505 (and associated debug log) inside the else block that ends on line 502, instead of outside it. Then the revocation case will run through to line 517 and will trigger a new OpenId authentication which I think is correct. I think this revocation can only occur if you do attach a separate LoginService to the OpenIdLoginService, but in that case the revoked authentication will still let the next request through (and possibly more than one if they are very close to simultaneous). Technically I think this is a security vulnerability, if a very minor one, so I'm sending this off-list.

Patched Versions

Fixed in Jetty Versions: 9.4.52 - fixed in PR https://github.com/eclipse/jetty.project/pull/9660 10.0.16 - fixed in PR https://github.com/eclipse/jetty.project/pull/9528 11.0.16 - fixed in PR https://github.com/eclipse/jetty.project/pull/9528 12.0.0 - not impacted (already has fix)

Workaround Upgrade your version of Jetty.

References https://github.com/eclipse/jetty.project/pull/9528 https://github.com/eclipse/jetty.project/pull/9660

Impact

Jetty accepts the '+' character proceeding the content-length value in a HTTP/1 header field. This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses. There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response.

Workarounds

There is no workaround as there is no known exploit scenario.

Original Report

RFC 9110 Secion 8.6 defined the value of Content-Length header should be a string of 0-9 digits. However we found that Jetty accepts "+" prefixed Content-Length, which could lead to potential HTTP request smuggling.

Payload:

POST / HTTP/1.1 Host: a.com Content-Length: +16 Connection: close ​ 0123456789abcdef

When sending this payload to Jetty, it can successfully parse and identify the length.

When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request.

This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS.

Eclipse Jetty Canonical Repository is the canonical repository for the Jetty project. Users of the CgiServlet with a very specific command structure may have the wrong command executed. If a user sends a request to a org.eclipse.jetty.servlets.CGI Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. This issue was patched in version 9.4.52, 10.0.16, 11.0.16 and 12.0.0-beta2.

Incomplete Cleanup vulnerability in Apache Tomcat.

When recycling various internal objects in Apache Tomcat from 11.0.0-M1 through 11.0.0-M11, from 10.1.0-M1 through 10.1.13, from 9.0.0-M1 through 9.0.80 and from 8.5.0 through 8.5.93, an error could cause Tomcat to skip some parts of the recycling process leading to information leaking from the current request/response to the next.

Users are recommended to upgrade to version 11.0.0-M12 onwards, 10.1.14 onwards, 9.0.81 onwards or 8.5.94 onwards, which fixes the issue.

Improper Input Validation vulnerability in Apache Tomcat.

Tomcat from 11.0.0-M1 through 11.0.0-M11, from 10.1.0-M1 through 10.1.13, from 9.0.0-M1 through 9.0.81 and from 8.5.0 through 8.5.93 did not correctly parse HTTP trailer headers. A specially crafted, invalid trailer header could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy.

Users are recommended to upgrade to version 11.0.0-M12 onwards, 10.1.14 onwards, 9.0.81 onwards or 8.5.94 onwards, which fix the issue.

Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with " (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: DISPLAYLANGUAGE="b; JSESSIONID=1337; c=d" will be parsed as one cookie, with the name DISPLAYLANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAYLANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAYLANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue.

A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high.

A race condidition in systemd-coredump allows a local attacker to crash a SUID program and gain read access to the resulting core dump

Null pointer dereference when composing from a specially crafted draft message in Mutt >1.5.2 <2.2.12

Null pointer dereference when viewing a specially crafted email in Mutt 1.5.2 <2.2.12

Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

Fixed bug (Memory corruption (zendmmheap corrupted) in opensslencrypt with AES-WRAP-PAD). (CVE-2026-14355)

A use-after-free flaw was found in the xorg-x11-server. An X server crash may occur in a very specific and legacy configuration (a multi-screen setup with multiple protocol screens, also known as Zaphod mode) if the pointer is warped from within a window on one screen to the root window of the other screen and if the original window is destroyed followed by another window being destroyed.

Last updated 21 August 2024

Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

A flaw in the Linux Kernel found in the GFS2 file system. On corrupted gfs2 file systems the evict code can try to reference the journal descriptor structure, jdesc, after it has been freed and set to NULL. It can lead to null pointer dereference when gfs2transbegin being called and then fail ingfs2evictinode().

Reference: https://listman.redhat.com/archives/cluster-devel/2023-April/023914.html

A directory traversal problem in the URL decoder of librsvg before 2.56.3 could be used by local or remote attackers to disclose files (on the local filesystem outside of the expected area), as demonstrated by href=".?../../../../../../../../../../etc/passwd" in an xi:include element.

A website could have obscured the fullscreen notification by using a URL with a scheme handled by an external program, such as a mailto URL. This could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox < 115, Firefox ESR < 102.13, and Thunderbird < 102.13.

A Type Confusion vulnerability was found in Samba's mdssvc RPC service for Spotlight. When parsing Spotlight mdssvc RPC packets, one encoded data structure is a key-value style dictionary where the keys are character strings, and the values can be any of the supported types in the mdssvc protocol. Due to a lack of type checking in callers of the dallocvalueforkey() function, which returns the object associated with a key, a caller may trigger a crash in tallocgetsize() when talloc detects that the passed-in pointer is not a valid talloc pointer. With an RPC worker process shared among multiple client connections, a malicious client or attacker can trigger a process crash in a shared RPC mdssvc worker process, affecting all other clients this worker serves.

A path disclosure vulnerability was found in Samba. As part of the Spotlight protocol, Samba discloses the server-side absolute path of shares, files, and directories in the results for search queries. This flaw allows a malicious client or an attacker with a targeted RPC request to view the information that is part of the disclosed path.

A vulnerability was found in PostgreSQL with the use of the MERGE command, which fails to test new rows against row security policies defined for UPDATE and SELECT. If UPDATE and SELECT policies forbid some rows that INSERT policies do not forbid, a user could store such rows.

An implementation flaw was discovered in the AES cipher in the Hotspot component of OpenJDK. This could weaken the cipher protection and lead to confidentiality issue.

========== 2. OOB read of XFRMAMTIMERTHRESH nlattr ==========

[require privilege]: CAPNETADMIN

[effects]: information leak

[crash stack]: Interesting enough as this OOB read will not be detected by KASan (perhaps why this bug is not detected by the fuzzer), see the details below.

[buggy commit]: 4e484b3e969b ("xfrm: rate limit SA mapping change message to user space")

[root cause]: The mentioned commit above added one additional attribute named XFRMAMTIMERTHRESH and described its type at compatpolicy (net/xfrm/xfrmcompat.c). However, the author forgot to also describe it at xfrmapolicy (net/xfrm/xfrmuser.c). Hence, this suppose NLAU32 (4 bytes) value can be faked as empty (0 bytes) by a malicious user, which lead to 4 bytes overflow read when parsing nlattrs.

The overall buffer skb is created at netlinksendmsg(...). According to the code, it will add another 0x140 skbsharedinfo data behind the skb data so this OOB will not be detected by KASan.

To exploit this (see PoC part), one malicious user can spray the SLUB objects and then leverage this 4 bytes OOB read to leak the heap data into x->mappingmaxage (see xfrmupdateaeparams(...)), and leak it to userspace via copytouserstateextra(...).

[PoC code]: see attachment poc2.c. I have tested it in latest Linux with QEMU. (no effects in ubuntu thanks to CONFIGINITONALLOCDEFAULTON)

[suggest fix]: Just add the type description like below

@@ -3035,6 +3035,7 @@ const struct nlapolicy xfrmapolicy[XFRMAMAX+1] = { [XFRMASETMARK] = { .type = NLAU32 }, [XFRMASETMARKMASK] = { .type = NLAU32 }, [XFRMAIFID] = { .type = NLAU32 }, + [XFRMAMTIMERTHRESH] = { .type = NLAU32 }, };

========== 1. Null-ptr-deref in xfrmupdateaeparams() ==========

[require privilege]: CAPNETADMIN

[effects]: local DoS

[crash stack]: [ 47.933119] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 47.933119] #PF: supervisor write access in kernel mode [ 47.933119] #PF: errorcode(0x0002) - not-present page [ 47.933119] PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0 [ 47.933119] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI [ 47.933119] CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8 [ 47.933119] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4 [ 47.933119] RIP: 0010:memcpyorig+0xad/0x140 [ 47.933119] Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c [ 47.933119] RSP: 0018:ffff888008f57658 EFLAGS: 00000202 [ 47.933119] RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571 [ 47.933119] RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000 [ 47.933119] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 47.933119] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818 [ 47.933119] R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000 [ 47.933119] FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000 [ 47.933119] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 47.933119] CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0 [ 47.933119] Call Trace: [ 47.933119] <TASK> [ 47.933119] ? die+0x1f/0x70 [ 47.933119] ? pagefaultoops+0x1e8/0x500 [ 47.933119] ? pfxisprefetch.constprop.0+0x10/0x10 [ 47.933119] ? pfxpagefaultoops+0x10/0x10 [ 47.933119] ? rawspinunlockirqrestore+0x11/0x40 [ 47.933119] ? fixupexception+0x36/0x460 [ 47.933119] ? rawspinunlockirqrestore+0x11/0x40 [ 47.933119] ? excpagefault+0x5e/0xc0 [ 47.933119] ? asmexcpagefault+0x26/0x30 [ 47.933119] ? xfrmupdateaeparams+0xd1/0x260 [ 47.933119] ? memcpyorig+0xad/0x140 [ 47.933119] ? pfxrawspinlockbh+0x10/0x10 [ 47.933119] xfrmupdateaeparams+0xe7/0x260 [ 47.933119] xfrmnewae+0x298/0x4e0 [ 47.933119] ? pfxxfrmnewae+0x10/0x10 [ 47.933119] xfrmuserrcvmsg+0x25a/0x410 [ 47.933119] ? pfxxfrmuserrcvmsg+0x10/0x10 [ 47.933119] ? allocskb+0xcf/0x210 [ 47.933119] ? stacktracesave+0x90/0xd0 [ 47.933119] ? filterirqstacks+0x1c/0x70 [ 47.933119] ? stackdepotsave+0x39/0x4e0 [ 47.933119] ? kasanslabfree+0x10a/0x190 [ 47.933119] ? kmemcachefree+0x9c/0x340 [ 47.933119] ? netlinkrecvmsg+0x23c/0x660 [ 47.933119] ? sockrecvmsg+0xeb/0xf0 [ 47.933119] ? sysrecvfrom+0x13c/0x1f0 [ 47.933119] ? x64sysrecvfrom+0x71/0x90 [ 47.933119] ? dosyscall64+0x3f/0x90 [ 47.933119] ? entrySYSCALL64afterhwframe+0x72/0xdc [ 47.933119] ? copyout+0x3e/0x50 [ 47.933119] netlinkrcvskb+0xd6/0x210 [ 47.933119] ? pfxxfrmuserrcvmsg+0x10/0x10 [ 47.933119] ? pfxnetlinkrcvskb+0x10/0x10 [ 47.933119] ? pfxsockhasperm+0x10/0x10 [ 47.933119] ? mutexlock+0x8d/0xe0 [ 47.933119] ? pfxmutexlock+0x10/0x10 [ 47.933119] xfrmnetlinkrcv+0x44/0x50 [ 47.933119] netlinkunicast+0x36f/0x4c0 [ 47.933119] ? pfxnetlinkunicast+0x10/0x10 [ 47.933119] ? netlinkrecvmsg+0x500/0x660 [ 47.933119] netlinksendmsg+0x3b7/0x700 [ 47.933119] ? pfxnetlinksendmsg+0x10/0x10 [ 47.933119] ? updateloadavg+0x591/0xab0 [ 47.933119] ? pfxnetlinksendmsg+0x10/0x10 [ 47.933119] socksendmsg+0xde/0xe0 [ 47.933119] syssendto+0x18d/0x230 [ 47.933119] ? pfxsyssendto+0x10/0x10 [ 47.933119] ? rbinsertcolor+0x1c0/0x280 [ 47.933119] ? timerqueueadd+0x128/0x150 [ 47.933119] ? ktimeget+0x49/0xb0 [ 47.933119] ? pfxnativeapicmemwrite+0x10/0x10 [ 47.933119] ? lapicnextevent+0x35/0x40 [ 47.933119] ? clockeventsprogramevent+0xdf/0x140 [ 47.933119] ? hrtimerinterrupt+0x321/0x360 [ 47.933119] x64syssendto+0x71/0x90 [ 47.933119] dosyscall64+0x3f/0x90 [ 47.933119] entrySYSCALL64afterhwframe+0x72/0xdc [ 47.933119] RIP: 0033:0x44b8aa [ 47.933119] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 9 [ 47.933119] RSP: 002b:00007fff7ded8258 EFLAGS: 00000246 ORIGRAX: 000000000000002c [ 47.933119] RAX: ffffffffffffffda RBX: 00007fff7ded9688 RCX: 000000000044b8aa [ 47.933119] RDX: 00000000000002a8 RSI: 00007fff7ded8480 RDI: 0000000000000003 [ 47.933119] RBP: 00007fff7ded82c0 R08: 00007fff7ded829c R09: 000000000000000c [ 47.933119] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 [ 47.933119] R13: 00007fff7ded9678 R14: 00000000004c37d0 R15: 0000000000000001 [ 47.933119] </TASK> [ 47.933119] Modules linked in: [ 47.933119] CR2: 0000000000000000 [ 47.933119] ---[ end trace 0000000000000000 ]--- [ 47.933119] RIP: 0010:memcpyorig+0xad/0x140 [ 47.933119] Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c [ 47.933119] RSP: 0018:ffff888008f57658 EFLAGS: 00000202 [ 47.933119] RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571 [ 47.933119] RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000 [ 47.933119] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 47.933119] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818 [ 47.933119] R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000 [ 47.933119] FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000 [ 47.933119] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 47.933119] CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0 [ 47.933119] Kernel panic - not syncing: Fatal exception in interrupt [ 47.933119] Kernel Offset: disabled [ 47.933119] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

[buggy commit]: d8647b79c3b7 ("xfrm: Add user interface for esn and big anti-replay windows")

[root cause]: x->replayesn and x->preplayesn should be allocated at xfrmallocreplaystateesn(...) in xfrmstateconstruct(..), and then the xfrmupdateaeparams(...) is okay to update them. However, the current implementation allows a malicious user to directly dereference the pointer and crash the kernel like above.

[PoC code]: see attachment poc1.c. I have tested it in ubuntu 22.04 and latest Linux with QEMU.

[suggest fix]: Add NULL check in xfrmupdateaeparams() like below:

@@ -628,7 +628,7 @@ static void xfrmupdateaeparams(struct xfrmstate x, struct nlattr attrs, struct nlattr rt = attrs[XFRMAREPLAYTHRESH]; struct nlattr mt = attrs[XFRMAMTIMERTHRESH];

- if (re) { + if (re && x->replayesn && x->preplayesn) { struct xfrmreplaystateesn replayesn;

A side channel attack known as ‘Inception’ or ‘RAS Poisoning’ may allow an attacker to influence branch prediction, potentially leading to information disclosure.

Refer: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7005.html

A flaw in the Linux Kernel found in drivers/media/dvb-core/dvbfrontend.c. There is a blocking operation when a task is in !TASKRUNNING. In dvbfrontendgetevent, waiteventinterruptible is called; the condition is dvbfrontendtestevent(fepriv,events). In dvbfrontendtestevent, down(&fepriv->sem) is called. However, waiteventinterruptible would put the process to sleep, and down(&fepriv->sem) may block the process.

Reference: https://lore.kernel.org/all/CA+UBctCu7fXn4q41O3=id1+OdyQ85tZY1x+TkT-6OVBL6KAUw@mail.gmail.com/

A use-after-free vulnerability was found in the siano smsusb module in the Linux kernel. The bug occurs during device initialization when the siano device is plugged in. This flaw allows a local user to crash the system, causing a denial of service condition.

Gather Date Sampling (GDS) is a transient execution side channel vulnerability affecting certain Intel processor. In this flaw, a local attack using gather instruction (load from memory) may infer stale data from previously used vector registers on the same physical core.

A flaw found in the Linux Kernel. The tun/tap sockets have their socket UID hardcoded to 0 due to a type confusion in their initialization function. While it will be often correct, as tuntap devices require CAPNETADMIN, it may not always be the case, e.g., a non-root user only having that capability. This would make tun/tap sockets being incorrectly treated in filtering/routing decisions, possibly bypassing network filters. The original fix for the CVE-2023-1076 was incorrect. The problem is that the following upstream commits (that were fix for the CVE-2023-1076) - a096ccca6e50 ("tun: tunchropen(): correctly initialize socket uid"), - 66b2c338adce ("tap: tapopen(): correctly initialize socket uid"), pass "inode->iuid" to sockinitdatauid() as the last parameter and that turns out to be entirely bogus.

References: https://lore.kernel.org/all/20230731164237.48365-1-lersek@redhat.com/ https://lore.kernel.org/all/20230731164237.48365-2-lersek@redhat.com/ https://lore.kernel.org/all/20230731164237.48365-3-lersek@redhat.com/