Re: CVE-2023-25690 and CVE-2023-27522
Hi John,
On Wed, Mar 22, 2023 at 05:25:19PM -0400, John Lauro wrote:
> Assuming no direct access to apache servers, does anyone know if
> haproxy would by default protect against these vulnerabilities?
For others, the descriptions are here:
https://httpd.apache.org/security/vulnerabilities_24.html
I don't know, but it *seems* to me that the issue is rather between
Apache and the next hop so unless you're able to block the undesired
characters at the front (e.g. by dropping byte pairs starting with
"%0" and "%1" in the URI to drop ctrl chars) I don't think just
placing a proxy upfront could be sufficient here. But you could
probably experiment with something like this:
http-request reject if { url -m reg %[01] }
Maybe it would be sufficient to handle req.path by the way. It would
even avoid matching in the query string in case it's needed to let
some such chars pass there.
Just an idea...
Willy
CVE-2023-25690 and CVE-2023-27522
Assuming no direct access to apache servers, does anyone know if haproxy would by default protect against these vulnerabilities?
Re: [PATCH] BUG/MINOR: illegal use of the malloc_trim() function if jemalloc is used
On Wed, Mar 22, 2023 at 02:39:15PM +0100, Miroslav Zagorac wrote: > On 22. 03. 2023. 14:33, Willy Tarreau wrote: > >> Also, in that case, when calling 'haproxy -vv', it is no longer printed > >> that > >> malloc_trim is enabled. > > > > I'm not sure what you mean here, because for me it's never printed that > > malloc_trim() is enabled when building with jemalloc. > > > > Hello Willy, > > without the patch: > > % make -j8 ADDLIB="-ljemalloc" TARGET="linux-glibc" IGNOREGIT=1 > USE_GETADDRINFO=1 USE_LIBCRYPT=1 USE_LUA=1 USE_MEMORY_PROFILING=1 > USE_MODULES=1 USE_NS=1 USE_OPENSSL=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_TFO=1 > USE_THREAD=1 USE_ZLIB=1 > > % ldd haproxy | grep jemalloc > libjemalloc.so.2 => /lib/x86_64-linux-gnu/libjemalloc.so.2 > (0x7f1319e3a000) > > ./haproxy -vv | grep trim > Support for malloc_trim() is enabled. Ah thanks now I understand. For me it wasn't the case because I LD_PRELOADed it. However by doing so you've changed the semantics of this variable "using_default_allocator" whose role was exactly to detect if the allocator had changed from the built-in one. That's why it wasn't called "using_glibc_allocator" or so. Admittedly that part was still seriously lacking comments... I'd rather turn it back to what it was and fix the problem where the message is emitted instead. Anyway on latest changes we do emulate malloc_trim() using the equivalent in the other libs so in the end I'll just remove that message as it doesn't provide any value anymore. Thanks for the explanation! Willy
Promoting list - RSA Conference 2023
Happy Wednesday to you! Would you be interested in acquiring a pre-show attendee list of RSA Conference 2023? You can use this list for multi-channel marketing purpose for email marketing, tele-marketing and direct mail marketing. The list includes contact information, such as name, email address, and company name, as well as additional information about the buyer, such as interest in products, budget, and purchase intent. Let me know if you would like to hear more about counts and cost. Just reply with the option below, 1. Yes, I'm interested, send counts and cost. 2. No, unsubscribe. Thanks Elizabeth Cooper Global Marketing Executive
Re: [PATCH] BUG/MINOR: illegal use of the malloc_trim() function if jemalloc is used
On 22. 03. 2023. 14:33, Willy Tarreau wrote: >> Also, in that case, when calling 'haproxy -vv', it is no longer printed that >> malloc_trim is enabled. > > I'm not sure what you mean here, because for me it's never printed that > malloc_trim() is enabled when building with jemalloc. > Hello Willy, without the patch: % make -j8 ADDLIB="-ljemalloc" TARGET="linux-glibc" IGNOREGIT=1 USE_GETADDRINFO=1 USE_LIBCRYPT=1 USE_LUA=1 USE_MEMORY_PROFILING=1 USE_MODULES=1 USE_NS=1 USE_OPENSSL=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_TFO=1 USE_THREAD=1 USE_ZLIB=1 % ldd haproxy | grep jemalloc libjemalloc.so.2 => /lib/x86_64-linux-gnu/libjemalloc.so.2 (0x7f1319e3a000) ./haproxy -vv | grep trim Support for malloc_trim() is enabled. -- Zaga What can change the nature of a man?
Re: [PATCH] BUG/MINOR: illegal use of the malloc_trim() function if jemalloc is used
Hi Miroslav, On Wed, Mar 22, 2023 at 01:11:53PM +0100, Miroslav Zagorac wrote: > Hello all, > > here is a patch that does not allow the use of malloc_trim() function if > HAProxy is linked with the malloc library. It was checked in some places in > the source, but not everywhere. Oh thanks for this, I remember noting it along a previous debugging session related to the patterns, and I would have sworn it was done! Interestingly we were speaking with William about this precise function 2 hours ago, saying that a more reliable long-term solution would be to intercept it and replace it so that any possible calls made from child libraries could be intercepted. This would then permit to get rid of the library compatibility check in dl_open(). > Also, in that case, when calling 'haproxy -vv', it is no longer printed that > malloc_trim is enabled. I'm not sure what you mean here, because for me it's never printed that malloc_trim() is enabled when building with jemalloc. Thanks! Willy
Re: [PATCH] BUG/MINOR: illegal use of the malloc_trim() function if jemalloc is used
On 22. 03. 2023. 13:11, Miroslav Zagorac wrote: > Hello all, > > here is a patch that does not allow the use of malloc_trim() function if > HAProxy is linked with the malloc library. It was checked in some places in .. jemalloc .., sorry for the typo. > the source, but not everywhere. > > Also, in that case, when calling 'haproxy -vv', it is no longer printed that > malloc_trim is enabled. > -- Miroslav Zagorac Senior Developer
[PATCH] BUG/MINOR: illegal use of the malloc_trim() function if jemalloc is used
Hello all,
here is a patch that does not allow the use of malloc_trim() function if
HAProxy is linked with the malloc library. It was checked in some places in
the source, but not everywhere.
Also, in that case, when calling 'haproxy -vv', it is no longer printed that
malloc_trim is enabled.
--
Miroslav Zagorac
Senior DeveloperFrom 33a84d19548baf46e8fccbb58a891a3e4c6b4895 Mon Sep 17 00:00:00 2001
From: Miroslav Zagorac
Date: Wed, 22 Mar 2023 12:52:19 +0100
Subject: [PATCH] BUG/MINOR: illegal use of the malloc_trim() function if
jemalloc is used
In the event that HAProxy is linked with the jemalloc library, it is still
shown that malloc_trim() is enabled when executing "haproxy -vv":
..
Support for malloc_trim() is enabled.
..
It's not so much a problem as it is that malloc_trim() is called in the
pat_ref_purge_range() function without any checking.
This was solved by setting the using_default_allocator variable to the
correct value in the detect_allocator() function and before calling
malloc_trim() it is checked whether the function should be called.
---
include/haproxy/pool.h | 1 +
src/pattern.c | 2 +-
src/pool.c | 9 -
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/haproxy/pool.h b/include/haproxy/pool.h
index 16146604b..a12990d24 100644
--- a/include/haproxy/pool.h
+++ b/include/haproxy/pool.h
@@ -101,6 +101,7 @@ extern int mem_poison_byte;
/* set of POOL_DBG_* flags */
extern uint pool_debugging;
+int is_trim_enabled(void);
void *pool_get_from_os(struct pool_head *pool);
void pool_put_to_os(struct pool_head *pool, void *ptr);
void *pool_alloc_nocache(struct pool_head *pool);
diff --git a/src/pattern.c b/src/pattern.c
index a2557dea1..71f25a43b 100644
--- a/src/pattern.c
+++ b/src/pattern.c
@@ -2084,7 +2084,7 @@ int pat_ref_purge_range(struct pat_ref *ref, uint from, uint to, int budget)
HA_RWLOCK_WRUNLOCK(PATEXP_LOCK, >lock);
#if defined(HA_HAVE_MALLOC_TRIM)
- if (done) {
+ if (done && is_trim_enabled()) {
malloc_trim(0);
}
#endif
diff --git a/src/pool.c b/src/pool.c
index 345681a0c..214d950fb 100644
--- a/src/pool.c
+++ b/src/pool.c
@@ -177,11 +177,10 @@ static void detect_allocator(void)
my_mallctl = mallctl;
#endif
-
- if (!my_mallctl) {
+ if (!my_mallctl)
my_mallctl = get_sym_curr_addr("mallctl");
- using_default_allocator = (my_mallctl == NULL);
- }
+
+ using_default_allocator = (my_mallctl == NULL);
if (!my_mallctl) {
#if defined(HA_HAVE_MALLOC_TRIM)
@@ -212,7 +211,7 @@ static void detect_allocator(void)
}
}
-static int is_trim_enabled(void)
+int is_trim_enabled(void)
{
return using_default_allocator;
}
--
2.37.1
Re: 2.4.22 and maxconn setting problem
wt., 21 mar 2023 o 15:03 Willy Tarreau napisał(a): > What you *seem* to be missing in these logs is "%bc" and "%bq" to see > the state of the backend itself. My suspicion is that %bq is not zero > despite %bc being zero. > I will add these to logs/experiment with balance source and will return with more data when the issue occurs again. Thanks Willy!
