After analyzing the thing again, I don't think that it's such a big
security issue, or even a security issue at all, since it's not remotely
exploitable in any way and probably is very specific to how I'm using it
(I haven't found anyone else using it in the same way), so here it is:
src/proto_sockpair.c, line 422, the one with "memcpy".
The issue here lies within the fact that the SCM_RIGHTS control message
received from the Unix domain socket could have more than one file
descriptor associated with it. In this case, "totlen" will be greater
than sizeof(int), so the memcpy function spills over to the rest of the
variables (cmsg, buf, etc.).
As it appears to be used from the documentation and source code,
normally only HAProxy itself would send file descriptors over using
SCM_RIGHTS. However, in our use case, we have an external daemon which
sends file descriptors returned by accept() over to HAProxy. If that
daemon were to send more than one file descriptor over to HAProxy, a
stack buffer overflow would still result.
This usage was probably not the original intent of sockpair, so again I
don't think that it's really a security issue at all (the send_fd_uxst
function would only send one file descriptor at a time, and if that was
the only function to send file descriptors, each receive on the other
side would only obtain one file descriptor at a time anyway), but the
fact that it's a stack buffer overflow still warrants a fix anyway.
Peter
On 7/20/21 1:48 AM, Lukas Tribus wrote:
Hello,
On Tue, 20 Jul 2021 at 08:13, Peter Jin <[email protected]> wrote:
2. There is a stack buffer overflow found in one of the files. Not
disclosing it here because this email will end up on the public mailing
list. If there is a "security" email address I could disclose it to,
what is it?
It's [email protected], it's somehow well hidden in doc/intro.txt
(that is the *starter* guide).
I would definitely suggest putting it on the website haproxy.org, and
in the repository move it to a different file, like MAINTAINERS.
Lukas
