CVE-2022-22707: Bug #3134: mod_extforward plugin has out-of-bounds (OOB) write of 4-byte -1 - Lighttpd

I uploaded the exp by mistake, please delete it in time

• File deleted (exp.py)

• Subject changed from Security - lighttpd mod_extforward plugin has stack overflow vulnerability to lighttpd mod_extforward plugin has out-of-bounds (OOB) write of 4-byte -1

• Description updated (diff)

• Status changed from New to Patch Pending

• Target version changed from 1.4.xx to 1.4.64

You are correct that there is an out-of-bounds write on the stack.
However, this out-of-bounds write is not controlled by the attacker.
The value that is written out-of-bounds after the end of offsets[] is -1

However, with the default lighttpd build with gcc -O2, I was unable to
trigger a crash in lighttpd on amd64 (64-bit) or on i686 (32-bit).

As with your prior posts, I think your test toolchain is configured
with a stack canary which crashes when an out-of-bounds read or write
is detected, which is fine for your research, but not necessarily a
reflection of real-world impact. When mod_extforward.c is compiled with
-fstack-protector-all -fstack-protector-strong, I was able to trigger
a crash in lighttpd on i686 (32-bit), but not amd64 (64-bit), using the
reproducer (exp.py) you had provided.

Also, the scenario in which this occurs is not enabled by default in lighttpd.

• First, the user must be using mod_extforward. (not default)
• Second, the user must explicitly configure extforward.headers
  to contain “Forwarded” (not default)
• Third, the user must have configured mod_extforward to trust the
  upstream proxy server which proxied the request to lighttpd,
  and from which lighttpd is receiving the “Forwarded” header.
  This upstream proxy must allow and use this unusual “Forwarded”
  header.

Your statement that this issue affects lighttpd 1.4.41-1.4.63 is incorrect.
Support for the “Forwarded” header was added in lighttpd 1.4.46.
https://redmine.lighttpd.net/issues/2703
I have updated your original post.

Given this initial assessment (not yet complete), I have changed the
the wording of this issue to tone it down from vulnerability to OOB write.
There is a bug that will be fixed, but unless further information comes to
light, this does not appear to have security implications for default usage
of lighttpd. Please help me determine in which scenarios and platforms
this might have an impact.

• Subject changed from lighttpd mod_extforward plugin has out-of-bounds (OOB) write of 4-byte -1 to mod_extforward plugin has out-of-bounds (OOB) write of 4-byte -1

gstrauss wrote in #note-3:

You are correct that there is an out-of-bounds write on the stack.
However, this out-of-bounds write is not controlled by the attacker.
The value that is written out-of-bounds after the end of offsets[] is -1

However, with the default lighttpd build with gcc -O2, I was unable to
trigger a crash in lighttpd on amd64 (64-bit) or on i686 (32-bit).

As with your prior posts, I think your test toolchain is configured
with a stack canary which crashes when an out-of-bounds read or write
is detected, which is fine for your research, but not necessarily a
reflection of real-world impact. When mod_extforward.c is compiled with
-fstack-protector-all -fstack-protector-strong, I was able to trigger
a crash in lighttpd on i686 (32-bit), but not amd64 (64-bit), using the
reproducer (exp.py) you had provided.

Also, the scenario in which this occurs is not enabled by default in lighttpd.

• First, the user must be using mod_extforward. (not default)
• Second, the user must explicitly configure extforward.headers
  to contain “Forwarded” (not default)
• Third, the user must have configured mod_extforward to trust the
  upstream proxy server which proxied the request to lighttpd,
  and from which lighttpd is receiving the “Forwarded” header.
  This upstream proxy must allow and use this unusual “Forwarded”
  header.

Your statement that this issue affects lighttpd 1.4.41-1.4.63 is incorrect.
Support for the “Forwarded” header was added in lighttpd 1.4.46.
https://redmine.lighttpd.net/issues/2703
I have updated your original post.

Given this initial assessment (not yet complete), I have changed the
the wording of this issue to tone it down from vulnerability to OOB write.
There is a bug that will be fixed, but unless further information comes to
light, this does not appear to have security implications for default usage
of lighttpd. Please help me determine in which scenarios and platforms
this might have an impact.

I’m using the ubuntu 20.04 default configuration, where canary is turned on by default

povcfe-bug wrote in #note-5:

gstrauss wrote in #note-3:

You are correct that there is an out-of-bounds write on the stack.
However, this out-of-bounds write is not controlled by the attacker.
The value that is written out-of-bounds after the end of offsets[] is -1

However, with the default lighttpd build with gcc -O2, I was unable to
trigger a crash in lighttpd on amd64 (64-bit) or on i686 (32-bit).

As with your prior posts, I think your test toolchain is configured
with a stack canary which crashes when an out-of-bounds read or write
is detected, which is fine for your research, but not necessarily a
reflection of real-world impact. When mod_extforward.c is compiled with
-fstack-protector-all -fstack-protector-strong, I was able to trigger
a crash in lighttpd on i686 (32-bit), but not amd64 (64-bit), using the
reproducer (exp.py) you had provided.

Also, the scenario in which this occurs is not enabled by default in lighttpd.

• First, the user must be using mod_extforward. (not default)
• Second, the user must explicitly configure extforward.headers
  to contain “Forwarded” (not default)
• Third, the user must have configured mod_extforward to trust the
  upstream proxy server which proxied the request to lighttpd,
  and from which lighttpd is receiving the “Forwarded” header.
  This upstream proxy must allow and use this unusual “Forwarded”
  header.

Your statement that this issue affects lighttpd 1.4.41-1.4.63 is incorrect.
Support for the “Forwarded” header was added in lighttpd 1.4.46.
https://redmine.lighttpd.net/issues/2703
I have updated your original post.

Given this initial assessment (not yet complete), I have changed the
the wording of this issue to tone it down from vulnerability to OOB write.
There is a bug that will be fixed, but unless further information comes to
light, this does not appear to have security implications for default usage
of lighttpd. Please help me determine in which scenarios and platforms
this might have an impact.

I’m using the ubuntu 20.04 default configuration, where canary is turned on by default

The reason why 64-bit programs can’t crash is that sse 16-bit alignment, when closing intel sse, 64-bit programs will also crash, so please make sure that mips, arm and other architecture programs will not trigger a crash.

So compiling 32-bit lighttpd within an operating system with a higher gcc version, or compiling and using lighttpd with an architecture that does not support sse 16-bit byte alignment, will result in a denial of service

gstrauss wrote in #note-8:

So compiling 32-bit lighttpd within an operating system with a higher gcc version, or compiling and using lighttpd with an architecture that does not support sse 16-bit byte alignment, will result in a denial of service

You seem to be overlooking the prerequisites to reaching the bug. Case in point, I wrote:

• Third, the user must have configured mod_extforward to trust the
  upstream proxy server which proxied the request to lighttpd,
  and from which lighttpd is receiving the “Forwarded” header.
  This upstream proxy must allow and use this unusual “Forwarded”
  header.

For someone to want to configure lighttpd this way, they must be using a proxy which supports "Forwarded". Do you know of real-world use in popular CDNs? Most CDNs and cloud providers have their own custom fields for X-Forwarded-For.

I took a quick look and Cloudflare does not currently support Forwarded.
https://community.cloudflare.com/t/support-for-http-forwarded-header-as-a-replacement-for-x-forwarded-for/320943
Nor does HAProxy (where the HAProxy “PROXY” protocol is often preferred)
https://github.com/haproxy/haproxy/issues/575

I did find that “Forwarded” is implemented in
https://microsoft.github.io/reverse-proxy/articles/transforms.html#forwarded
though a developer noted it is not enabled by default
(https://github.com/dotnet/aspnetcore/issues/5978#issuecomment-668013246)
and “Forwarded” is implemented in
https://github.com/gorilla/handlers/blob/master/proxy_headers.go

Please keep in mind that my questions here and above are to help gauge potential impact of the bug.

Thus far, based on what I have posted here and above, I am confident that the bug is not reachable in common use scenarios of lighttpd mod_extforward.

I noticed that “https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModExtForward” mentions a custom setting for "Forwarded", which is not really the default configuration, but I mean that for users with such a configuration, remote denial of service is possible.

• File header.png header.png added

This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.

My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.

gstrauss wrote in #note-11:

This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.

My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.

I agree with you in the comment above that he will not be triggered by default

gstrauss wrote in #note-11:

This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.

My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.

I hope you will listen to me carefully, you said he will not be triggered by default, I agree. Also you said that canary must be turned on to trigger a crash, I told you that canary is turned on by default in higher versions of gcc, and that crashes are possible for system architectures that do not have SSE turned on.

povcfe-bug wrote in #note-12:

gstrauss wrote in #note-11:

This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.

My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.

I agree with you in the comment above that he will not be triggered by default

Please respect contributors who find problems and submit patches

Please respect contributors who find problems and submit patches

I appreciate that you have taken the time to find this and to post it so that it can be fixed. Thank you.

Above, I wrote:

This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.

My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.

Please help me to understand why you feel disrespected by these grounded statements. Impact analysis is an important part of bug and security triage.

gstrauss wrote in #note-15:

Please respect contributors who find problems and submit patches

I appreciate that you have taken the time to find this and to post it so that it can be fixed. Thank you.

Above, I wrote:

This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.

My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.

Please help me to understand why you feel disrespected by these grounded statements. Impact analysis is an important part of bug and security triage.

I don’t think you’ve just listened carefully to my analysis, and there are differences between our two concerns. Impact exclusion is indeed a very important aspect, and I agree with your analysis above

This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.

I don’t think you’ve just listened carefully to my analysis, and there are differences between our two concerns.

Would you please describe your concerns in more detail?

Your post is less than 5 hours old and I have spent a considerable amount of time reviewing, reproducing, and analyzing the potential impact, and have tried to be explicit in my posts that these are the steps I am taking. If you feel that I am giving it short thrift, then please describe your expectations in more detail.

gstrauss wrote in #note-17:

This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.

I don’t think you’ve just listened carefully to my analysis, and there are differences between our two concerns.

Would you please describe your concerns in more detail?

Your post is less than 5 hours old and I have spent a considerable amount of time reviewing, reproducing, and analyzing the potential impact, and have tried to be explicit in my posts that these are the steps I am taking. If you feel that I am giving it short thrift, then please describe your expectations in more detail.

Sorry, my narrative above was just to show you that users using this non-default configuration can trigger crashes with the default compile option. I appreciate your work, and your attention to this issue, and I apologize.

Yes, for systems and distros which enable the canary by default, and if the prerequisites to reach the bug are met, then the bug will trigger a crash.

Please attach a patch (e.g. output from git format-patch) with the patch in your original post and how you’d like to be credited. The patch looks good, and I’ll need to edit the commit message a bit, but will try to preserve what you’d like to include.

It’s late here and I’ll return to this tomorrow.

I have applied for a cve id, please trace

You did not include a commit message in the attachment. Please see the lighttpd git history for how I credit contributors and let me know if you would like any different.

I have applied for a cve id, please trace

What do you mean by "please trace"? Is that an incomplete sentence?

I have a feeling that you are disappointed that my analysis indicates that this bug is low severity, as its prevalence in production is likely to be rare and specialized. Even when the bug is reachable, I do not believe it exploitable beyond triggering a crash. I will dispute the CVE if you represent the bug otherwise.

gstrauss wrote in #note-22:

You did not include a commit message in the attachment. Please see the lighttpd git history for how I credit contributors and let me know if you would like any different.

I have applied for a cve id, please trace

What do you mean by "please trace"? Is that an incomplete sentence?

I have a feeling that you are disappointed that my analysis indicates that this bug is low severity, as its prevalence in production is likely to be rare and specialized. Even when the bug is reachable, I do not believe it exploitable beyond triggering a crash. I will dispute the CVE if you represent the bug otherwise.

I applied for cve with a remote denial of service error type, which I think is reasonable, emm. I would like to know if you agree.

this is the new patch

From 8a91fd45f7f31707a876492b13c0f46845626727 Mon Sep 17 00:00:00 2001
From: povcfe <[email protected]>
Date: Wed, 5 Jan 2022 12:44:34 +0000
Subject: [PATCH] [mod_extforward] fix out-of-bounds (OOB) write of 4-byte -1

(thx povcfe)
---
 src/mod_extforward.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mod_extforward.c b/src/mod_extforward.c
index 733231fd..8dbdfad9 100644
--- a/src/mod_extforward.c
+++ b/src/mod_extforward.c
@@ -715,7 +715,7 @@ static handler_t mod_extforward_Forwarded (request_st * const r, plugin_data * c
         while (s[i] == ' ' || s[i] == '\t') ++i;
         if (s[i] == ';') { ++i; continue; }
         if (s[i] == ',') {
-            if (j >= (int)(sizeof(offsets)/sizeof(int))) break;
+            if (j >= (int)((sizeof(offsets)/sizeof(int)) - 1)) break;
             offsets[++j] = -1; /*("offset" separating params from next proxy)*/
             ++i;
             continue;
--
2.25.1