The WOOCS WordPress plugin before 1.3.7.3 does not sanitise and escape the custom_prices parameter before outputting it back in the response, leading to a Reflected Cross-Site Scripting issue

CVE-2021-25043: Changeset 2640621 for woocommerce-currency-switcher – WordPress Plugin Repository

A Denial of Service vulnerability exists in Binaryen 104 due to an assertion abort in wasm::WasmBinaryBuilder::readFunctions.

    Program received signal SIGABRT, Aborted.
    [----------------------------------registers-----------------------------------]
    RAX: 0x0 
    RBX: 0x7ffff4416040 (0x00007ffff4416040)
    RCX: 0x7ffff446018b (<__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108])
    RDX: 0x0 
    RSI: 0x7fffffff9970 --> 0x0 
    RDI: 0x2 
    RBP: 0x7ffff45d5588 ("%s%s%s:%u: %s%sAssertion `%s' failed.\n%n")
    RSP: 0x7fffffff9970 --> 0x0 
    RIP: 0x7ffff446018b (<__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108])
    R8 : 0x0 
    R9 : 0x7fffffff9970 --> 0x0 
    R10: 0x8 
    R11: 0x246 
    R12: 0x7ffff7b29060 ("/home/zxq/CVE_testing/project/binaryen/src/wasm/wasm-binary.cpp")
    R13: 0x8d4 
    R14: 0x7ffff7b2b8e0 ("exceptionTargetNames.empty()")
    R15: 0x615000006200 --> 0x60300001aba0 --> 0x30246c6562616c ('label$0')
    EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
    [-------------------------------------code-------------------------------------]
       0x7ffff446017f <__GI_raise+191>:	mov    edi,0x2
       0x7ffff4460184 <__GI_raise+196>:	mov    eax,0xe
       0x7ffff4460189 <__GI_raise+201>:	syscall 
    => 0x7ffff446018b <__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108]
       0x7ffff4460193 <__GI_raise+211>:	xor    rax,QWORD PTR fs:0x28
       0x7ffff446019c <__GI_raise+220>:	jne    0x7ffff44601c4 <__GI_raise+260>
       0x7ffff446019e <__GI_raise+222>:	mov    eax,r8d
       0x7ffff44601a1 <__GI_raise+225>:	add    rsp,0x118
    [------------------------------------stack-------------------------------------]
    0000| 0x7fffffff9970 --> 0x0 
    0008| 0x7fffffff9978 --> 0x4cb020 (<free>:	push   rbp)
    0016| 0x7fffffff9980 --> 0xfbad8000 --> 0x0 
    0024| 0x7fffffff9988 --> 0x612000000340 --> 0x74706f2d63000001 
    0032| 0x7fffffff9990 --> 0x6120000003a5 ("Builder::readFunctions(): Assertion `exceptionTargetNames.empty()' failed.\n")
    0040| 0x7fffffff9998 --> 0x612000000340 --> 0x74706f2d63000001 
    0048| 0x7fffffff99a0 --> 0x612000000340 --> 0x74706f2d63000001 
    0056| 0x7fffffff99a8 --> 0x6120000003f0 --> 0x0 
    [------------------------------------------------------------------------------]
    Legend: code, data, rodata, value
    Stopped reason: SIGABRT
    __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
    50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    gdb-peda$ bt
    #0  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
    #1  0x00007ffff443f859 in __GI_abort () at abort.c:79
    #2  0x00007ffff443f729 in __assert_fail_base (fmt=0x7ffff45d5588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7ffff7b2b8e0 <str> "exceptionTargetNames.empty()", 
        file=0x7ffff7b29060 <str> "/home/zxq/CVE_testing/project/binaryen/src/wasm/wasm-binary.cpp", line=0x8d4, function=<optimized out>) at assert.c:92
    #3  0x00007ffff4450f36 in __GI___assert_fail (assertion=0x7ffff7b2b8e0 <str> "exceptionTargetNames.empty()", file=0x7ffff7b29060 <str> "/home/zxq/CVE_testing/project/binaryen/src/wasm/wasm-binary.cpp", 
        line=0x8d4, function=0x7ffff7b2b840 <__PRETTY_FUNCTION__._ZN4wasm17WasmBinaryBuilder13readFunctionsEv> "void wasm::WasmBinaryBuilder::readFunctions()") at assert.c:101
    #4  0x00007ffff6ea794d in wasm::WasmBinaryBuilder::readFunctions (this=<optimized out>) at /home/zxq/CVE_testing/project/binaryen/src/wasm/wasm-binary.cpp:2260
    #5  0x00007ffff6e988a2 in wasm::WasmBinaryBuilder::read (this=0x7fffffffa6e0) at /home/zxq/CVE_testing/project/binaryen/src/wasm/wasm-binary.cpp:1426
    #6  0x00007ffff7046785 in wasm::ModuleReader::readBinaryData (this=<optimized out>, input=..., wasm=..., sourceMapFilename=<incomplete type>) at /home/zxq/CVE_testing/project/binaryen/src/wasm/wasm-io.cpp:63
    #7  0x00007ffff7046f76 in wasm::ModuleReader::readBinary (this=<optimized out>, filename=<incomplete type>, wasm=..., sourceMapFilename=<incomplete type>)
        at /home/zxq/CVE_testing/project/binaryen/src/wasm/wasm-io.cpp:74
    #8  0x00007ffff7047e1c in wasm::ModuleReader::read (this=<optimized out>, filename=<incomplete type>, wasm=..., sourceMapFilename=<incomplete type>)
        at /home/zxq/CVE_testing/project/binaryen/src/wasm/wasm-io.cpp:97
    #9  0x00000000006ae0ff in main (argc=<optimized out>, argv=<optimized out>) at /home/zxq/CVE_testing/project/binaryen/src/tools/wasm-opt.cpp:249
    #10 0x00007ffff44410b3 in __libc_start_main (main=0x6a6b70 <main(int, char const**)>, argc=0x2, argv=0x7fffffffe328, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
        stack_end=0x7fffffffe318) at ../csu/libc-start.c:308
    #11 0x0000000000452bde in _start () at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/iostream:74

CVE-2021-46048: A abort failure in wasm::WasmBinaryBuilder::readFunctions · Issue #4412 · WebAssembly/binaryen

A Denial of Service vulnerability exists in Binaryen 104 due to an assertion abort in wasm::WasmBinaryBuilder::visitRethrow(wasm::Rethrow*).

**Version:**

**command:**

POC8.zip

**Result**

**bt**

    Program received signal SIGABRT, Aborted.
    [----------------------------------registers-----------------------------------]
    RAX: 0x0 
    RBX: 0x7ffff4416040 (0x00007ffff4416040)
    RCX: 0x7ffff446018b (<__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108])
    RDX: 0x0 
    RSI: 0x7fffffffb890 --> 0x0 
    RDI: 0x2 
    RBP: 0x7ffff45d5588 ("%s%s%s:%u: %s%sAssertion `%s' failed.\n%n")
    RSP: 0x7fffffffb890 --> 0x0 
    RIP: 0x7ffff446018b (<__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108])
    R8 : 0x0 
    R9 : 0x7fffffffb890 --> 0x0 
    R10: 0x8 
    R11: 0x246 
    R12: 0x7ffff799dc40 ("/home/zxq/CVE_testing/project/binaryen/src/wasm-builder.h")
    R13: 0x31 ('1')
    R14: 0x7ffff799dc00 ("type.isSignature()")
    R15: 0xfffff700 --> 0x0
    EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
    [-------------------------------------code-------------------------------------]
       0x7ffff446017f <__GI_raise+191>:	mov    edi,0x2
       0x7ffff4460184 <__GI_raise+196>:	mov    eax,0xe
       0x7ffff4460189 <__GI_raise+201>:	syscall 
    => 0x7ffff446018b <__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108]
       0x7ffff4460193 <__GI_raise+211>:	xor    rax,QWORD PTR fs:0x28
       0x7ffff446019c <__GI_raise+220>:	jne    0x7ffff44601c4 <__GI_raise+260>
       0x7ffff446019e <__GI_raise+222>:	mov    eax,r8d
       0x7ffff44601a1 <__GI_raise+225>:	add    rsp,0x118
    [------------------------------------stack-------------------------------------]
    0000| 0x7fffffffb890 --> 0x0 
    0008| 0x7fffffffb898 --> 0x49bba0 (<free>:	push   rbp)
    0016| 0x7fffffffb8a0 --> 0x7ffffbad8000 
    0024| 0x7fffffffb8a8 --> 0x6120000001c0 --> 0x7369642d69000001 
    0032| 0x7fffffffb8b0 --> 0x612000000225 ("on> wasm::Builder::makeFunction(wasm::Name, wasm::HeapType, std::vector<Type> &&, wasm::Expression *): Assertion `type.isSignature()' failed.\n")
    0040| 0x7fffffffb8b8 --> 0x6120000001c0 --> 0x7369642d69000001 
    0048| 0x7fffffffb8c0 --> 0x6120000001c0 --> 0x7369642d69000001 
    0056| 0x7fffffffb8c8 --> 0x6120000002b3 --> 0x0 
    [------------------------------------------------------------------------------]
    Legend: code, data, rodata, value
    Stopped reason: SIGABRT
    __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
    50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    gdb-peda$ bt
    #0  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
    #1  0x00007ffff443f859 in __GI_abort () at abort.c:79
    #2  0x00007ffff443f729 in __assert_fail_base (fmt=0x7ffff45d5588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7ffff799dc00 <str> "type.isSignature()", 
        file=0x7ffff799dc40 <str> "/home/zxq/CVE_testing/project/binaryen/src/wasm-builder.h", line=0x31, function=<optimized out>) at assert.c:92
    #3  0x00007ffff4450f36 in __GI___assert_fail (assertion=0x7ffff799dc00 <str> "type.isSignature()", file=0x7ffff799dc40 <str> "/home/zxq/CVE_testing/project/binaryen/src/wasm-builder.h", line=0x31, 
        function=0x7ffff799dca0 <__PRETTY_FUNCTION__._ZN4wasm7Builder12makeFunctionENS_4NameENS_8HeapTypeEOSt6vectorINS_4TypeESaIS4_EEPNS_10ExpressionE> "static std::unique_ptr<Function> wasm::Builder::makeFunction(wasm::Name, wasm::HeapType, std::vector<Type> &&, wasm::Expression *)") at assert.c:101
    #4  0x00007ffff51417c4 in wasm::Builder::makeFunction (name=..., type=..., vars=..., body=<optimized out>) at /home/zxq/CVE_testing/project/binaryen/src/wasm-builder.h:49
    #5  0x00007ffff6ea172f in wasm::WasmBinaryBuilder::readImports (this=<optimized out>) at /home/zxq/CVE_testing/project/binaryen/src/wasm/wasm-binary.cpp:2059
    #6  0x00007ffff6e9967e in wasm::WasmBinaryBuilder::read (this=0x7fffffffcce0) at /home/zxq/CVE_testing/project/binaryen/src/wasm/wasm-binary.cpp:1417
    #7  0x00007ffff7046785 in wasm::ModuleReader::readBinaryData (this=<optimized out>, input=..., wasm=..., sourceMapFilename=<incomplete type>) at /home/zxq/CVE_testing/project/binaryen/src/wasm/wasm-io.cpp:63
    #8  0x00007ffff7046f76 in wasm::ModuleReader::readBinary (this=<optimized out>, filename=<incomplete type>, wasm=..., sourceMapFilename=<incomplete type>)
        at /home/zxq/CVE_testing/project/binaryen/src/wasm/wasm-io.cpp:74
    #9  0x00000000004cf7ca in main (argc=<optimized out>, argv=<optimized out>) at /home/zxq/CVE_testing/project/binaryen/src/tools/wasm-dis.cpp:65
    #10 0x00007ffff44410b3 in __libc_start_main (main=0x4cdef0 <main(int, char const**)>, argc=0x2, argv=0x7fffffffe348, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
        stack_end=0x7fffffffe338) at ../csu/libc-start.c:308
    #11 0x000000000042375e in _start () at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/iostream:74

CVE-2021-46055: A abort failure in wasm::Builder::makeFunction · Issue #4413 · WebAssembly/binaryen

Users have access to the directory where the installation repair occurs. Since the MS Installer allows regular users to run the repair, an attacker can initiate the installation repair and place a specially crafted EXE in the repair folder which runs with the Check Point Remote Access Client privileges.

Enterprise Endpoint Security E86.20 Windows Clients

**Technical Level**

Solution ID

sk176853

Technical Level ![](https://sc1.checkpoint.com/sc//images/information.png)

Product

Endpoint Security Client, Endpoint Security VPN, Harmony Endpoint, Harmony Disk and Media Encryption

Version

E86.20

OS

Windows

Date Created

2021-12-28 00:00:00.0

Last Modified

2022-01-09 06:00:44.0

Solution

*   **New Features**
    
*   **In a Nutshell**
    
*   **Resolved Issues and Enhancements**
    

*   **Endpoint Security Clients Downloads**
    
*   **Standalone Clients Downloads**
    
*   **Endpoint Security Server Downloads**
    

*   **Management Console Downloads**
    
*   **Utilities/Services Downloads**
    
*   **Documentation and Related SecureKnowledge Articles**
    

**Notes:**

*   See **Endpoint Security Homepage.**
*   To support SmartLog or SmartView Tracker reporting with Endpoint Security Clients for all supported servers (except R80.20 and higher), you must update the log schema. Follow instructions in sk106662.
*   Starting from E80.85, anonymized incident related data is sent to Check Point ThreatCloud, by default. See sk129753.
*   This release includes all limitations of earlier releases unless explicitly shown as resolved.

Click Here to Show the Entire Article

**List of New Features in E86.20**

Show / Hide this section

> ID
> 
> Description
> 
> General
> 
> ESVPN-2749
> 
> The administrator can now exclude traffic to dynamically located SaaS services from a VPN tunnel in Hub Mode. The Security Gateway fetches the locations of excluded services from Internet feeds. When VPN clients connect to a Security Gateway, the gateway sends the locations of excluded services to propagated VPN clients.
> 
> This feature requires a Gateway hotfix. Contact Check Point Support for more details.
> 
> EPS-38184
> 
> Endpoint Protection Solution for Terminal Servers is now open for all customers in Public Early Availability. See sk176939 for setup.
> 
> IOC Management
> 
> AHTP-23676
> 
> The user can now add IOCs to his Management Endpoint by specifying hashes, domains, IPs or URLs that should be blocked by the Endpoint. Adding an IOC causes the Endpoint to block this IOC and protects the Endpoint from it.

**  
In a Nutshell**

Item

Description

Download Link

**Managed Client**

E86.20 Endpoint Security Clients for Windows OS

![](https://sc1.checkpoint.com/sc/images/download-m.png) (ZIP)

E86.20 Endpoint Security Clients for Windows OS - Dynamic package

![](https://sc1.checkpoint.com/sc/images/download-m.png) (EXE)

**VPN Standalone Client**

E86.20 Remote Access Clients for Windows

![](https://sc1.checkpoint.com/sc/images/download-m.png) (MSI)

**Capsule Docs**

E86.20 Capsule Docs Standalone Client

![](https://sc1.checkpoint.com/sc/images/download-m.png) (EXE)

**Documentation**

E86.20 Endpoint Security Client for Windows Release Notes (English)  
E86.20 Endpoint Security Client for Windows Release Notes (Japanese)  
sk164896 - Video: How to deploy and upgrade Endpoint Security Client?

**List of Resolved Issues and Enhancements in E86.20**

Show / Hide this section

> Enter the string to filter the below table:
> 
> ID
> 
> Description
> 
> General
> 
> EPS-37545
> 
> CPDA.EXE crashes at telemetry-sending if ProgramData folder is moved out of C: drive.
> 
> EPS-37336
> 
> When using the "Reconnect Tool" to connect to an already-connected Management Server, the client gets disconnected.
> 
> EPS-37550
> 
> Endpoint Client disconnects from the Management Server when using the Reconnect Tool and the Self Protection prompt is canceled.
> 
> EPS-37445
> 
> Clients are disconnected when certificates are switched to external from the Management Server.
> 
> EPS-36653
> 
> In rare scenarios disconnected Endpoint Clients are mistakenly switched to Connected state (by way of the "Connected" policy) for several minutes.
> 
> Anti-Malware
> 
> EPS-37711
> 
> In the Super Node environment, anti-malware signatures are not distributed correctly.
> 
> FDE
> 
> EPS-35952
> 
> Enhancement: Options for fdectonrol.exe to override the Autologon hardware check are added. If hardware change(s) are expected and there is a temporary need to keep the AutoLogon enabled, the hardware-check can be overriden via the fdecontrol.exe tool.
> 
> Threat Emulation
> 
> AHTP-23593
> 
> Enhancement: The Threat Emulation blade is enhanced to support additional file types. Therefore, it can now protect against many new types of files, thus enhancing the overall Endpoint security.
> 
> AHTP-23679
> 
> Enhancement: Upon any detection log, the user can now right-click the log and exclude the detection, which adds an exclusion to the Management Endpoint. The exclusion prevents this detection from taking place. It is a simplified way to automatically create exclusions once false detections are identified in the logs.
> 
> Firewall & Application Control
> 
> EPS-37192
> 
> In rare scenarios, the Endpoint Client hangs for a while during VPN policy installation.
> 
> EPS-32786
> 
> Adding a Firewall blade after initial client deployment, while using IPV6 only, disconnects the Endpoint Client from the Management Server.
> 
> Media Encryption & Port Protection
> 
> EPS-37418
> 
> When a device is in the middle of the encryption process, it shows a UserCheck message that writing business data is not allowed.
> 
> EPS-36579
> 
> Enhancement: Added support for Installing Media Encryption & Port protection via the msiexec /norestart switch. However, when done from Software deployment, a restart request is still shown.
> 
> User Interface
> 
> EPS-34614
> 
> The initial client has a new user interface that reflects the current status of the client
> 
> EPS-37522
> 
> Forensics blade's name in the overview screen translation is inorrect.
> 
> VPN
> 
> ESVPN-3084
> 
> Enhancement: A certificate from the Windows store can now be automatically selected during the first connection using the trac.exe command line utility. If this option is enabled and only one matching certificate in the Windows store exists, trac.exe selects that certificate and connects to VPN automatically. 
> 
> Usage: trac.exe connect -a true
> 
> ESVPN-3119
> 
> Users have access to the directory where the installation repair occurs. Since the MS Installer allows regular users to run the repair, an attacker can initiate the installation repair and place a specially crafted EXE in the repair folder which runs with Remote Access Client privileges (CVE-2021-30360 resolution)
> 
> ESVPN-3044
> 
> The Secure Configuration Verification can now recognize Windows 11. See sk176367 for details on how to configure SCV.

**  
Endpoint Security Clients Downloads****Standalone Clients Downloads****Endpoint Security Server Downloads ****Management Console Downloads**

Show / Hide this section

> **_Management Console for Endpoint Security Server_**
> 
> The SmartConsole for Endpoint Security Server allows the Administrator to connect to the Endpoint Security Server and to manage the new Endpoint Security Software Blades.
> 
> **Latest Versions**
> 
> Endpoint Security Server
> 
> Package
> 
> Link
> 
> R81.10
> 
> SmartConsole for Endpoint Security Server R81.10 
> 
> sk175188
> 
> R81
> 
>  SmartConsole for Endpoint Security Server R81 
> 
> sk170116
> 
> R80.40
> 
>  SmartConsole for Endpoint Security Server R80.40 
> 
> sk165473
> 
> **Previous Versions**
> 
> Endpoint Security Server
> 
> Package
> 
> Link
> 
> R80.30
> 
>  SmartConsole for Endpoint Security Server R80.30
> 
> sk153153
> 
> R80.20
> 
>  SmartConsole for Endpoint Security Server R80.20
> 
> sk137593
> 
> R77.30.03
> 
>  SmartConsole for Endpoint Security Server R77.30.03 / E86.20 and higher
> 
> ![](https://sc1.checkpoint.com/sc/images/download-m.png) (EXE)
> 
> R77.30
> 
>  SmartConsole for Endpoint Security Server R77.30 / E86.20 and higher
> 
> ![](https://sc1.checkpoint.com/sc/images/download-m.png) (EXE)
> 
> R80.10
> 
>  SmartConsole for Endpoint Security Server R80.10
> 
> sk119612
> 
> R77.30 EP6.5
> 
>  SmartConsole for Endpoint Security Server R77.30 EP6.5 / E86.20 and higher 
> 
> ![](https://sc1.checkpoint.com/sc/images/download-m.png) (EXE)
> 
> R77.20 EP6.2
> 
> SmartConsole for Endpoint Security Server R77.20 EP6.2 / E86.20 and higher
> 
> ![](https://sc1.checkpoint.com/sc/images/download-m.png) (EXE)
> 
> **Note**: The above packages include the Recovery Image of version 86.8.62.6

**Utilities/Services Downloads**

Show / Hide this section

> **Utilities**
> 
> Platform
> 
> Package
> 
> Description
> 
> Link
> 
> **Windows**
> 
> Harmony Endpoint Remediation Manager for Administrators
> 
> The administrator utility contains the capabilities of the end-user utility plus these additional features:
> 
> *   Quarantine - Send files to quarantine. 
> *   Delete - Use the Harmony Endpoint remediation service to delete a file. 
> *   Import - Import a quarantined file from a different computer or location. Get the administrator utility from the release homepage
> 
> ![](https://sc1.checkpoint.com/sc/images/download-m.png) (EXE)
> 
> Capsule Docs Bulk Protection Services for Windows-based Servers and Workstations
> 
> Capsule Docs Bulk Protection lets you manage file protection settings based on file locations and properties. 
> 
> ![](https://sc1.checkpoint.com/sc/images/download-m.png) (EXE)
> 
> R77.30 DLP Gateway HF for Content-aware Capsule Docs protection (Mail attachments / Network locations)
> 
>  
> 
> ![](https://sc1.checkpoint.com/sc/images/download-m.png) (TGZ)
> 
> For more information about Capsule Docs Bulk Protection, refer to Capsule Docs Bulk Protection Services Reference Guide.
> 
> **Full Disk Encryption Offline Management Tool**
> 
> Platform
> 
> Package
> 
> Description
> 
> Link
> 
> **Windows**
> 
> Full Disk Encryption Offline Management Tool
> 
> The Endpoint Offline Management Tool lets administrators manage offline mode users and give them password recovery and disk recovery.
> 
> ![](https://sc1.checkpoint.com/sc/images/download-m.png) (TGZ)
> 
> **Windows**
> 
> Full Disk Encryption Offline Management Tool (Japanese)
> 
> The Endpoint Offline Management Tool lets administrators manage offline mode users and give them password recovery and disk recovery.
> 
> ![](https://sc1.checkpoint.com/sc/images/download-m.png) (TGZ)

**  
Documentation and Related SecureKnowledge Articles**

CVE-2021-30360: Enterprise Endpoint Security E86.20 Windows Clients

IBM AIX 7.1, 7.2, and VIOS 3.1 could allow a non-privileged local user to exploit a vulnerability in the mount command which could lead to code execution. IBM X-Force ID: 212952.

CVE-2021-38990: IBM AIX code execution CVE-2021-38990 Vulnerability Report

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

IBM PowerVM Hypervisor FW860, FW940, FW950, and FW1010, through a specific sequence of VM management operations could lead to a violation of the isolation between peer VMs. IBM X-Force ID: 210019.

**Security Bulletin**

  

**Summary**

A specific sequence of VM management operations from the management console (HMC, Novalink, or PowerVC) can lead to a violation of the isolation between peer VMs.

**Vulnerability Details**

**CVEID:**   CVE-2021-38918  
**DESCRIPTION:**   IBM PowerVM Hypervisor through a specific sequence of VM management operations could lead to a violation of the isolation between peer VMs.  
CVSS Base score: 8.6  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/210019 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N)

**Affected Products and Versions**

Affected Product(s)

Version(s)

PowerVM Hypervisor

FW860

PowerVM Hypervisor

FW1010

PowerVM Hypervisor

FW940

PowerVM Hypervisor

FW950

**Remediation/Fixes**

Customers with the products below should install FW860.A2(860\_236), FW940.50(940\_095), FW950.30(950\_092), FW1010.01(1010\_69) or newer to remediate this concern.

Power 8

1) IBM Power System S812 (8284-21A)

2) IBM Power System S822 (8284-22A)

3) IBM Power System S814 (8286-41A)

4) IBM Power System S824 (8286-42A)

5) IBM Power System E850 (8408-E8E)

6) IBM Power System E850C (8408-44E)

7) IBM Power System E870 (9119-MME)

8) IBM Power System E880 (9119-MHE)

9) IBM Power System E870C (9080-MME)

10) IBM Power System E880C (9080-MHE)

Power 9

1) IBM Power System S922 (9009-22A, 9009-22G)

2) IBM Power System H922 (9223-22H, 9223-22S)

3) IBM Power System S914 (9009-41A, 9009-41G)

4) IBM Power System S924 (9009-42A, 9009-42G)

5) IBM Power System H924 (9223-42H, 9223-42S)

6) IBM Power System E950 (9040-MR9)

7) IBM Power System E980 (9080-M98, 9080-M9S)

Power 10

1) IBM Power System E1080 (9080-HEX)

**Workarounds and Mitigations**

None

**References**

Off

**Acknowledgement**

**Change History**

02 Dec 2021: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\\/TPS"},"Product":{"code":"HW1A1","label":"Power Systems"},"Component":"","Platform":\[{"code":"PF009","label":"Firmware"}\],"Version":"all","Edition":"","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}}\]

CVE-2021-38918: Security Bulletin: The PowerVM hypervisor can violate the isolation between peer VMs in certain scenarios

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

A download of code without integrity check vulnerability in the "execute restore src-vis" command of FortiOS before 7.0.3 may allow a local authenticated attacker to download arbitrary files on the device via specially crafted update packages.

**![](https://fortiguard.com/static/images/icons/psirt.svg?v=5073) PSIRT Advisories**

**FortiOS - Removal of \`restore src-vis\` command.**

**Summary**

A download of code without integrity check vulnerability \[CWE-494\] in the "execute restore src-vis" command of FortiOS may allow a local authenticated attacker to download arbitrary files on the device via specially crafted update packages.

**Exploitation Status:**

Fortinet is aware of an instance where this vulnerability was abused and recommends immediately validating your systems for indicators of compromise:

*   Unexpected files on the FortiGate Device (list files with \`fnsysctl ls\`)
    *   /data2/virc.dat
    *   /data2/vire
    *   /data2/vire.tar.gz
    *   /data2/vire.tar
    *   /data2/vird
    *   /data2/gettd
    *   /data2/smartctll
    *   /data2/ftar
    *   /data2/reportnd
    *   /data2/llpdtd
    *   /data2/flcfgt
    *   /data2/viree/vire/inject
    *   /data2/viree/vire/insmod
    *   /data2/viree/vire/hack.o
    *   /data2/viree/vire/libips.so
    *   /bin/lldptd
    *   /data/lib/libipsx.so
    *   /data2/viree/vire/ld.so.preload
    *   /etc/ld.so.preload
*   Unexpected processes running on the FortiGate device
    *   The following unexpected processes were found to be running on the device when running \`fnsysctl ps\`:
        *   30892 0 0 S ash -c /bin/flcfgt>/data2/44.txt 2>&1
        *   30068 0 0:00 {smartctl} ash -c /data2/smartctl ps>/data2/17.txt 2>
*   Unexpected traffic sourced from the FortiGate device
    *   Traffic has been observed to the following C&C servers on port 7443 (Plaintext HTTP):
        *   192.46.213.244
        *   172.105.181.67

**Affected Products**

FortiOS versions 6.0.13 and below,  
FortiOS versions 6.2.9 and below,  
FortiOS versions 6.4.7 and below,  
FortiOS versions 7.0.2 and below.

**Solutions**

Upgrade to FortiOS 6.0.14 or above,  
Upgrade to FortiOS 6.2.10 or above,  
Upgrade to FortiOS 6.4.8 or above,  
Upgrade to FortiOS 7.0.3 or above.

CVE-2021-44168: Fortiguard

A BIOS bug in firmware for a particular PC model leaves the Platform authorization value empty. This can be used to permanently brick the TPM in multiple ways, as well as to non-permanently DoS the system.

**Related documentation**

*   Creating an account

You are not authorized to access bug #3499. To see this bug, you must first log in to an account with the appropriate permissions.

Please press **Back** and try again.

Tag

#ios