A Server-Side Request Forgery (SSRF) bypass vulnerability exists in “stunnel” 5.79 and lower when configured in SOCKS proxy mode. This flaw allows a client to bypass intended localhost restrictions by using IPv4-mapped IPv6 addresses (e.g., “::ffff:127.0.0.1”) or unspecified addresses ("0.0.0.0", "::"), enabling access to loopback-only services on the "stunnel" host that should not be network-reachable.

AIONLYREPORT package: stunnel-5.72-8.el10 ------ Summary: SSRF Bypass in SOCKS Proxy via 0.0.0.0 and IPv4-mapped IPv6 Addresses: stunnel configured with protocol = socks rejects only 127.0.0.0/8 and ::1, allowing a client to bypass the localhost filter via ::ffff:127.0.0.1 and, on some platforms, 0.0.0.0 or :: to reach loopback-only services on the stunnel host. Requirements to exploit: The package must be deployed in SOCKS server mode (protocol = socks), the attacker must be able to reach that listener, and a service of interest must be bound to loopback on the stunnel host. Some deployments may additionally gate access with network policy or TLS client authentication. The strongest reproduced bypass uses ::ffff:127.0.0.1; the 0.0.0.0 and :: variants are additional edge cases and may be OS-dependent. Component affected: stunnel-5.72-8.el10, src/protocol.c, validateconnectaddr() in the SOCKS server request path Version affected: stunnel-5.72-8.el10 when configured with protocol = socks Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L - 8.1 (HIGH) AV:N - A reachable protocol = socks listener can be attacked over the network with a crafted SOCKS request. AC:L - The bypass only requires a crafted destination address and no race or unusual precondition once the listener is reachable. PR:N - The SOCKS server path accepts the 0x00 no-authentication method; no prior privileges on the host are required. UI:N - No user interaction is required. S:U - The issue is an access-control failure in stunnel's own destination validation and is scored within that service boundary. C:H - Successful exploitation can expose loopback-only administrative, metadata, or data-bearing services that were intentionally not network-reachable. I:L - Some local services may accept state-changing requests once the loopback-only boundary is bypassed, but that impact is deployment-dependent. A:L - Unintended requests to local services can also create limited service disruption or load. Impact: Important. When stunnel is deployed as a reachable SOCKS server, a client that can reach the listener can bypass the intended localhost restriction and access services that should only be reachable from the local host. Under Red Hat's guidance this is closer to Important than Moderate because it can expose protected resources to a remote client of the vulnerable service and may enable limited integrity or availability impact as a follow-on. It is not Critical because it does not by itself provide system compromise or code execution, and it is limited to the supported but non-default protocol = socks configuration. Embargo: no Reason: The issue is limited to deployments that intentionally enable protocol = socks, and operators can immediately reduce exposure by disabling or tightly restricting the SOCKS listener. It is serious for affected deployments, but it is not a default-path or wormable compromise. Acknowledgement: Aisle Research Vulnerability Details: The directly observed flaw is an incomplete destination filter in validateconnectaddr(). The function rejects IPv4 loopback (127.0.0.0/8) and exact IPv6 loopback (::1), but it does not reject IPv4-mapped IPv6 loopback such as ::ffff:127.0.0.1, and it also leaves the unspecified addresses 0.0.0.0 and :: unchecked. c NOEXPORT int validateconnectaddr(CLI c) { #ifdef USEIPv6 const unsigned char ipv6loopback[16]={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}; #endif unsigned i; for(i=0; i<c->connectaddr.num; ++i) { SOCKADDRUNION addr=&c->connectaddr.addr[i]; #ifdef USEIPv6 if(addr->sa.safamily==AFINET6) { if(!memcmp(&addr->in6.sin6addr, ipv6loopback, 16)) { slog(LOGERR, "SOCKS connection to the IPv6 loopback rejected"); return 0; } / TODO: implement more checks / } else #endif if(addr->sa.safamily==AFINET) { if((ntohl(addr->in.sinaddr.saddr)&0xff000000)==0x7f000000) { slog(LOGERR, "SOCKS connection to the IPv4 loopback rejected"); return 0; } / TODO: implement more checks / } else { slog(LOGERR, "Unsupported address type 0x%02x", addr->sa.safamily); return 0; } } return 1; } The same validation helper is used before the normal outbound connect path (connectremote() -> sconnect() -> connect()). As a result, a client can supply ::ffff:127.0.0.1 and reach a service bound only to loopback on the stunnel host. The 0.0.0.0 and :: variants should be treated more cautiously because their behavior is OS-dependent, but they remain unfiltered edge cases. The strongest reproduced case is the IPv4-mapped IPv6 loopback path on IPv6-enabled builds. The downstream impact depends on what services are bound to loopback and whether those services apply their own authentication. Steps to reproduce: 1. Configure stunnel SOCKS server: ini [socksserver] protocol = socks accept = 127.0.0.1:9080 cert = stunnel.pem key = stunnel.key 2. Start a localhost-only target service on the same host: bash nc -lv 127.0.0.1 18080 3. Open a TLS session to stunnel and perform SOCKS5 handshake: bash openssl sclient -quiet -connect 127.0.0.1:9080 4. Send method negotiation bytes 05 01 00. 5. Send a connect request to ::ffff:127.0.0.1:18080: 05 01 00 04 00000000000000000000ffff7f000001 46a0 6. Observe stunnel replies success (REP=0x00) and data reaches the localhost listener. 7. Repeat with 0.0.0.0 / :: as additional edge cases; these may be OS-dependent, while IPv4-mapped IPv6 loopback is the strongest reproducible bypass case. Mitigation: If SOCKS proxying is not required, disable protocol = socks. Otherwise do not expose the SOCKS listener to untrusted clients, keep it bound to loopback or a trusted management network where possible, and enforce any available client-authentication or network ACL controls until a code fix is shipped. Proposed Fix: A minimal fix is to reject IPv4 and IPv6 unspecified addresses and to detect IPv4-mapped IPv6 loopback before returning success from validateconnectaddr(). diff diff --git a/src/protocol.c b/src/protocol.c @@ NOEXPORT int validateconnectaddr(CLI c) { #ifdef USEIPv6 const unsigned char ipv6loopback[16]={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}; + const unsigned char ipv6any[16]={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; #endif @@ #ifdef USEIPv6 if(addr->sa.safamily==AFINET6) { if(!memcmp(&addr->in6.sin6addr, ipv6loopback, 16)) { slog(LOGERR, "SOCKS connection to the IPv6 loopback rejected"); return 0; } + if(!memcmp(&addr->in6.sin6addr, ipv6any, 16)) { + slog(LOGERR, + "SOCKS connection to the IPv6 unspecified address rejected"); + return 0; + } + if(!memcmp(addr->in6.sin6addr.s6addr, + "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff", 12) && + ((addr->in6.sin6addr.s6addr[12] & 0xff)==0x7f)) { + slog(LOGERR, + "SOCKS connection to the IPv4-mapped IPv6 loopback rejected"); + return 0; + } / TODO: implement more checks / } else #endif if(addr->sa.safamily==AFINET) { + if(ntohl(addr->in.sinaddr.saddr)==0x00000000) { + slog(LOGERR, + "SOCKS connection to the IPv4 unspecified address rejected"); + return 0; + } if((ntohl(addr->in.sinaddr.saddr)&0xff000000)==0x7f000000) { slog(LOGERR, "SOCKS connection to the IPv4 loopback rejected"); return 0; } ------ This report was generated using AI technology. Always review AI-generated content prior to use

A stack-based out-of-bounds read vulnerability exists in the "svlog" function of stunnel, when handling oversized log messages via "vsnprintf". A remote attacker with network access to a stunnel service can send protocol inputs that trigger a log message longer than 1024 bytes, leading to an out-of-bounds stack read and a potential crash. In certain corner cases, the same vulnerability could be used to replace a series of trailing "\n" characters with "\0".

AIONLYREPORT package: stunnel-5.72-8.el10 ------ Summary: Stack-based Out-of-Bounds Read/Write in svlog via vsnprintf Misuse: an oversized attacker-controlled log message can make svlog index past its 1024-byte stack buffer during newline stripping, causing an out-of-bounds stack read and a possible out-of-bounds write that can destabilize the process. Requirements to exploit: A remote attacker needs network access to a stunnel-5.72-8.el10 service configured for server-side IMAP protocol negotiation (protocol = imap) and must be able to send an unexpected IMAP command line longer than 1024 bytes but below the fdgetline 64KB guard. The demonstrated logging path emits at LOGERR, which is commonly enabled with the default debug = notice setting. Component affected: stunnel-5.72-8.el10, specifically src/log.c in svlog, with a demonstrated remote trigger path through src/protocol.c imapservermiddle and src/network.c fdgetline Version affected: stunnel-5.72-8.el10 Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - 7.5 (HIGH) AV:N - The demonstrated trigger is over the network by sending an oversized IMAP command to a reachable stunnel service in the affected protocol mode. AC:L - No race or unusual precondition is required beyond the affected configuration; a long unexpected command line is sufficient. PR:N - The demonstrated path does not require prior authentication. UI:N - No user interaction is required once the service is exposed. S:U - The invalid memory access occurs within the stunnel process. C:N - The available evidence shows an out-of-bounds read used for newline checking, but does not establish disclosure of memory contents to the attacker. I:N - A possible out-of-bounds write exists, but the report does not establish a reliable or attacker-controlled integrity impact. A:H - The invalid stack access can abort or destabilize the affected process, and repeated unauthenticated requests can be used to deny service in affected configurations. Impact: Moderate. Based on Red Hat's severity guidance, the currently supported impact is a remotely triggerable denial-of-service condition in specific protocol configurations rather than a broadly reachable default-path failure or a demonstrated confidentiality, integrity, or code-execution compromise. That makes the issue more constrained than a typical Important remote DoS and better fits Moderate. Embargo: no Reason: The demonstrated impact is denial of service in a configuration-dependent protocol path, with no established privilege escalation or code execution. Exposure can also be reduced operationally by disabling or restricting the affected protocol mode until a fix is shipped. Acknowledgement: Aisle Research Vulnerability Details: In src/log.c, svlog measures the formatted length, caps that length at 1024 for stack allocation, and then overwrites len with the return value from the second vsnprintf call. Because vsnprintf returns the full would-have-been output length, len can again exceed the allocated buffer size before the newline-stripping loop runs: c vacopy(aq, ap); len=vsnprintf(NULL, 0, format, ap); if(len>1024) len=1024; text=alloca((sizet)len+1); len=vsnprintf(text, (sizet)len+1, format, aq); vaend(aq); while(len>0 && text[len-1]=='\n') text[--len]='\0'; If the formatted output is longer than 1024 bytes, text[len-1] reads past the end of the stack buffer. If the out-of-bounds byte happens to be '\n', the loop also writes '\0' out of bounds. The demonstrated remote path is in server-side IMAP negotiation: fdgetline accepts client lines until its ptr>65536 guard triggers, and imapservermiddle logs attacker-controlled command text on error: c slog(LOGERR, "Unexpected client command %s", tail); A remote client can therefore send an unexpected IMAP command longer than 1024 bytes and cause the resulting %s expansion to reach the vulnerable code. The available reproduction evidence shows an ASan-detected invalid read at text[len-1]; without sanitizers, the exact manifestation depends on adjacent stack state, but denial of service is a reasonable outcome. A reliable confidentiality or integrity impact was not established from the available technical evidence. Steps to reproduce: 1. Build stunnel-5.72-8.el10 with sanitizers enabled: bash CFLAGS="-O1 -g -fsanitize=address,undefined -fno-omit-frame-pointer" ./configure make -j 2. Configure a service using server-side IMAP protocol negotiation (protocol = imap) and start stunnel. 3. Connect as a client and send an oversized unexpected IMAP command line longer than 1024 bytes, ending with \r\n. 4. Ensure the request reaches fdgetline in src/network.c, then slog(LOGERR, "Unexpected client command %s", tail); in src/protocol.c, and finally the newline-stripping loop in svlog in src/log.c. 5. Observe an ASan invalid read, and potentially an invalid write, in svlog around text[len-1]. Mitigation: Until a fixed build is available, avoid exposing services configured with server-side IMAP protocol negotiation to untrusted clients, or restrict those services to trusted networks. Lowering log verbosity is not a reliable mitigation for the demonstrated path because it logs at LOGERR. Proposed Fix: Clamp negative and oversized results from the second vsnprintf call before reusing len in the newline-stripping loop. diff diff --git a/src/log.c b/src/log.c — a/src/log.c +++ b/src/log.c @@ -195,12 +195,19 @@ void svlog(int level, const char format, valist ap) { / format the text to be logged / vacopy(aq, ap); len=vsnprintf(NULL, 0, format, ap); + if(len<0) + len=0; if(len>1024) len=1024; text=alloca((sizet)len+1); len=vsnprintf(text, (sizet)len+1, format, aq); + { + int actuallen=vsnprintf(text, (sizet)len+1, format, aq); + if(actuallen<0) + actuallen=0; + if(actuallen>len) + actuallen=len; + len=actuallen; + } vaend(aq); while(len>0 && text[len-1]=='\n') text[--len]='\0'; / strip trailing newlines /

------ This report was generated using AI technology. Always review AI-generated content prior to use

A flaw was found in stunnel before 5.57, where it improperly validates client certificates when it is configured to use both redirect and verifyChain options. This flaw allows an attacker with a certificate signed by a Certificate Authority, which is not the one accepted by the stunnel server, to access the tunneled service instead of being redirected to the address specified in the redirect option. The highest threat from this vulnerability is to confidentiality.

Stunnel 5.00 through 5.13, when using the redirect option, does not redirect client connections to the expected server after the initial connection, which allows remote attackers to bypass authentication.

A flaw was found in the way stunnel, a socket wrapper which can provide SSL support to ordinary applications, performed (re)initialization of PRNG after fork. When accepting a new connection, the server forks and the child process handles the request. The RANDbytes() function of openssl doesn't reset its state after the fork, but seeds the PRNG with the output of time(NULL). The most important consequence is that servers using EC (ECDSA) or DSA certificates may under certain conditions leak their private key.

A flaw was found in the way stunnel, a socket wrapper which can provide SSL support to ordinary applications, performed (re)initialization of PRNG after fork. When accepting a new connection, the server forks and the child process handles the request. The RANDbytes() function of openssl doesn't reset its state after the fork, but seeds the PRNG with the output of time(NULL). The most important consequence is that servers using EC (ECDSA) or DSA certificates may under certain conditions leak their private key.

stunnel 4.21 through 4.54, when CONNECT protocol negotiation and NTLM authentication are enabled, does not correctly perform integer conversion, which allows remote proxy servers to execute arbitrary code via a crafted request that triggers a buffer overflow.

stunnel 4.40 and 4.41 might allow remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) via unspecified vectors.

The OCSP functionality in stunnel before 4.24 does not properly search certificate revocation lists (CRL), which allows remote attackers to bypass intended access restrictions by using revoked certificates.

Unspecified vulnerability in stunnel before 4.23, when running as a service on Windows, allows local users to gain privileges via unknown attack vectors.

Stunnel 4.00, and 3.24 and earlier, leaks a privileged file descriptor returned by listen(), which allows local users to hijack the Stunnel server.

stunnel 4.0.3 and earlier allows attackers to cause a denial of service (crash) via SIGCHLD signal handler race conditions that cause an inconsistency in the child counter.

OpenSSL does not use RSA blinding by default, which allows local and remote attackers to obtain the server's private key by determining factors using timing differences on (1) the number of extra reductions during Montgomery reduction, and (2) the use of different integer multiplication algorithms ("Karatsuba" and normal).

Format string vulnerability in stunnel before 3.22 when used in client mode for (1) smtp, (2) pop, or (3) nntp allows remote malicious servers to execute arbitrary code.

Format string vulnerability in stunnel 3.8 and earlier allows attackers to execute arbitrary commands via a malformed ident username.