**What is the version information for this release?**

Microsoft Edge Version

Date Released

Based on Chromium Version

97.0.1072.55

1/6/2022

97.0.4692.71

CVE-2022-0113: Chromium: CVE-2022-0113 Inappropriate implementation in Blink

CVE-2022-0115: Chromium: CVE-2022-0115 Uninitialized Use in File API

CVE-2022-0114: Chromium: CVE-2022-0114 Out of bounds memory access in Web Serial

CVE-2022-0106: Chromium: CVE-2022-0106 Use after free in Autofill

CVE-2022-0105: Chromium: CVE-2022-0105 Use after free in PDF

CVE-2022-0102: Chromium: CVE-2022-0102 Type Confusion in V8 

In lighttpd 1.4.46 through 1.4.63, the mod_extforward_Forwarded function of the mod_extforward plugin has a stack-based buffer overflow (4 bytes), as demonstrated by remote denial of service (daemon crash).

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

![](https://redmine.lighttpd.net/attachments/thumbnail/2160)

![](https://redmine.lighttpd.net/attachments/download/2160/header.png)

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 <povcfe@qq.com>
    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

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

Foxit PDF Reader and PDF Editor before 11.1 on macOS allow remote attackers to execute arbitrary code via getURL in the JavaScript API.

CVE-2021-45980: Security Bulletins | Foxit Software

Utilizing existing Microsoft features for offensive operations is very common during red team assessments as it provides the opportunity to blend in with the environment… 
Continue reading → Domain Persistence – AdminSDHolder

Utilizing existing Microsoft features for offensive operations is very common during red team assessments as it provides the opportunity to blend in with the environment and stay undetected. Microsoft introduced “_AdminSDHolder_” active directory object to protect high privilege accounts such as domain admins and enterprise admins from unintentional modifications of permissions as it is used as security template. Active directory retrieves the ACL of the “_AdminSDHolder_” object periodically (every 60 minutes by default) and apply the permissions to all the groups and accounts which are part of that object. This means that during red team operations even if an account is detected and removed from a high privileged group within 60 minutes (unless it is enforced) these permissions will be pushed back.

In the event that a domain has been compromised a standard user account can be added into the access control list of the “_AdminSDHolder_” in order to establish domain persistence. This user will acquire “GenericAll” privileges which is the equivalent of the domain administrator. This technique is not new as it has been presented initially by Sean Metcalf during DerbyCon in 2015. The implementation of the attack is trivial from an elevated PowerShell console by executing the following PowerView module:

    Add-ObjectAcl -TargetADSprefix 'CN=AdminSDHolder,CN=System' -PrincipalSamAccountName pentestlab -Verbose -Rights All

AdminSDHolder – Modification

After 60 minutes the changes in the permissions will be applied and the module “_Get-ObjectAcl_” can be used to validate that the user “_pentestlab_” has “_GenericAll_” active directory rights.

    Get-ObjectAcl -SamAccountName "Domain Admins" -ResolveGUIDs | ?{$_.IdentityReference -match 'pentestlab'}

AdminSDHolder – GenericAll Privileges

Changes in ACL will propagate automatically after 60 minutes. This is due to the Security Descriptor propagator (SDProp) process that runs every 60 minutes on the Principal Domain Controller (PDC) emulator and populates the access control list with the security permissions that exist in the AdminSDHolder for groups and accounts. However, these could be forced by modifying the DN as it can be seen below using the “_ldp.exe_” utility.

AdminSDHolder – Modify DN

Alternatively modification of a specific registry key on the domain controller can reduce the time interval of the SDProp to 3 minutes (12c hexadecimal value). It should be noted that Microsoft doesn’t recommend the modification of this setting as this might cause performance issues in relation to LSASS process across the domain.

    REG ADD HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /V AdminSDProtectFrequency /T REG_DWORD /F /D 300

From the perspective of Active Directory it is visible that the user “_pentestlab_” has been added at the “_AdminSDHolder_” object by looking on its Properties.

AdminSDHolder – Properties

Groups and accounts which are part of the “_AdminSDHolder_” container will have the “_adminCount_” attribute set to 1. This flag indicates that permissions from that container will be copied in 60 minutes across the domain even if privileges are modified.

AdminSDHolder – adminCount

Since the user has the required permissions it can be added to the “_Domain Admins_” group.

    net group "domain admins" pentestlab /add /domain

Add user to Domain Admins Group

Executing the command below will verify that the domain controller is now accessible and domain persistence has been established.

    dir \\10.0.0.1\c$

AdminSDHolder – DC Access

**References**

*   https://adsecurity.org/?p=1906
*   https://www.harmj0y.net/blog/redteaming/abusing-active-directory-permissions-with-powerview/
*   https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/how-to-abuse-and-backdoor-adminsdholder-to-obtain-domain-admin-persistence

**Post navigation**

Tag

#microsoft