Headline
CVE-2021-40425: TALOS-2021-1433 || Cisco Talos Intelligence Group
An out-of-bounds read vulnerability exists in the IOCTL GetProcessCommand and B_03 of Webroot Secure Anywhere 21.4. A specially-crafted executable can lead to denial of service. An attacker can issue an ioctl to trigger this vulnerability. An out-of-bounds read vulnerability exists in the IOCTL GetProcessCommand and B_03 of Webroot Secure Anywhere 21.4. An IOCTL_B03 request with specific invalid data causes a similar issue in the device driver WRCore_x64. An attacker can issue an ioctl to trigger this vulnerability.
Summary
An out-of-bounds read vulnerability exists in the IOCTL GetProcessCommand and B_03 of Webroot Secure Anywhere 21.4. A specially-crafted executable can lead to denial of service. An attacker can issue an ioctl to trigger this vulnerability.
Tested Versions
Webroot Secure Anywhere 21.4
Product URLs
Secure Anywhere - https://www.webroot.com/us/en/home/products/av
CVSSv3 Score
7.1 - CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
CWE
CWE-125 - Out-of-bounds Read
Details
A windows device driver is almost like a kernel DLL that, once loaded, provides additional features. In order to communicate with these device drivers, Windows has a major component named Windows I/O Manager. The Windows IO Manager is responsible for the interface between user applications and device drivers. It implements I/O Request Packets (IRP) to enable the communication with the devices drivers, answering to all I/O requests.
For more information see the Microsoft website https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/example-i-o-request—an-overview.
The driver is responsible for creating a device interface with different functions to answer to specific codes, named major code function. If the designer wants to implement customized functions into a driver, there is one major function code named IRP_MJ_DEVICE_CONTROL. Handling such major code function, device drivers will support specific I/O Control Code (IOCTL) through a dispatch routine.
The Windows I/O Manager provides three different methods to enable the shared memory: - Buffered I/O - Direct I/O - Neither I/O
Without getting into the details of the IO Manager mechanisms, the method Buffered I/O is often the easiest one for handling memory user buffers from a device perspective.
The I/O Manager is providing all features to enable device drivers sharing buffers between userspace and kernelspace. It will be responsible for copying data back and forth.
Let’s see some examples of routines (which you should not copy as is) that explain how things work.
When creating a driver, you’ll have several functions to implement, and you’ll find some dispatcher routines to handle different IRP as follows:
extern "C"
NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT pDriverObject, _In_ PUNICODE_STRING RegistryPath)
{
[...]
pDriverObject->DriverUnload = DriverUnload;
pDriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = DriverIOctl;
pDriverObject->MajorFunction[IRP_MJ_CREATE] = DriverCreate;
pDriverObject->MajorFunction[IRP_MJ_CLOSE] = DriverClose;
[...]
}
The DriverEntry is the function main for a driver. This is the place where initializations start.
We can see for example the pDriverObject which is a PDRIVER_OBJECT object given by the system to associate different routines, to be called against specific codes, into the Majorfunction table IRP_MJ_DEVICE_CONTROL for DriverIOctl etc.
Then later inside the driver you’ll see the implementation of the DriverIOctl routine responsible for handling the IOCTL code. It can be something like below:
NTSTATUS DriverIOctl(PDEVICE_OBJECT pDevObject, PIRP pIrp)
{
[...]
auto pIrpSp = IoGetCurrentIrpStackLocation(pIrp);
switch (pIrpSp->Parameters.DeviceIoControl.IoControlCode)
{
case IO_CREATE_EXAMPLE:
ioctl_inbuffer_data = (ioctl_inbuffer*)pIrp->AssociatedIrp.SystemBuffer;
auto InputBufferLength = pIrpSp->Parameters.DeviceIoControl.InputBufferLength;
auto OutputBufferLength = pIrpSp->Parameters.DeviceIoControl.OutputBufferLength;
[...] some code
pIrp->IoStatus.Information = 0;
pIrp->IoStatus.Status = status;
break;
}
pIrp->IoStatus.Information = some value;
pIrp->IoStatus.Status = status;
return status;
}
First the we can see the pIrp pointer to an IRP structure (the description would be out of the scope of this document). Keep in mind this pointer will be useful for accessing data.
So here for example we can observe some switch-case implementation depending on the IoControlCode IOCTL. When the device driver gets an IRP with code value IO_CREATE_EXAMPLE, it performs the operations below the case. To get into the buffer data exchanged between userspace and kernelspace and vice-versa, we’ll look into SystemBuffer passed as an argument through the pIrp pointer.
On the device side, the pointer inside an IRP represents the user buffer, usually a field named Irp->AssociatedIrp.SystemBuffer, when the buffered I/O mechanism is chosen. The specification of the method is indicated by the code itself.
On the userspace side, an application would need to gain access to the device driver symbolic link if it exists, then send some ioctl requests as follows:
success = ::DeviceIoControl(
ghDevice,
IO_CREATE_EXAMPLE, // control code
&gpIoctl, // input buffer
sizeof(struct ioctl_inbuffer), // input buffer length
&gpIoctl, // output buffer
sizeof(struct ioctl_inbuffer), // output buffer length
&returned,
nullptr
);
Such a call will result in an IRP with a major code IRP_MJ_DEVICE_CONTROL and a control code to IO_CREATE_EXAMPLE. The buffer passed from userspace here as input gpIoctl, and output will be accessible from the device driver in the kernelspace via pIrp->AssociatedIrp.SystemBuffer. The lengths specified on the DeviceIoControl parameters will be used to build the IRP, and the device would be able to get them into the InputBufferLength and the OutputBufferLength respectively.
Now below we’ll see two examples of out-of-bounds read, which can lead to different behaviors and more frequently a local denial of service and blue screen of death through the usage of the device driver WRCore_x64.
CVE-2021-40424 - Out-of-bounds GetProcessCommandLine
The GetProcessCommandLine IOCTL request could cause an out-of-bounds read in the device driver WRCore_x64, as shown below:
WRCore_x64+0x190b:
fffff80f`ad60190b 8b4024 mov eax,dword ptr [rax+24h] ds:ffff8488`e3a0b004=????????
When inspecting the memory, we see the out-of-bounds read in non-mapped memory
3: kd> dq ffff8488e3a0afe0
ffff8488`e3a0afe0 00000000`00000000 00000000`00000000
ffff8488`e3a0aff0 00000000`00000000 55555555`55555555
ffff8488`e3a0b000 ????????`???????? ????????`????????
ffff8488`e3a0b010 ????????`???????? ????????`????????
ffff8488`e3a0b020 ????????`???????? ????????`????????
ffff8488`e3a0b030 ????????`???????? ????????`????????
ffff8488`e3a0b040 ????????`???????? ????????`????????
ffff8488`e3a0b050 ????????`???????? ????????`????????
The call stack is the following, clearly indicating the out-of-bounds happening in WRCore_x64+0x190b
3: kd> k
# Child-SP RetAddr Call Site
00 ffffe781`793f6c18 fffff802`1946046f nt!KeBugCheckEx
01 ffffe781`793f6c20 fffff802`192b5500 nt!MiSystemFault+0x18d0bf
02 ffffe781`793f6d20 fffff802`1941b35e nt!MmAccessFault+0x400
03 ffffe781`793f6ec0 fffff80f`ad60190b nt!KiPageFault+0x35e
04 ffffe781`793f7050 fffff80f`ad61decf WRCore_x64+0x190b
05 ffffe781`793f7080 fffff80f`ad61c6d3 WRCore_x64+0x1decf
06 ffffe781`793f7110 fffff802`193830b7 WRCore_x64+0x1c6d3
07 ffffe781`793f7140 fffff802`199d7f1a nt!IopfCallDriver+0x53
08 ffffe781`793f7180 fffff802`19454db1 nt!IovCallDriver+0x266
09 ffffe781`793f71c0 fffff802`1968b308 nt!IofCallDriver+0x1af5a1
0a ffffe781`793f7200 fffff802`1968abd5 nt!IopSynchronousServiceTail+0x1a8
0b ffffe781`793f72a0 fffff802`1968a5d6 nt!IopXxxControlFile+0x5e5
0c ffffe781`793f73e0 fffff802`1941ebb5 nt!NtDeviceIoControlFile+0x56
0d ffffe781`793f7450 00007ffa`a450ce54 nt!KiSystemServiceCopyEnd+0x25
0e 00000026`34d4fbf8 00000000`00000000 0x00007ffa`a450ce54
This corresponds to the following pseudo-code named get_hprocess_from_webroot_irp. The function get_hprocess_from_webroot_irp has an argument named here webroot_irp; we’ll see later where it’s coming from.
LINE1 __int64 __fastcall get_hprocess_from_webroot_irp(webroot_irp *webroot_irp)
LINE2 {
LINE3 if ( webroot_irp->possible_size_of_self <= 32ui64 )
LINE4 j_rtl_failfast_wrappoer((__int64)webroot_irp);
LINE5 return (unsigned int)webroot_irp->getProcessInfo->hprocess;
LINE6 }
The out-of-bounds read happens at LINE5 while attempting to read what should be the hprocess.
The function get_hprocess_from_webroot_irp is called at LINE28 from a function named GetProcessCommandLine. The function GetProcessCommandLine is an IOCTL handler which is responsible for returning information against some specific process ID. Here below, the pseudo-code corresponds to GetProcessCommandLine:
LINE8 MACRO_STATUS __fastcall GetProcessCommandLine(IRP *pIrp, _IO_STACK_LOCATION *io_stack_loc)
LINE9 {
[...]
LINE20
LINE21 if ( io_stack_loc->Parameters.DeviceIoControl.InputBufferLength < 0x18
LINE22 || io_stack_loc->Parameters.DeviceIoControl.OutputBufferLength < 0x18 )
LINE23 {
LINE24 return STATUS_SINGLE_STEP|STATUS_OBJECT_NAME_EXISTS;
LINE25 }
LINE26 build_webroot_irp(&webroot_irp, (getProcessInfo *)pIrp->AssociatedIrp.SystemBuffer);
LINE27 process_list_related_0 = (process_related *)get_process_list_related_0();
LINE28 p_systemBuffer = get_hprocess_from_webroot_irp(&webroot_irp);
LINE29 sub_14000F8EC(process_list_related_0, &_result, p_systemBuffer);
LINE30 nt_status = 0;
LINE31 if ( !_result.some_ptr )
LINE32 {
LINE33 nt_status = STATUS_UNSUCCESSFUL;
LINE34 LABEL_11:
LINE35 sub_14000159C(&_result);
LINE36 sub_14001C190(&webroot_irp);
LINE37 return (unsigned __int64)nt_status;
LINE38 }
LINE39 field_28_of_irp = get_field_28_of_irp(&webroot_irp);
LINE40 size_to_check = (unsigned __int64)*(unsigned __int16 *)sub_14000D5E8(_result.some_ptr) >> 1;
LINE41 v8 = *(_WORD **)sub_140001A8C(&webroot_irp);
LINE42 if ( !v8 || field_28_of_irp < size_to_check )
LINE43 {
LINE44 // set some length
LINE45 sub_14000199C(&webroot_irp, size_to_check);
LINE46 pIrp->IoStatus.Information = 24i64;
LINE47 goto LABEL_11;
LINE48 }
LINE49 v9 = sub_14000D5E8(_result.some_ptr);
LINE50 v10 = &word_140028480;
LINE51 if ( *(_QWORD *)(v9 + 8) )
LINE52 v10 = *(const wchar_t **)(v9 + 8);
LINE53 _mm_lfence();
LINE54 ProbeForWrite(v8, size_to_check, 1u);
LINE55 perform_write_into_dest(v8, field_28_of_irp, (__int64)v10, size_to_check);
LINE56 _mm_lfence();
LINE57 sub_140001810(&webroot_irp, size_to_check);
LINE58 pIrp->IoStatus.Information = 24i64;
LINE59 sub_14000159C(&_result);
LINE60 sub_14001C190(&webroot_irp);
LINE61 return 0i64;
LINE62 }
The function build_webroot_irp, called at LINE26, is responsible for building the webroot_irp object, which will be used as an argument in the culprit function.
LINE63 webroot_irp *__fastcall build_webroot_irp(webroot_irp *webroot_irp, getProcessInfo *getProcessInfoData)
LINE64 {
LINE65 webroot_irp->table_function = &off_14002AAA0;
LINE66 webroot_irp->byte8 = 0;
LINE67 webroot_irp->qword10 = 0i64;
LINE68 webroot_irp->PERESOURCE = 0i64;
LINE69 webroot_irp->qword20 = 0i64;
LINE70 webroot_irp->possible_size_of_self = 56i64;
LINE71 webroot_irp->getProcessInfo = getProcessInfoData;
LINE72 if ( !getProcessInfoData )
LINE73 j_rtl_failfast_wrappoer((__int64)webroot_irp);
LINE74 webroot_irp->table_function = &off_14002AAA0;
LINE75 return webroot_irp;
LINE76 }
When looking at LINE26, we can see our buffer AssociatedIrp.SystemBuffer is corresponding to the parameter named here getProcessInfoData. The function build_webroot_irp is associating the buffer getProcessInfoData to the variable webroot_irp->getProcessInfo as we can see at LINE71.
When reversing a bit more the functions around this spot, we can deduce the expected structure getProcessInfo format should correspond to something like:
00000000 getProcessInfo struc ; (sizeof=0x38, mappedto_561)
00000000 qword_1 dq ?
00000008 qword_2 dq ?
00000010 qword_3 dq ?
00000018 qword_4 dq ?
00000020 dword_1 dd ?
00000024 hprocess dd ?
00000028 length dq ?
00000030 output_buffer dq ?
00000038 getProcessInfo ends
The getProcessInfoData corresponds to the user buffer we can control from userspace as input buffer.
We can see here the hprocess at offset 0x24. And this is the hprocess field from the structure getProcessInfo which corresponds to the read value in the culprit function get_hprocess_from_webroot_irp without precaution, causing the out-of-bounds read. The issue is the checks done in LINE21 and LINE22 are not preventing the out-of-bounds read happening, as they check only for valid input up to input size of 0x18 bytes.
Crash Information
3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: ffff8488e3a0b004, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffff80fad60190b, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000002, (reserved)
Debugging Details:
------------------
Unable to load image \??\C:\Program Files\Webroot\Core\WRCore.x64.sys, Win32 error 0n2
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 3078
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 4492
Key : Analysis.Init.CPU.mSec
Value: 7921
Key : Analysis.Init.Elapsed.mSec
Value: 22374
Key : Analysis.Memory.CommitPeak.Mb
Value: 83
Key : WER.OS.Branch
Value: vb_release
Key : WER.OS.Timestamp
Value: 2019-12-06T14:06:00Z
Key : WER.OS.Version
Value: 10.0.19041.1
VIRTUAL_MACHINE: HyperV
BUGCHECK_CODE: 50
BUGCHECK_P1: ffff8488e3a0b004
BUGCHECK_P2: 0
BUGCHECK_P3: fffff80fad60190b
BUGCHECK_P4: 2
READ_ADDRESS: ffff8488e3a0b004 Special pool
MM_INTERNAL_CODE: 2
IMAGE_NAME: WRCore.x64.sys
MODULE_NAME: WRCore.x64
FAULTING_MODULE: 0000000000000000
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXWINLOGON: 1
PROCESS_NAME: webroot_ioctl_a01.exe
TRAP_FRAME: ffffe781793f6ec0 -- (.trap 0xffffe781793f6ec0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffff8488e3a0afe0 rbx=0000000000000000 rcx=ffffe781793f70b8
rdx=ffff8488e3a0afe0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80fad60190b rsp=ffffe781793f7050 rbp=ffff8488df571d80
r8=ffff8488df571d80 r9=000000000000000e r10=fffff80fad61c554
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
WRCore_x64+0x190b:
fffff80f`ad60190b 8b4024 mov eax,dword ptr [rax+24h] ds:ffff8488`e3a0b004=????????
Resetting default scope
STACK_TEXT:
ffffe781`793f6c18 fffff802`1946046f : 00000000`00000050 ffff8488`e3a0b004 00000000`00000000 ffffe781`793f6ec0 : nt!KeBugCheckEx
ffffe781`793f6c20 fffff802`192b5500 : 00000000`00001000 00000000`00000000 ffffe781`793f6f40 00000000`00000000 : nt!MiSystemFault+0x18d0bf
ffffe781`793f6d20 fffff802`1941b35e : 00000000`00000001 00000000`00001000 00000000`00000000 00000000`00000000 : nt!MmAccessFault+0x400
ffffe781`793f6ec0 fffff80f`ad60190b : fffff802`1968b308 fffff802`199eaf31 ffff8488`e377d0d8 fffff802`199f3a48 : nt!KiPageFault+0x35e
ffffe781`793f7050 fffff80f`ad61decf : ffff8488`e0205650 ffff8488`e2afe9a0 ffff8488`e377d0d8 fffff802`199e311a : WRCore_x64+0x190b
ffffe781`793f7080 fffff80f`ad61c6d3 : 00000000`00000000 ffff8488`df5196a0 ffff8488`df5195d0 ffff8488`e0205650 : WRCore_x64+0x1decf
ffffe781`793f7110 fffff802`193830b7 : ffff8488`df5195d0 00000000`00000000 ffff8488`00000001 ffff8488`df571d80 : WRCore_x64+0x1c6d3
ffffe781`793f7140 fffff802`199d7f1a : ffff8488`df5195d0 ffff8488`df571d80 00000000`20206f49 00000000`00000000 : nt!IopfCallDriver+0x53
ffffe781`793f7180 fffff802`19454db1 : ffff8488`df5195d0 00000000`00000002 00000000`00000028 ffff8488`e0205650 : nt!IovCallDriver+0x266
ffffe781`793f71c0 fffff802`1968b308 : ffffe781`793f7540 ffff8488`df5195d0 00000000`00000001 ffffe781`793f7540 : nt!IofCallDriver+0x1af5a1
ffffe781`793f7200 fffff802`1968abd5 : 00000000`9c412804 ffffe781`793f7540 00000000`00000000 ffffe781`793f7540 : nt!IopSynchronousServiceTail+0x1a8
ffffe781`793f72a0 fffff802`1968a5d6 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x5e5
ffffe781`793f73e0 fffff802`1941ebb5 : 00000000`000000e8 00000000`00000000 00000000`77566d4d ffffe781`793f74a8 : nt!NtDeviceIoControlFile+0x56
ffffe781`793f7450 00007ffa`a450ce54 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25
00000026`34d4fbf8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffa`a450ce54
STACK_COMMAND: .thread ; .cxr ; kb
FAILURE_BUCKET_ID: AV_VRF_R_INVALID_IMAGE_WRCore.x64.sys
OS_VERSION: 10.0.19041.1
BUILDLAB_STR: vb_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {4487bf4b-fcaa-ab42-3f1b-e48f350aad47}
Followup: MachineOwner
---------
CVE-2021-40425 - Out-of-bounds IOCTL_B03
Another IOCTL request with specific invalid data causes a similar issue in the device driver WRCore_x64, as shown below:
WRCore_x64+0x192b:
fffff803`8a87192b 8b4020 mov eax,dword ptr [rax+20h] ds:ffffe48f`d8063000=????????
Investigating the call stack should lead us to the culprit routine :
3: kd> k
# Child-SP RetAddr Call Site
00 ffff810a`4aae4478 fffff801`03d24b12 nt!DbgBreakPointWithStatus
01 ffff810a`4aae4480 fffff801`03d240f6 nt!KiBugCheckDebugBreak+0x12
02 ffff810a`4aae44e0 fffff801`03c092b7 nt!KeBugCheck2+0x946
03 ffff810a`4aae4bf0 fffff801`03c5c46f nt!KeBugCheckEx+0x107
04 ffff810a`4aae4c30 fffff801`03ab1500 nt!MiSystemFault+0x18d0bf
05 ffff810a`4aae4d30 fffff801`03c1735e nt!MmAccessFault+0x400
06 ffff810a`4aae4ed0 fffff803`8a87192b nt!KiPageFault+0x35e
07 ffff810a`4aae5060 fffff803`8a88e079 WRCore_x64+0x192b
08 ffff810a`4aae5090 fffff803`8a88c760 WRCore_x64+0x1e079
09 ffff810a`4aae5110 fffff801`03b7f0b7 WRCore_x64+0x1c760
0a ffff810a`4aae5140 fffff801`041d3f1a nt!IopfCallDriver+0x53
0b ffff810a`4aae5180 fffff801`03c50db1 nt!IovCallDriver+0x266
0c ffff810a`4aae51c0 fffff801`03e87308 nt!IofCallDriver+0x1af5a1
0d ffff810a`4aae5200 fffff801`03e86bd5 nt!IopSynchronousServiceTail+0x1a8
0e ffff810a`4aae52a0 fffff801`03e865d6 nt!IopXxxControlFile+0x5e5
0f ffff810a`4aae53e0 fffff801`03c1abb5 nt!NtDeviceIoControlFile+0x56
10 ffff810a`4aae5450 00007ff9`b24ece54 nt!KiSystemServiceCopyEnd+0x25
11 00000045`4e31fb28 00007ff9`aff5b07b ntdll!NtDeviceIoControlFile+0x14
12 00000045`4e31fb30 00007ff9`b09a5611 KERNELBASE!DeviceIoControl+0x6b
13 00000045`4e31fba0 00007ff7`e9271142 KERNEL32!DeviceIoControlImplementation+0x81
14 00000045`4e31fbf0 00000000`00000000 poc+0x1142
So it turns out the WRCore_x64+0x192b looks to be where the out-of-bounds is occurring. This corresponds to the following pseudo-code:
LINE77 __int64 __fastcall sub_14000191C(webroot_irp *iob)
LINE78 {
LINE79 if ( iob->self_size <= 0x20ui64 )
LINE80 j_rtl_failfast_wrappoer((__int64)iob);
LINE81 return (unsigned int)iob->SystemBuffer->field_20;
LINE82 }
We can see at LINE81 a variable here named field_20 from iob->SystemBuffer.
The subroutine sub_14000191C is called directly from the ioctl dispatcher routine ioctl_2 associated with following pseudo code:
LINE84 __int64 __fastcall ioctl_2(PIRP pIrp, _IO_STACK_LOCATION *psStackLocation)
LINE85 {
[...]
LINE93
LINE94 if ( psStackLocation->Parameters.DeviceIoControl.InputBufferLength < 32
LINE95 || psStackLocation->Parameters.DeviceIoControl.OutputBufferLength < 32 )
LINE96 {
LINE97 return 0xC0000004i64;
LINE98 }
LINE99 SystemBuffer = pIrp->AssociatedIrp.SystemBuffer;
LINE100 memset(&iob.qword10, 0, 24);
LINE101 iob.byte8 = 0;
LINE102 iob.self_size = 64i64;
LINE103 iob.SystemBuffer = SystemBuffer;
LINE104 if ( !SystemBuffer )
LINE105 goto LABEL_11;
LINE106 iob.table_function = &off_14002B920;
LINE107 process_list_related_0 = get_process_list_related_0();
LINE108 v5 = sub_14000191C(&iob);
LINE109 sub_14000F8EC(process_list_related_0, &a2, v5);
LINE110 some_ptr = a2.some_ptr;
LINE111 if ( a2.some_ptr )
LINE112 {
LINE113 pIrp->IoStatus.Information = 64i64;
LINE114 v7 = sub_14000D850(some_ptr, &iob);
LINE115 }
LINE116 else
LINE117 {
LINE118 v7 = STATUS_UNSUCCESSFUL;
LINE119 }
LINE120 sub_14000159C(&a2);
LINE121 iob.table_function = &off_14002B920;
LINE122 if ( iob.PERESOURCE )
LINE123 {
LINE124 if ( iob.self_size <= 0x20ui64 )
LINE125 LABEL_11:
LINE126 j_rtl_failfast_wrappoer((__int64)pIrp);
LINE127 }
LINE128 sub_1400076C8(&iob.byte8);
LINE129 return v7;
LINE130 }
At LINE108 we can see the call directly to the culprit subroutine using the variable iob.
The iob.SystemBuffer is directly derived from SystemBuffer which is in fact the IOCTL input SystemBuffer as indicated at LINE99.
When doing some reverse around function the attended SystemBuffer is structured like below:
00000000 ioctl_03 struc ; (sizeof=0x40, mappedto_625)
00000000 vftable dq ?
00000008 field_8 dq ?
00000010 field_10 dq ?
00000018 field_18 dq ?
00000020 hprocess dd ? ; XREF: sub_14000191C+F/r
00000024 field_24 dd ?
00000028 self_size dq ?
00000030 SystemBuffer dq ?
00000038 field_38 dq ?
00000040 ioctl_03 ends
We can see here the hprocess field at offset 0x20, which again checks the size length for input buffer and output buffer done at LINE94 and at LINE95. They are not big enough, as they allow an out-of-bounds read to happen when the function sub_14000191C is called.
Crash Information
3: kd> !analyze -v
Connected to Windows 10 19041 x64 target at (Thu Dec 2 18:11:33.195 2021 (UTC + 1:00)), ptr64 TRUE
Loading Kernel Symbols
...............................................................
................................................................
...........................................
Loading User Symbols
.............
Loading unloaded module list
.........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: ffffe48fd8063000, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffff8038a87192b, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000002, (reserved)
Debugging Details:
------------------
*** WARNING: Unable to verify checksum for poc.exe
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 7952
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 11787
Key : Analysis.Init.CPU.mSec
Value: 172905
Key : Analysis.Init.Elapsed.mSec
Value: 24533381
Key : Analysis.Memory.CommitPeak.Mb
Value: 92
Key : WER.OS.Branch
Value: vb_release
Key : WER.OS.Timestamp
Value: 2019-12-06T14:06:00Z
Key : WER.OS.Version
Value: 10.0.19041.1
BUGCHECK_CODE: 50
BUGCHECK_P1: ffffe48fd8063000
BUGCHECK_P2: 0
BUGCHECK_P3: fffff8038a87192b
BUGCHECK_P4: 2
READ_ADDRESS: ffffe48fd8063000 Special pool
MM_INTERNAL_CODE: 2
IMAGE_NAME: WRCore.x64.sys
MODULE_NAME: WRCore.x64
FAULTING_MODULE: 0000000000000000
PROCESS_NAME: poc.exe
TRAP_FRAME: ffff810a4aae4ed0 -- (.trap 0xffff810a4aae4ed0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffffe48fd8062fe0 rbx=0000000000000000 rcx=ffff810a4aae50c8
rdx=ffffe48fd6ab8f70 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8038a87192b rsp=ffff810a4aae5060 rbp=ffff810a4aae5100
r8=ffff8383152450b2 r9=0000000000000002 r10=fffff80103f14940
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
WRCore_x64+0x192b:
fffff803`8a87192b 8b4020 mov eax,dword ptr [rax+20h] ds:ffffe48f`d8063000=????????
Resetting default scope
STACK_TEXT:
ffff810a`4aae4478 fffff801`03d24b12 : ffff810a`4aae45e0 fffff801`03b8f200 fffff803`8a870000 00000000`00000000 : nt!DbgBreakPointWithStatus
ffff810a`4aae4480 fffff801`03d240f6 : fffff803`00000003 ffff810a`4aae45e0 fffff801`03c1e110 ffff810a`4aae4b30 : nt!KiBugCheckDebugBreak+0x12
ffff810a`4aae44e0 fffff801`03c092b7 : 00000000`00000000 00000000`00000000 ffffe48f`d8063000 ffffe48f`d8063000 : nt!KeBugCheck2+0x946
ffff810a`4aae4bf0 fffff801`03c5c46f : 00000000`00000050 ffffe48f`d8063000 00000000`00000000 ffff810a`4aae4ed0 : nt!KeBugCheckEx+0x107
ffff810a`4aae4c30 fffff801`03ab1500 : 00000000`00000000 00000000`00000000 ffff810a`4aae4f50 00000000`00000000 : nt!MiSystemFault+0x18d0bf
ffff810a`4aae4d30 fffff801`03c1735e : ffff8383`0d000100 fffff801`03a9b422 ffff8383`0d000340 00000000`000000ff : nt!MmAccessFault+0x400
ffff810a`4aae4ed0 fffff803`8a87192b : ffff8383`15774060 fffff803`8a88f986 00000000`00000000 ffffe48f`00000000 : nt!KiPageFault+0x35e
ffff810a`4aae5060 fffff803`8a88e079 : ffffe48f`d240b0d8 fffff801`041df11a ffff8383`15245e30 fffff801`03e87308 : WRCore_x64+0x192b
ffff810a`4aae5090 fffff803`8a88c760 : 00000000`00000000 ffffe48f`d6ab8ea0 00000000`00000000 ffffe48f`d5c48440 : WRCore_x64+0x1e079
ffff810a`4aae5110 fffff801`03b7f0b7 : ffffe48f`d6ab8ea0 00000000`00000000 ffffe48f`00000001 ffffe48f`d0f16290 : WRCore_x64+0x1c760
ffff810a`4aae5140 fffff801`041d3f1a : ffffe48f`d6ab8ea0 ffffe48f`d0f16290 00000000`20206f49 00000000`00000000 : nt!IopfCallDriver+0x53
ffff810a`4aae5180 fffff801`03c50db1 : ffffe48f`d6ab8ea0 00000000`00000002 00000000`00000028 ffffe48f`d5c48440 : nt!IovCallDriver+0x266
ffff810a`4aae51c0 fffff801`03e87308 : ffff810a`4aae5540 ffffe48f`d6ab8ea0 00000000`00000001 ffff810a`4aae5540 : nt!IofCallDriver+0x1af5a1
ffff810a`4aae5200 fffff801`03e86bd5 : 00000000`9c412c0c ffff810a`4aae5540 00000000`00000000 ffff810a`4aae5540 : nt!IopSynchronousServiceTail+0x1a8
ffff810a`4aae52a0 fffff801`03e865d6 : 00007ff9`b046d246 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x5e5
ffff810a`4aae53e0 fffff801`03c1abb5 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtDeviceIoControlFile+0x56
ffff810a`4aae5450 00007ff9`b24ece54 : 00007ff9`aff5b07b 00007ff9`b049f4e8 00000002`0000000c 000001c9`c66c0101 : nt!KiSystemServiceCopyEnd+0x25
00000045`4e31fb28 00007ff9`aff5b07b : 00007ff9`b049f4e8 00000002`0000000c 000001c9`c66c0101 00000045`4e31fb50 : ntdll!NtDeviceIoControlFile+0x14
00000045`4e31fb30 00007ff9`b09a5611 : 00000000`9c412c0c 00000000`00000000 00000000`00000000 00007ff9`b03bdd3e : KERNELBASE!DeviceIoControl+0x6b
00000045`4e31fba0 00007ff7`e9271142 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!DeviceIoControlImplementation+0x81
00000045`4e31fbf0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 000001c9`c66d15c0 : poc+0x1142
STACK_COMMAND: .thread ; .cxr ; kb
FAILURE_BUCKET_ID: AV_VRF_R_INVALID_IMAGE_WRCore.x64.sys
OS_VERSION: 10.0.19041.1
BUILDLAB_STR: vb_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {4487bf4b-fcaa-ab42-3f1b-e48f350aad47}
Followup: MachineOwner
---------
Timeline
2021-12-16 - Vendor disclosure
2022-03-15 - Public Release
Discovered by Emmanuel Tacheau of Cisco Talos.
Related news
An issue in upload.csp of FANTEC GmbH MWiD25-DS Firmware v2.000.030 allows attackers to write files and reset the user passwords without having a valid session cookie.
A vulnerability has been discovered in Moxa MGate which allows an attacker to perform a man-in-the-middle (MITM) attack on the device. This affects MGate MB3170 Series Firmware Version 4.2 or lower. and MGate MB3270 Series Firmware Version 4.2 or lower. and MGate MB3280 Series Firmware Version 4.1 or lower. and MGate MB3480 Series Firmware Version 3.2 or lower.
LDAP Account Manager (LAM) is an open source web frontend for managing entries stored in an LDAP directory. The profile editor tool has an edit profile functionality, the parameters on this page are not properly sanitized and hence leads to stored XSS attacks. An authenticated user can store XSS payloads in the profiles, which gets triggered when any other user try to access the edit profile page. The pdf editor tool has an edit pdf profile functionality, the logoFile parameter in it is not properly sanitized and an user can enter relative paths like ../../../../../../../../../../../../../usr/share/icons/hicolor/48x48/apps/gvim.png via tools like burpsuite. Later when a pdf is exported using the edited profile the pdf icon has the image on that path(if image is present). Both issues require an attacker to be able to login to LAM admin interface. The issue is fixed in version 7.9.1.
Nyron 1.0 is affected by a SQL injection vulnerability through Nyron/Library/Catalog/winlibsrch.aspx. To exploit this vulnerability, an attacker must inject '"> on the thes1 parameter.
A denial of service vulnerability exists in the parseNormalModeParameters functionality of MZ Automation GmbH libiec61850 1.5.0. A specially-crafted series of network requests can lead to denial of service. An attacker can send a sequence of malformed iec61850 messages to trigger this vulnerability.
Multiple cross-site scripting (XSS) vulnerabilities in Liferay Portal 7.3.5 through 7.4.0, and Liferay DXP 7.3 before service pack 3 allow remote attackers to inject arbitrary web script or HTML via a form field's help text to (1) Forms module's form builder, or (2) App Builder module's object form view's form builder.
Irzip v0.640 was discovered to contain a heap memory corruption via the component lrzip.c:initialise_control.
stb_image.h v2.27 was discovered to contain an integer overflow via the function stbi__jpeg_decode_block_prog_dc. This vulnerability allows attackers to cause a Denial of Service (DoS) via unspecified vectors.
stb_image.h v2.27 was discovered to contain an heap-based use-after-free via the function stbi__jpeg_huff_decode.
SuiteCRM v7.11.23 was discovered to allow remote code execution via a crafted payload injected into the FirstName text field.
**Why is Attack Complexity marked as High for this vulnerability?** Successful exploitation of this vulnerability requires an attacker to take additional actions prior to exploitation to prepare the target environment.
**Why is this Chrome CVE included in the Security Update Guide?** The vulnerability assigned to this CVE is in Chromium Open Source Software (OSS) which is consumed by Microsoft Edge (Chromium-based). It is being documented in the Security Update Guide to announce that the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable. Please see Security Update Guide Supports CVEs Assigned by Industry Partners for more information. **How can I see the version of the browser?** 1. In your Microsoft Edge browser, click on the 3 dots (...) on the very right-hand side of the window 2. Click on **Help and Feedback** 3. Click on **About Microsoft Edge**
**Why is this Chrome CVE included in the Security Update Guide?** The vulnerability assigned to this CVE is in Chromium Open Source Software (OSS) which is consumed by Microsoft Edge (Chromium-based). It is being documented in the Security Update Guide to announce that the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable. Please see Security Update Guide Supports CVEs Assigned by Industry Partners for more information. **How can I see the version of the browser?** 1. In your Microsoft Edge browser, click on the 3 dots (...) on the very right-hand side of the window 2. Click on **Help and Feedback** 3. Click on **About Microsoft Edge**
**Why is this Chrome CVE included in the Security Update Guide?** The vulnerability assigned to this CVE is in Chromium Open Source Software (OSS) which is consumed by Microsoft Edge (Chromium-based). It is being documented in the Security Update Guide to announce that the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable. Please see Security Update Guide Supports CVEs Assigned by Industry Partners for more information. **How can I see the version of the browser?** 1. In your Microsoft Edge browser, click on the 3 dots (...) on the very right-hand side of the window 2. Click on **Help and Feedback** 3. Click on **About Microsoft Edge**
**Why is this Chrome CVE included in the Security Update Guide?** The vulnerability assigned to this CVE is in Chromium Open Source Software (OSS) which is consumed by Microsoft Edge (Chromium-based). It is being documented in the Security Update Guide to announce that the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable. Please see Security Update Guide Supports CVEs Assigned by Industry Partners for more information. **How can I see the version of the browser?** 1. In your Microsoft Edge browser, click on the 3 dots (...) on the very right-hand side of the window 2. Click on **Help and Feedback** 3. Click on **About Microsoft Edge**
**Why is this Chrome CVE included in the Security Update Guide?** The vulnerability assigned to this CVE is in Chromium Open Source Software (OSS) which is consumed by Microsoft Edge (Chromium-based). It is being documented in the Security Update Guide to announce that the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable. Please see Security Update Guide Supports CVEs Assigned by Industry Partners for more information. **How can I see the version of the browser?** 1. In your Microsoft Edge browser, click on the 3 dots (...) on the very right-hand side of the window 2. Click on **Help and Feedback** 3. Click on **About Microsoft Edge**
**Why is this Chrome CVE included in the Security Update Guide?** The vulnerability assigned to this CVE is in Chromium Open Source Software (OSS) which is consumed by Microsoft Edge (Chromium-based). It is being documented in the Security Update Guide to announce that the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable. Please see Security Update Guide Supports CVEs Assigned by Industry Partners for more information. **How can I see the version of the browser?** 1. In your Microsoft Edge browser, click on the 3 dots (...) on the very right-hand side of the window 2. Click on **Help and Feedback** 3. Click on **About Microsoft Edge**
**Why is this Chrome CVE included in the Security Update Guide?** The vulnerability assigned to this CVE is in Chromium Open Source Software (OSS) which is consumed by Microsoft Edge (Chromium-based). It is being documented in the Security Update Guide to announce that the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable. Please see Security Update Guide Supports CVEs Assigned by Industry Partners for more information. **How can I see the version of the browser?** 1. In your Microsoft Edge browser, click on the 3 dots (...) on the very right-hand side of the window 2. Click on **Help and Feedback** 3. Click on **About Microsoft Edge**
**Why is this Chrome CVE included in the Security Update Guide?** The vulnerability assigned to this CVE is in Chromium Open Source Software (OSS) which is consumed by Microsoft Edge (Chromium-based). It is being documented in the Security Update Guide to announce that the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable. Please see Security Update Guide Supports CVEs Assigned by Industry Partners for more information. **How can I see the version of the browser?** 1. In your Microsoft Edge browser, click on the 3 dots (...) on the very right-hand side of the window 2. Click on **Help and Feedback** 3. Click on **About Microsoft Edge**
**Why is this Chrome CVE included in the Security Update Guide?** The vulnerability assigned to this CVE is in Chromium Open Source Software (OSS) which is consumed by Microsoft Edge (Chromium-based). It is being documented in the Security Update Guide to announce that the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable. Please see Security Update Guide Supports CVEs Assigned by Industry Partners for more information. **How can I see the version of the browser?** 1. In your Microsoft Edge browser, click on the 3 dots (...) on the very right-hand side of the window 2. Click on **Help and Feedback** 3. Click on **About Microsoft Edge**
**Why is this Chrome CVE included in the Security Update Guide?** The vulnerability assigned to this CVE is in Chromium Open Source Software (OSS) which is consumed by Microsoft Edge (Chromium-based). It is being documented in the Security Update Guide to announce that the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable. Please see Security Update Guide Supports CVEs Assigned by Industry Partners for more information. **How can I see the version of the browser?** 1. In your Microsoft Edge browser, click on the 3 dots (...) on the very right-hand side of the window 2. Click on **Help and Feedback** 3. Click on **About Microsoft Edge**
The Signal app before 5.34 for iOS allows URI spoofing via RTLO injection. It incorrectly renders RTLO encoded URLs beginning with a non-breaking space, when there is a hash character in the URL. This technique allows a remote unauthenticated attacker to send legitimate looking links, appearing to be any website URL, by abusing the non-http/non-https automatic rendering of URLs. An attacker can spoof, for example, example.com, and masquerade any URL with a malicious destination. An attacker requires a subdomain such as gepj, txt, fdp, or xcod, which would appear backwards as jpeg, txt, pdf, and docx respectively.
Metabase is an open source business intelligence and analytics application. SQLite has an FDW-like feature called `ATTACH DATABASE`, which allows connecting multiple SQLite databases via the initial connection. If the attacker has SQL permissions to at least one SQLite database, then it can attach this database to a second database, and then it can query across all the tables. To be able to do that the attacker also needs to know the file path to the second database. Users are advised to upgrade as soon as possible. If you're unable to upgrade, you can modify your SQLIte connection strings to contain the url argument `?limit_attached=0`, which will disallow making connections to other SQLite databases. Only users making use of SQLite are affected.
Discourse is an open source platform for community discussion. In affected versions an attacker can poison the cache for anonymous (i.e. not logged in) users, such that the users are shown the crawler view of the site instead of the HTML page. This can lead to a partial denial-of-service. This issue is patched in the latest stable, beta and tests-passed versions of Discourse. There are no known workarounds for this issue.
GeoWebCache is a tile caching server implemented in Java. The GeoWebCache disk quota mechanism can perform an unchecked JNDI lookup, which in turn can be used to perform class deserialization and result in arbitrary code execution. While in GeoWebCache the JNDI strings are provided via local configuration file, in GeoServer a user interface is provided to perform the same, that can be accessed remotely, and requires admin-level login to be used. These lookup are unrestricted in scope and can lead to code execution. The lookups are going to be restricted in GeoWebCache 1.21.0, 1.20.2, 1.19.3.
Discourse is an open source platform for community discussion. A category's group permissions settings can be viewed by anyone that has access to the category. As a result, a normal user is able to see whether a group has read/write permissions in the category even though the information should only be available to the users that can manage a category. This issue is patched in the latest stable, beta and tests-passed versions of Discourse. There are no workarounds for this problem.
An out-of-bounds read/write vulnerability was found in e2fsprogs 1.46.5. This issue leads to a segmentation fault and possibly arbitrary code execution via a specially crafted filesystem.
An authentication bypass vulnerability exists in the Web Application functionality of Moxa MXView Series 3.2.4. A specially-crafted HTTP request can lead to unauthorized access. An attacker can send an HTTP request to trigger this vulnerability.
A SQL injection vulnerability exists in the HelpdeskEmailActions.aspx functionality of Lansweeper lansweeper 9.1.20.2. A specially-crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerability.
An SQL injection vulnerability exists in the EchoAssets.aspx functionality of Lansweeper lansweeper 9.1.20.2. A specially-crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerability.
A denial of service vulnerability exists in the cgiserver.cgi Upgrade API functionality of Reolink RLC-410W v3.0.0.136_20121102. A specially-crafted HTTP request can lead to a reboot. An attacker can send an HTTP request to trigger this vulnerability.
An out-of-bounds write vulnerability exists in the parse_raster_data functionality of Accusoft ImageGear 19.10. A specially-crafted malformed file can lead to memory corruption. An attacker can provide a malicious file to trigger this vulnerability.
An out-of-bounds read vulnerability exists in the RS-274X aperture macro multiple outline primitives functionality of Gerbv 2.7.0 and dev (commit b5f1eacd), and Gerbv forked 2.7.1 and 2.8.0. A specially-crafted Gerber file can lead to information disclosure. An attacker can provide a malicious file to trigger this vulnerability.
An SQL injection vulnerability exists in the AssetActions.aspx functionality of Lansweeper lansweeper 9.1.20.2. A specially-crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerability.
An information disclosure vulnerability exists in the Web Application functionality of Moxa MXView Series 3.2.4. Network sniffing can lead to a disclosure of sensitive information. An attacker can sniff network traffic to exploit this vulnerability.
An out-of-bounds write vulnerability exists in the OTA update task functionality of Sealevel Systems, Inc. SeaConnect 370W v1.3.34. A specially-crafted MQTT payload can lead to denial of service. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.
Two heap-based buffer overflow vulnerabilities exist in the TIFF parser functionality of Accusoft ImageGear 19.10. A specially-crafted file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger these vulnerabilities. Placeholder
A stored cross-site scripting vulnerability exists in the WebUserActions.aspx functionality of Lansweeper lansweeper 9.1.20.2. A specially-crafted HTTP request can lead to arbitrary Javascript code injection. An attacker can send an HTTP request to trigger this vulnerability.
An authentication bypass vulnerability exists in the device password generation functionality of Swift Sensors Gateway SG3-1010. A specially-crafted network request can lead to remote code execution. An attacker can send a sequence of requests to trigger this vulnerability.
An out-of-bounds read vulnerability exists in the RS-274X aperture macro outline primitive functionality of Gerbv 2.7.0 and dev (commit b5f1eacd) and the forked version of Gerbv (commit d7f42a9a). A specially-crafted Gerber file can lead to information disclosure. An attacker can provide a malicious file to trigger this vulnerability.
A heap-based buffer overflow vulnerability exists in the sphere.c start_read() functionality of Sound Exchange libsox 14.4.2 and master commit 42b3557e. A specially-crafted file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.
Lack of Neutralization of Formula Elements in the CSV API of MantisBT before 2.25.3 allows an unprivileged attacker to execute code or gain access to information when a user opens the csv_export.php generated CSV file in Excel.
An issue was discovered in Amazon AWS VPN Client 2.0.0. A TOCTOU race condition exists during the validation of VPN configuration files. This allows parameters outside of the AWS VPN Client allow list to be injected into the configuration file prior to the AWS VPN Client service (running as SYSTEM) processing the file. Dangerous arguments can be injected by a low-level user such as log, which allows an arbitrary destination to be specified for writing log files. This leads to an arbitrary file write as SYSTEM with partial control over the files content. This can be abused to cause an elevation of privilege or denial of service.
A blind SQL injection vulnerability in the ePolicy Orchestrator (ePO) extension of MA prior to 5.7.6 can be exploited by an authenticated administrator on ePO to perform arbitrary SQL queries in the back-end database, potentially leading to command execution on the server.
An XSS issue was discovered in COINS Construction Cloud 11.12. Due to insufficient neutralization of user input in the description of a task, it is possible to store malicious JavaScript code in the task description. This is later executed when it is reflected back to the user.
** UNSUPPORTED WHEN ASSIGNED ** A heap-based buffer overflow exists in XML Decompression DecodeTreeBlock in AT&T Labs Xmill 0.7. A crafted input file can lead to remote code execution. This is not the same as any of: CVE-2021-21810, CVE-2021-21811, CVE-2021-21812, CVE-2021-21815, CVE-2021-21825, CVE-2021-21826, CVE-2021-21828, CVE-2021-21829, or CVE-2021-21830. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
MariaDB Server v10.9 and below was discovered to contain a segmentation fault via the component sql/sql_window.cc.
MariaDB Server v10.6.3 and below was discovered to contain an use-after-free in the component my_wildcmp_8bit_impl at /strings/ctype-simple.c.
MariaDB Server v10.9 and below was discovered to contain a segmentation fault via the component sql/item_cmpfunc.cc.
MariaDB Server v10.6.3 and below was discovered to contain an use-after-free in the component VDec::VDec at /sql/sql_type.cc.
Sourcecodester Messaging Web Application 1.0 is vulnerable to stored XSS. If a sender inserts valid scripts into the chat, the script will be executed on the receiver chat.
MariaDB Server v10.9 and below was discovered to contain a segmentation fault via the component sql/item_subselect.cc.