Compare commits

...

10 Commits

Author SHA1 Message Date
openeuler-ci-bot
6457a390c5
!138 fix CVE-2024-25617
From: @willwolf 
Reviewed-by: @robertxw 
Signed-off-by: @robertxw
2024-02-20 06:39:29 +00:00
willwolf
ea1392b76c fix CVE-2024-25617
Signed-off-by: willwolf <hehuazhen@huawei.com>
2024-02-19 15:59:33 +08:00
openeuler-ci-bot
b6694963ac
!132 [sync] PR-128: fix CVE-2024-23638
From: @openeuler-sync-bot 
Reviewed-by: @robertxw 
Signed-off-by: @robertxw
2024-01-26 03:24:00 +00:00
xinghe
a68b6c6153 fix CVE-2024-23638
(cherry picked from commit 1f611bd2e6d2756b6ff56dd35d811f4e0da7d87d)
2024-01-25 19:22:05 +08:00
openeuler-ci-bot
598076ce24
!124 [sync] PR-119: fix CVE-2023-50269
From: @openeuler-sync-bot 
Reviewed-by: @robertxw 
Signed-off-by: @robertxw
2023-12-19 01:17:36 +00:00
xh
ced15abdd1 fix CVE-2023-50269
(cherry picked from commit dec0999f972a9a1e12e05e260c3070e456d441db)
2023-12-18 15:13:10 +08:00
openeuler-ci-bot
bd8abbdd2f
!111 [sync] PR-107: fix CVE-2023-49285 CVE-2023-49286
From: @openeuler-sync-bot 
Reviewed-by: @sunsuwan 
Signed-off-by: @sunsuwan
2023-12-07 02:52:07 +00:00
yangl777
7147c4f70b fix CVE-2023-49285 CVE-2023-49286
(cherry picked from commit d8519a501cbb770729c96bf27d62d08502d2b19b)
2023-12-06 16:57:58 +08:00
openeuler-ci-bot
dac746618f
!103 [sync] PR-99: fix CVE-2023-46728
From: @openeuler-sync-bot 
Reviewed-by: @robertxw 
Signed-off-by: @robertxw
2023-11-09 06:20:34 +00:00
yangl777
27c27112e3 fix CVE-2023-46728
(cherry picked from commit 7df12a553b245a7a2da1fc0cef5c74f128fc8b83)
2023-11-09 09:36:40 +08:00
7 changed files with 2514 additions and 1 deletions

File diff suppressed because it is too large Load Diff

View File

@ -0,0 +1,34 @@
From 77b3fb4df0f126784d5fd4967c28ed40eb8d521b Mon Sep 17 00:00:00 2001
From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Wed, 25 Oct 2023 19:41:45 +0000
Subject: [PATCH] RFC 1123: Fix date parsing (#1538)
The bug was discovered and detailed by Joshua Rogers at
https://megamansec.github.io/Squid-Security-Audit/datetime-overflow.html
where it was filed as "1-Byte Buffer OverRead in RFC 1123 date/time
Handling".
Conflict:NA
Reference:https://github.com/squid-cache/squid/commit/77b3fb4df0f126784d5fd4967c28ed40eb8d521b
---
lib/rfc1123.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/lib/rfc1123.c b/lib/rfc1123.c
index e5bf9a4d705..cb484cc002b 100644
--- a/lib/rfc1123.c
+++ b/lib/rfc1123.c
@@ -50,7 +50,13 @@ make_month(const char *s)
char month[3];
month[0] = xtoupper(*s);
+ if (!month[0])
+ return -1; // protects *(s + 1) below
+
month[1] = xtolower(*(s + 1));
+ if (!month[1])
+ return -1; // protects *(s + 2) below
+
month[2] = xtolower(*(s + 2));
for (i = 0; i < 12; i++)

View File

@ -0,0 +1,84 @@
From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Fri, 27 Oct 2023 21:27:20 +0000
Subject: [PATCH] Exit without asserting when helper process startup fails
(#1543)
... to dup() after fork() and before execvp().
Assertions are for handling program logic errors. Helper initialization
code already handled system call errors correctly (i.e. by exiting the
newly created helper process with an error), except for a couple of
assert()s that could be triggered by dup(2) failures.
This bug was discovered and detailed by Joshua Rogers at
https://megamansec.github.io/Squid-Security-Audit/ipc-assert.html
where it was filed as 'Assertion in Squid "Helper" Process Creator'.
Conflict:NA
Reference:https://github.com/squid-cache/squid/commit/6014c6648a2a54a4ecb7f952ea1163e0798f9264
---
src/ipc.cc | 32 ++++++++++++++++++++++++++------
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/src/ipc.cc b/src/ipc.cc
index 40d34b475..1afc4d5cf 100644
--- a/src/ipc.cc
+++ b/src/ipc.cc
@@ -22,6 +22,11 @@
#include "SquidConfig.h"
#include "SquidIpc.h"
#include "tools.h"
+#include <cstdlib>
+
+#if HAVE_UNISTD_H
+#include <unistd.h>
+#endif
static const char *hello_string = "hi there\n";
#ifndef HELLO_BUF_SZ
@@ -362,6 +367,22 @@ ipcCreate(int type, const char *prog, const char *const args[], const char *name
}
PutEnvironment();
+
+ // A dup(2) wrapper that reports and exits the process on errors. The
+ // exiting logic is only suitable for this child process context.
+ const auto dupOrExit = [prog,name](const int oldFd) {
+ const auto newFd = dup(oldFd);
+ if (newFd < 0) {
+ const auto savedErrno = errno;
+ debugs(54, DBG_CRITICAL, "ERROR: Helper process initialization failure: " << name <<
+ Debug::Extra << "helper (CHILD) PID: " << getpid() <<
+ Debug::Extra << "helper program name: " << prog <<
+ Debug::Extra << "dup(2) system call error for FD " << oldFd << ": " << xstrerr(savedErrno));
+ _exit(EXIT_FAILURE);
+ }
+ return newFd;
+ };
+
/*
* This double-dup stuff avoids problems when one of
* crfd, cwfd, or debug_log are in the rage 0-2.
@@ -369,17 +390,16 @@ ipcCreate(int type, const char *prog, const char *const args[], const char *name
do {
/* First make sure 0-2 is occupied by something. Gets cleaned up later */
- x = dup(crfd);
- assert(x > -1);
- } while (x < 3 && x > -1);
+ x = dupOrExit(crfd);
+ } while (x < 3);
close(x);
- t1 = dup(crfd);
+ t1 = dupOrExit(crfd);
- t2 = dup(cwfd);
+ t2 = dupOrExit(cwfd);
- t3 = dup(fileno(debug_log));
+ t3 = dupOrExit(fileno(debug_log));
assert(t1 > 2 && t2 > 2 && t3 > 2);

View File

@ -0,0 +1,79 @@
commit 9f7136105bff920413042a8806cc5de3f6086d6d
Author: Thomas Leroy <32497783+p4zuu@users.noreply.github.com>
Date: Tue Nov 28 07:35:46 2023 +0000
Limit the number of allowed X-Forwarded-For hops (#1589)
Squid will ignore all X-Forwarded-For elements listed after the first 64
addresses allowed by the follow_x_forwarded_for directive. A different
limit can be specified by defining a C++ SQUID_X_FORWARDED_FOR_HOP_MAX
macro, but that macro is not a supported Squid configuration interface
and may change or disappear at any time.
Squid will log a cache.log ERROR if the hop limit has been reached.
This change works around problematic ACLChecklist and/or slow ACLs
implementation that results in immediate nonBlockingCheck() callbacks.
Such callbacks have caused many bugs and development complications. In
clientFollowXForwardedForCheck() context, they lead to indirect
recursion that was bound only by the number of allowed XFF entries,
which could reach thousands and exhaust Squid process call stack.
This recursion bug was discovered and detailed by Joshua Rogers at
https://megamansec.github.io/Squid-Security-Audit/xff-stackoverflow.html
where it was filed as "X-Forwarded-For Stack Overflow".
Conflict: src/client_side_request.cc context adapt
Reference: http://www.squid-cache.org/Versions/v5/SQUID-2023_10.patch
diff --git a/src/ClientRequestContext.h b/src/ClientRequestContext.h
index f5316f9cf6..8651d101ae 100644
--- a/src/ClientRequestContext.h
+++ b/src/ClientRequestContext.h
@@ -80,6 +80,10 @@ public:
#endif
ErrorState *error; ///< saved error page for centralized/delayed processing
bool readNextRequest; ///< whether Squid should read after error handling
+
+#if FOLLOW_X_FORWARDED_FOR
+ size_t currentXffHopNumber = 0; ///< number of X-Forwarded-For header values processed so far
+#endif
};
#endif /* SQUID_CLIENTREQUESTCONTEXT_H */
diff --git a/src/client_side_request.cc b/src/client_side_request.cc
index 2f49ca1495..890357835a 100644
--- a/src/client_side_request.cc
+++ b/src/client_side_request.cc
@@ -81,6 +81,11 @@
static const char *const crlf = "\r\n";
#if FOLLOW_X_FORWARDED_FOR
+
+#if !defined(SQUID_X_FORWARDED_FOR_HOP_MAX)
+#define SQUID_X_FORWARDED_FOR_HOP_MAX 64
+#endif
+
static void clientFollowXForwardedForCheck(allow_t answer, void *data);
#endif /* FOLLOW_X_FORWARDED_FOR */
@@ -486,8 +491,16 @@ clientFollowXForwardedForCheck(Acl::Answer answer, void *data)
/* override the default src_addr tested if we have to go deeper than one level into XFF */
Filled(calloutContext->acl_checklist)->src_addr = request->indirect_client_addr;
}
- calloutContext->acl_checklist->nonBlockingCheck(clientFollowXForwardedForCheck, data);
- return;
+ if (++calloutContext->currentXffHopNumber < SQUID_X_FORWARDED_FOR_HOP_MAX) {
+ calloutContext->acl_checklist->nonBlockingCheck(clientFollowXForwardedForCheck, data);
+ return;
+ }
+ const auto headerName = Http::HeaderLookupTable.lookup(Http::HdrType::X_FORWARDED_FOR).name;
+ debugs(28, DBG_CRITICAL, "ERROR: Ignoring trailing " << headerName << " addresses" <<
+ Debug::Extra << "addresses allowed by follow_x_forwarded_for: " << calloutContext->currentXffHopNumber <<
+ Debug::Extra << "last/accepted address: " << request->indirect_client_addr <<
+ Debug::Extra << "ignored trailing addresses: " << request->x_forwarded_for_iterator);
+ // fall through to resume clientAccessCheck() processing
}
}
--

View File

@ -0,0 +1,36 @@
From 5bede3305cabb9ac19babecf3ebaf64f43f7b53e Mon Sep 17 00:00:00 2001
From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Sun, 12 Nov 2023 09:33:20 +0000
Subject: [PATCH] Do not update StoreEntry expiration after errorAppendEntry()
(#1580)
errorAppendEntry() is responsible for setting entry expiration times,
which it does by calling StoreEntry::storeErrorResponse() that calls
StoreEntry::negativeCache().
This change was triggered by a vulnerability report by Joshua Rogers at
https://megamansec.github.io/Squid-Security-Audit/cache-uaf.html where
it was filed as "Use-After-Free in Cache Manager Errors". The reported
"use after free" vulnerability was unknowingly addressed by 2022 commit
1fa761a that removed excessively long "reentrant" store_client calls
responsible for the disappearance of the properly locked StoreEntry in
this (and probably other) contexts.
Conflict: context adapt
Reference: https://github.com/squid-cache/squid/commit/5bede3305cabb9ac19babecf3ebaf64f43f7b53e
---
src/cache_manager.cc | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/cache_manager.cc b/src/cache_manager.cc
index b5a9cbecd33..08445a517a9 100644
--- a/src/cache_manager.cc
+++ b/src/cache_manager.cc
@@ -306,7 +306,6 @@ CacheManager::start(const Comm::ConnectionPointer &client, HttpRequest *request,
const auto err = new ErrorState(ERR_INVALID_URL, Http::scNotFound, request);
err->url = xstrdup(entry->url());
errorAppendEntry(entry, err);
- entry->expires = squid_curtime;
return;
}

View File

@ -0,0 +1,138 @@
From 72a3bbd5e431597c3fdb56d752bc56b010ba3817 Mon Sep 17 00:00:00 2001
From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Wed, 25 Oct 2023 11:47:19 +0000
Subject: [PATCH] Improve handling of expanding HTTP header values (#1536)
Squid manipulations often increase HTTP header value length compared to
the corresponding raw value received by Squid. Raw header length is
checked against request_header_max_size and reply_header_max_size that
default to 64KB, making the raw value safe to store in a String object
(by default). However, when the increased length of a manipulated value
exceeds String class limits, Squid leaks memory, asserts, or possibly
stalls affected transactions. The long-term fix for this problem is a
complete String elimination from Squid sources, but that takes time.
Known manipulations may effectively concatenate headers and/or increase
header value length by 50%. This workaround makes such known increases
safe by essentially tripling String class limits:
(64KB + 64KB) * 150% = 3 * 64KB
This bug was discovered and detailed by Joshua Rogers at
https://megamansec.github.io/Squid-Security-Audit/response-memleaks.html
where it was filed as "Memory Leak in HTTP Response Parsing".
Conflict: src/SquidString.h context adapt
Reference: https://github.com/squid-cache/squid/commit/72a3bbd5e431597c3fdb56d752bc56b010ba3817
---
src/SquidString.h | 11 ++++++++++-
src/cache_cf.cc | 12 ++++++++++++
src/cf.data.pre | 26 ++++++++++++++++----------
src/http.cc | 5 +++--
4 files changed, 41 insertions(+), 13 deletions(-)
diff --git a/src/SquidString.h b/src/SquidString.h
index 21fdde598cb..ffb215fa5e7 100644
--- a/src/SquidString.h
+++ b/src/SquidString.h
@@ -140,7 +140,16 @@ class String
size_type len_; /* current length */
- static const size_type SizeMax_ = 65535; ///< 64K limit protects some fixed-size buffers
+ /// An earlier 64KB limit was meant to protect some fixed-size buffers, but
+ /// (a) we do not know where those buffers are (or whether they still exist)
+ /// (b) too many String users unknowingly exceeded that limit and asserted.
+ /// We are now using a larger limit to reduce the number of (b) cases,
+ /// especially cases where "compact" lists of items grow 50% in size when we
+ /// convert them to canonical form. The new limit is selected to withstand
+ /// concatenation and ~50% expansion of two HTTP headers limited by default
+ /// request_header_max_size and reply_header_max_size settings.
+ static const size_type SizeMax_ = 3*64*1024 - 1;
+
/// returns true after increasing the first argument by extra if the sum does not exceed SizeMax_
static bool SafeAdd(size_type &base, size_type extra) { if (extra <= SizeMax_ && base <= SizeMax_ - extra) { base += extra; return true; } return false; }
diff --git a/src/cache_cf.cc b/src/cache_cf.cc
index 6a0d253b139..e4a296005fd 100644
--- a/src/cache_cf.cc
+++ b/src/cache_cf.cc
@@ -1007,6 +1007,18 @@ configDoConfigure(void)
(uint32_t)Config.maxRequestBufferSize, (uint32_t)Config.maxRequestHeaderSize);
}
+ // Warn about the dangers of exceeding String limits when manipulating HTTP
+ // headers. Technically, we do not concatenate _requests_, so we could relax
+ // their check, but we keep the two checks the same for simplicity sake.
+ const auto safeRawHeaderValueSizeMax = (String::SizeMaxXXX()+1)/3;
+ // TODO: static_assert(safeRawHeaderValueSizeMax >= 64*1024); // no WARNINGs for default settings
+ if (Config.maxRequestHeaderSize > safeRawHeaderValueSizeMax)
+ debugs(3, DBG_CRITICAL, "WARNING: Increasing request_header_max_size beyond " << safeRawHeaderValueSizeMax <<
+ " bytes makes Squid more vulnerable to denial-of-service attacks; configured value: " << Config.maxRequestHeaderSize << " bytes");
+ if (Config.maxReplyHeaderSize > safeRawHeaderValueSizeMax)
+ debugs(3, DBG_CRITICAL, "WARNING: Increasing reply_header_max_size beyond " << safeRawHeaderValueSizeMax <<
+ " bytes makes Squid more vulnerable to denial-of-service attacks; configured value: " << Config.maxReplyHeaderSize << " bytes");
+
/*
* Disable client side request pipelining if client_persistent_connections OFF.
* Waste of resources queueing any pipelined requests when the first will close the connection.
diff --git a/src/cf.data.pre b/src/cf.data.pre
index 15e09c42378..986e31499a6 100644
--- a/src/cf.data.pre
+++ b/src/cf.data.pre
@@ -6753,11 +6753,14 @@ TYPE: b_size_t
DEFAULT: 64 KB
LOC: Config.maxRequestHeaderSize
DOC_START
- This specifies the maximum size for HTTP headers in a request.
- Request headers are usually relatively small (about 512 bytes).
- Placing a limit on the request header size will catch certain
- bugs (for example with persistent connections) and possibly
- buffer-overflow or denial-of-service attacks.
+ This directives limits the header size of a received HTTP request
+ (including request-line). Increasing this limit beyond its 64 KB default
+ exposes certain old Squid code to various denial-of-service attacks. This
+ limit also applies to received FTP commands.
+
+ This limit has no direct affect on Squid memory consumption.
+
+ Squid does not check this limit when sending requests.
DOC_END
NAME: reply_header_max_size
@@ -6766,11 +6769,14 @@ TYPE: b_size_t
DEFAULT: 64 KB
LOC: Config.maxReplyHeaderSize
DOC_START
- This specifies the maximum size for HTTP headers in a reply.
- Reply headers are usually relatively small (about 512 bytes).
- Placing a limit on the reply header size will catch certain
- bugs (for example with persistent connections) and possibly
- buffer-overflow or denial-of-service attacks.
+ This directives limits the header size of a received HTTP response
+ (including status-line). Increasing this limit beyond its 64 KB default
+ exposes certain old Squid code to various denial-of-service attacks. This
+ limit also applies to FTP command responses.
+
+ Squid also checks this limit when loading hit responses from disk cache.
+
+ Squid does not check this limit when sending responses.
DOC_END
NAME: request_body_max_size
diff --git a/src/http.cc b/src/http.cc
index f4e96aacd52..138c845c7b0 100644
--- a/src/http.cc
+++ b/src/http.cc
@@ -1900,8 +1900,9 @@ HttpStateData::httpBuildRequestHeader(HttpRequest * request,
String strFwd = hdr_in->getList(Http::HdrType::X_FORWARDED_FOR);
- // if we cannot double strFwd size, then it grew past 50% of the limit
- if (!strFwd.canGrowBy(strFwd.size())) {
+ // Detect unreasonably long header values. And paranoidly check String
+ // limits: a String ought to accommodate two reasonable-length values.
+ if (strFwd.size() > 32*1024 || !strFwd.canGrowBy(strFwd.size())) {
// There is probably a forwarding loop with Via detection disabled.
// If we do nothing, String will assert on overflow soon.
// TODO: Terminate all transactions with huge XFF?

View File

@ -2,7 +2,7 @@
Name: squid
Version: 4.9
Release: 19
Release: 24
Summary: The Squid proxy caching server
Epoch: 7
License: GPLv2+ and (LGPLv2+ and MIT and BSD and Public Domain)
@ -50,6 +50,12 @@ Patch29:backport-0001-CVE-2023-46846.patch
Patch30:backport-0002-CVE-2023-46846.patch
Patch31:backport-CVE-2023-46847.patch
Patch32:backport-CVE-2023-46724.patch
Patch33:backport-CVE-2023-46728.patch
Patch34:backport-CVE-2023-49285.patch
Patch35:backport-CVE-2023-49286.patch
Patch36:backport-CVE-2023-50269.patch
Patch37:backport-CVE-2024-23638.patch
Patch38:backport-CVE-2024-25617.patch
Buildroot: %{_tmppath}/squid-4.9-1-root-%(%{__id_u} -n)
Requires: bash >= 2.0
@ -244,6 +250,36 @@ fi
chgrp squid /var/cache/samba/winbindd_privileged >/dev/null 2>&1 || :
%changelog
* Mon Feb 19 2024 hehuazhen <hehuazhen@huawei.com> - 7:4.9-24
- Type:cves
- ID:CVE-2024-25617
- SUG:NA
- DESC:fix CVE-2024-25617
* Thu Jan 25 2024 xinghe <xinghe2@h-partners.com> - 7:4.9-23
- Type:cves
- ID:CVE-2024-23638
- SUG:NA
- DESC:fix CVE-2024-23638
* Fri Dec 15 2023 xinghe <xinghe2@h-partners.com> - 7:4.9-22
- Type:cves
- ID:CVE-2023-50269
- SUG:NA
- DESC:fix CVE-2023-50269
* Tue Dec 05 2023 yanglu <yanglu72@h-partners.com> - 7:4.9-21
- Type:cves
- ID:CVE-2023-49285 CVE-2023-49286
- SUG:NA
- DESC:fix CVE-2023-49285 CVE-2023-49286
* Wed Nov 08 2023 yanglu <yanglu72@h-partners.com> - 7:4.9-20
- Type:CVE
- ID:CVE-2023-46728
- SUG:NA
- DESC:fix CVE-2023-46728
* Thu Nov 02 2023 yanglu <yanglu72@h-partners.com> - 7:4.9-19
- Type:CVE
- ID:CVE-2023-46724