blog.0patch.com Open in urlscan Pro
2a00:1450:4001:81c::2013 Public Scan

Back to summary

URL:
https://blog.0patch.com/
Submission: On November 19 via manual (November 19th 2024, 10:31:30 am UTC) from GB — Scanned from GB

Form analysis
0 forms found in the DOM

Text Content

0PATCH BLOG

Security Patching Simplified To The Extreme

MONDAY, NOVEMBER 18, 2024

Posted by Mitja Kolsek on November 18, 2024

FIXING A BUNCH OF SCRIPTING ENGINE VULNERABILITIES BY DISABLING JUST-IN-TIME
COMPILER (CVE-2024-38178)

August 2024 Windows Updates brought a patch for CVE-2024-38178, a remotely
exploitable memory corruption issue in "legacy" Scripting Engine (JScript9.dll).
This engine, while part of long-expired Internet Explorer, is still present on
all Windows computers and can be invoked via various mechanisms, for instance
from an Office document.

Subsequently, security researchers Hosu Choi and Minyeop Choi of S2W Talon
published a detailed article, which included a short proof-of-concept script,
allowing us to reproduce the issue and issue our own patches for it.

THE VULNERABILITY

This is yet another vulnerability in JScript9.dll's Just-in-Time (JIT) compiler.
We've patched these kinds of issues in JScript9 JIT before (CVE-2021-34480,
CVE-2022-41128), and this issue is actually just a bypass for the latter's
patch.

In a similar way as with CVE-2022-41128, exploitation is done by malicious
JavaScript code rendered by JScript9.dll, which first forces Scripting Engine to
switch to JIT by executing a very long loop, thereby triggering JIT
optimization. The JIT'ed malicious function is written so that JIT compiler
generates flawed code, which is then used for corrupting memory and finally
executing attacker's code on user's computer.

We encourage you to read the SW2 Talon article for details.

MICROSOFT'S PATCH

Microsoft patched this issue with a substantial amount of additional code, and
an extension of some data structures.

OUR MICROPATCH

We usually create our patches to be logically identical, or at least similar to
Microsoft's. However, in this case we decided to take a different approach:
namely, while JIT-compiled code can be significantly faster than interpreted
JavaScript bytecode, this effect is strongest on special cases that are
typically not encountered in real-world use.

On the other hand, about 50% of all vulnerabilities in browsers are related to
JIT, which led Microsoft to introduce a "Super Duper Secure Mode" to their Edge
browser already back in 2021. This mode disables JIT, and as claimed in their
article, "... we find that users with JIT disabled rarely notice a difference in
their daily browsing."

So we decided to fix some past JIT-related vulnerabilities that we had no test
cases for, and all future JIT-related vulnerabilities in Jscript9.dll - by
simply disabling JIT. In contrast to Edge, Internet Explorer never had a switch
to disable JIT, so we couldn't piggyback on that and had to find our own way.
Our approach was to patch function NewFunctionCodeGen, which is called whenever
some JavaScript code should be JIT compiled, such that it always returns an
error - so the execution continues with JavaScript bytecode instead.

Our patch has a single CPU instruction, setting the return value of function
NewFunctionCodeGen to 0. The calling function, checking for this error, does the
rest of the work.

;XX-2521
MODULE_PATH
"..\AffectedModules\jscript9.dll_11.00.22000.1641_Win11-21H2_64-bit_u2023-10\jscript9.dll"
PATCH_ID 2075
PATCH_FORMAT_VER 2
VULN_ID 7838
PLATFORM win64
patchlet_start
PATCHLET_ID 1
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x104183
N_ORIGINALBYTES 5
JUMPOVERBYTES 5
code_start
mov rax, 0
code_end
patchlet_end

MICROPATCH AVAILABILITY

Micropatches were written for the following security-adopted versions of Windows
with all available Windows Updates installed:

1. Windows 11 v21H2 - fully updated
2. Windows 10 v21H2 - fully updated
3. Windows 10 v21H1 - fully updated
4. Windows 10 v20H2 - fully updated
5. Windows 10 v2004 - fully updated
6. Windows 10 v1909 - fully updated
7. Windows 10 v1809 - fully updated
8. Windows 10 v1803 - fully updated
9. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
10. Windows Server 2012 R2 - fully updated with no ESU
11. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or
ESU 4

Interestingly, JScript9.dll on Windows Server 2012 (non-R2) does not seem to
support JIT, so we didn't have to write a patch for it there.
Micropatches have already been distributed to, and applied on, all affected
online computers with 0patch Agent in PRO or Enterprise accounts (unless
Enterprise group settings prevented that).

Vulnerabilities like these get discovered on a regular basis, and attackers know
about them all. If you're using Windows that aren't receiving official security
updates anymore, 0patch will make sure these vulnerabilities won't be exploited
on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, start a free
trial, then install and register 0patch Agent. Everything else will happen
automatically. No computer reboot will be needed.

We would like to thank Hosu Choi and Minyeop Choi of S2W Talon for sharing their
analysis and proof-of-concept, which made it possible for us to create a
micropatch for this issue.

To learn more about 0patch, please visit our Help Center.

No comments:
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest

TUESDAY, NOVEMBER 12, 2024

Posted by Mitja Kolsek on November 12, 2024

MICROPATCHES RELEASED FOR REMOTE REGISTRY SERVICE ELEVATION OF PRIVILEGE
VULNERABILITY (CVE-2024-43532)

October 2024 Windows Updates brought a patch for CVE-2024-43532, a vulnerability
in Windows Remote Registry Service that could allow an attacker with access to
network communication between administrator's computer and computer under remote
administration to hijack the network connection and obtain administrator's
credentials. These could then be relayed to another server, for instance an
Active Directory Certificate Server, and used for creating a new certificate for
subsequent authentication.

Note that the official title of this issue ("Remote Registry Service Elevation
of Privilege Vulnerability") is incorrect, as the vulnerability is not in the
Remote Registry Service but rather in the remote registry client code, i.e., in
the component that remotely connects to the Remote Registry Service on another
computer. We're reluctantly keeping this title to avoid the risk of anyone
thinking these are two separate issues.

Security researcher Stiv Kupchik of Akamai found this vulnerability and reported
it to Microsoft. Subsequently, Stiv published a detailed article and provided a
proof-of-concept tool.

THE VULNERABILITY

The root cause of this vulnerability is the use of an insecure authentication
level in a RpcBindingSetAuthInfo call (advapi32.dll) from function
BaseBindToMachine, which provides user-supplied parameters that control the
behavior of an RPC binding to the remote machine.

The default behavior of the BaseBindToMachine call is to first try to bind to
the RPC endpoint using named pipes and RPC_C_AUTHN_LEVEL_PKT_PRIVACY, but when
that doesn't work, fall back to the vulnerable tcp_ip protocol with
RPC_C_AUTHN_LEVEL_CONNECT - which provides no security. Because of the
vulnerable RPC_C_AUTHN_LEVEL_CONNECT parameter, the tcp_ip biding can then be
relayed to a different endpoint of attacker's choosing, while authenticating
with victim's credentials.

Stiv Kupchik found one occurrence of the vulnerable RegConnectRegistryExW call
in the registry editor application, but various other applications are likely to
use remote registry connections in the same way.

MICROSOFT'S PATCH

Microsoft patched this issue by changing the default behavior of remote registry
connections initiated through function BaseBindToMachine, but it also introduced
new registry values that control the protocol fallback policy and security
policy.

OUR MICROPATCH

Our patch is logically equivalent to enforcing the "patched" behavior of
function BaseBindToMachine (i.e., when TransportFallbackPolicy is absent or set
to 1 - DEFAULT), disabling the fallback functionality and only allowing remote
registry connections over named pipes with RPC_C_AUTHN_LEVEL_PKT_PRIVACY.

Our patch has a single CPU instruction, whereby the pointer to the fallback
protocol name is set to 0. Microsoft's original code in advapi32.dll then does
the rest.

;XX-2562
MODULE_PATH
"..\AffectedModules\advapi32.dll_10.0.19041.1052_Win10-2004_64-bit_u2021-12\advapi32.dll"
PATCH_ID 2029
PATCH_FORMAT_VER 2
VULN_ID 7839
PLATFORM win64
patchlet_start
PATCHLET_ID 1
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x42d9c
N_ORIGINALBYTES 5
JUMPOVERBYTES 0
code_start

mov r15, 0x0 ;move 0 to r15 to replace the fallback protocol name
pointer.

code_end
patchlet_end

MICROPATCH AVAILABILITY

Micropatches were written for the following security-adopted versions of Windows
with all available Windows Updates installed:

1. Windows 11 v21H2 - fully updated
2. Windows 10 v21H2 - fully updated
3. Windows 10 v21H1 - fully updated
4. Windows 10 v20H2 - fully updated
5. Windows 10 v2004 - fully updated
6. Windows 10 v1909 - fully updated
7. Windows 10 v1809 - fully updated
8. Windows 10 v1803 - fully updated
9. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
10. Windows Server 2012 (standard and R2) - fully udpated with no ESU
11. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or
ESU 4

Micropatches have already been distributed to, and applied on, all affected
online computers with 0patch Agent in PRO or Enterprise accounts (unless
Enterprise group settings prevented that).

We would like to thank Stiv Kupchik of Akamai for sharing their analysis and
proof-of-concept, which made it possible for us to create a micropatch for this
issue.

To learn more about 0patch, please visit our Help Center.

No comments:
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest

TUESDAY, OCTOBER 29, 2024

Posted by Mitja Kolsek on October 29, 2024

WE PATCHED CVE-2024-38030, FOUND ANOTHER WINDOWS THEMES SPOOFING VULNERABILITY
(0DAY)

TL;DR: While patching CVE-2024-38030, we found another similar issue, reported
it to Microsoft and created free micropatches for 0patch users on both legacy
and still-supported Windows versions so they don't have to wait for an official
patch.

When last year Akamai security researcher Tomer Peled decided to look into
Windows themes files, they found that when a theme file specified a network file
path for some of the theme properties (specifically BrandImage and Wallpaper),
Windows would automatically send authenticated network requests to remote hosts,
including user's NTLM credentials when such theme file would be viewed in
Windows Explorer. This meant that merely seeing a malicious theme file listed in
a folder or placed on the desktop would be enough for leaking user's credentials
without any additional user action.

Microsoft patched this issue (CVE-2024-21320) three months after receiving the
report, and when vulnerability details were shared, we created patches for
Windows systems that were no longer receiving Windows updates.

Tomer then looked at Microsoft's patch and noticed that it used
function PathIsUNC to check if a given path in a theme file is a network path,
and if so, disregarded such path. This should have prevented NTLM credentials
leaks, if it weren't for James Forshaw, who described multiple ways of bypassing
function PathIsUNC back in 2016. Tomer noticed that tricks described by James
could be used to bypass Microsoft's patch for CVE-2024-21320, and reported that
to Microsoft so they could try again.

Microsoft did fix their patch and assigned CVE-2024-38030 to the new issue.

When we learned about this second flaw, we had to fix our patches for
CVE-2024-21320 as well. (We admit, we trusted Microsoft's choice on using
PathIsUNC, but will be more careful going forward.) While analyzing the issue,
our security researchers decided to look around a bit and found an additional
instance of the very same problem that was still present on all fully updated
Windows versions, up to currently the latest Windows 11 24H2.

So instead of just fixing CVE-2024-38030, we created a more general patch for
Windows themes files that would cover all execution paths leading to Windows
sending a network request to a remote host specified in a theme file upon merely
viewing the file.

We were surprised Microsoft did not find this additional instance when fixing
Tomer's initially reported issue. Namely, in their blog post about "Additional
Fixes" Microsoft described their process of finding "variations" of reported
vulnerabilities:

"The MSRC Engineering team reviews the affected component of each externally
reported vulnerability. One part of the review is the “Hacking for Variations”
(HfV) stage, which helps mitigate the threat of variants being discovered after
the update is released. The HfV process is jointly undertaken by
MSRC-Engineering and the product team. It involves reviewing the source code and
the bug database as well as fuzzing the component and hurling it through our
gauntlet of tools; many of which are new or have been updated since the
component was first written."

Admittedly, said blog post was issued in 2011, and the only other Google hits on
“Hacking for Variations” are also from 2011 or earlier. In any case, looking for
bug variations seems like something every software vendor should be doing when
learning about a security issue in their product.

Be that as it may, we reported our 0day to Microsoft and will withhold details
from public until they have re-fixed their patch. Meanwhile, 0patch users are
already protected against this 0day with our micropatch.

MICROPATCH AVAILABILITY

Since this is a "0day" vulnerability with no official vendor fix available, we
are providing our micropatches for free until such fix becomes available.

Micropatches were written both for our security-adopted legacy versions of
Windows Workstation, and all still-supported Windows versions with all available
Windows Updates installed:

Legacy Windows versions:

Windows versions still receiving Windows Updates:

1. Windows 10 v22H2 - fully updated
2. Windows 11 v22H2 - fully updated
3. Windows 11 v23H2 - fully updated
4. Windows 11 v24H2 - fully updated

Note that patches were only created for Windows Workstation but not for Windows
Server. This is because for Windows Themes to work on a server, the Desktop
Experience feature needs to be installed (it's not by default). In addition, for
credentials leak to occur on a server it's not enough just to view a theme file
in Windows Explorer or on desktop; rather, the theme file needs to be
double-clicked and the theme thus applied. Actually applying a Windows theme
from an untrusted source is, from the security perspective, not very different
from launching an untrusted executable. Getting a user to view a theme file in
Windows Explorer, on the other hand, may be a simple matter of forcing a
download of the theme file while the user is on attacker's web page, then
waiting for the user to open the Downloads folder (depending on the view type of
the Downloads folder).

Micropatches have already been distributed to, and applied on, all affected
online computers with 0patch Agent in PRO or Enterprise accounts (unless
Enterprise group settings prevented that).

We would like to thank Tomer Peled of Akamai for sharing details of
CVE-2024-38030. This prompted us to take a deeper look at theme files, find this
additional issue, and allowed us to create a micropatch to fix it for 0patch
users.

Did you know 0patch will security-adopt Windows 10 when it goes out of support
in October 2025, allowing you to keep using it for at least 5 more years? Read
more about it here.

To learn more about 0patch, please visit our Help Center.

No comments:
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest

WEDNESDAY, OCTOBER 2, 2024

Posted by Mitja Kolsek on October 02, 2024

MICROPATCHES FOR WINDOWS INSTALLER ELEVATION OF PRIVILEGE VULNERABILITY
(CVE-2024-38014)

September 2024 Windows Updates brought a patch for CVE-2024-38014, a privilege
escalation vulnerability in Windows Installer that could allow a local
low-privileged attacker to execute arbitrary code as Local System user.

Security researcher Michael Baer with SEC Consult Vulnerability Lab found this
vulnerability and reported it to Microsoft. Subsequently they also published an
article detailing this vulnerability, which allowed us to create a micropatch
for it.

THE VULNERABILITY

This vulnerability is an addition to a series of Windows Installer security
flaws that were found over the last few years (and patched by 0patch: [1, 2, 3,
4]). Most of these exploited the "repair" operation in one way or another, and
so does this one. Its exploitability depends on a product being installed on the
computer, whereby product's installer has to fulfill a number of conditions
described in SEC Consult's article.

This vulnerability finally pushed Microsoft to create a patch that fixed not
just this particular issue, but a whole class of issues that might result from
non-admin users invoking the repair operation. After September 2024 update is
applied, the repair operation on a product installed "for all users" requires
administrative privileges. In case the user is a Windows administrator, the UAC
(User Account Control) dialog is shown according to the computer's UAC policy,
otherwise the user is prompted for administrative credentials. Note that a
non-admin can still perform the repair operation on a product installed "for
this user only" without administrative privileges. This makes sense, as such
operation does not include privileged actions that could be exploited.

Microsoft's article describes the effects of the change: "When [Windows
Installer] repairs an application, the User Account Control (UAC) does not
prompt for your credentials. After you install this update, the UAC will prompt
for them. Because of this, you must update your automation scripts. Application
owners must add the Shield icon. It indicates that the process requires full
administrator access. To turn off the UAC prompt, set the
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer\DisableLUAInRepair
registry value to 1. The changes in this update might affect automatic Windows
Installer repairs."

Note that this fix also addresses a vulnerability in Windows Installer reported
to Microsoft by Adrian Denkiewicz with Doyensec in December 2023, which
Microsoft reportedly could not reproduce. This vulnerability also exploited the
repair operation and the fact that some actions can be executed with elevated
privileges, which a non-admin user could "hijack" to launch code as Local
System.

OUR MICROPATCH

Our micropatch is simpler but logically equivalent to Microsoft's: it requires
administrative privileges for all repair operations on products installed "for
all users".

The effect of this change is identical to that of Microsoft's patch (see above)
but in contrast to reverting this change with a registry value, our patch can be
disabled either locally via 0patch Console or remotely via 0patch Central if
needed.

Here's the source code of our micropatch (note that in the title, the size of
our micropatch is said to be "4 instructions", which is true for some Windows
versions; this particular one for 32-bit Windows 10 v2004 only needed two
instructions.)

;XX-2369
MODULE_PATH
"..\AffectedModules\msi.dll_5.0.19041.1415_Win10-2004_32-bit_u2021-12\msi.dll"
PATCH_ID 1960
PATCH_FORMAT_VER 2
VULN_ID 7835
PLATFORM win32
patchlet_start
PATCHLET_ID 1
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x1ddfb7
N_ORIGINALBYTES 5
JUMPOVERBYTES 0
PIT msi.dll!0x1de0a1
code_start
cmp eax, 0x2 ;check if the current operation is repair
je PIT_0x1de0a1 ;if yes, jump to the block that enables UAC
code_end
patchlet_end

MICROPATCH AVAILABILITY

Micropatches were written for the following security-adopted versions of Windows
with all available Windows Updates installed:

1. Windows 11 v21H2 - fully updated
2. Windows 10 v21H2 - fully updated
3. Windows 10 v21H1 - fully updated
4. Windows 10 v20H2 - fully updated
5. Windows 10 v2004 - fully updated
6. Windows 10 v1909 - fully updated
7. Windows 10 v1809 - fully updated
8. Windows 10 v1803 - fully updated
9. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
10. Windows Server 2012 (standard and R2) - fully udpated with no ESU
11. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or
ESU 4

Micropatches have already been distributed to, and applied on, all affected
online computers with 0patch Agent in PRO or Enterprise accounts (unless
Enterprise group settings prevented that).

We would like to thank Michael Baer with SEC Consult Vulnerability Lab for
sharing their analysis, which made it possible for us to create a micropatch for
this issue. We'd also like to thank Adrian Denkiewicz with Doyensec for sharing
their analysis, which allowed us to confirm that our patch also fixes the
vulnerability they had found.

To learn more about 0patch, please visit our Help Center.

No comments:
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest

THURSDAY, SEPTEMBER 19, 2024

Posted by Mitja Kolsek on September 19, 2024

MICROPATCHES FOR "MADLICENSE" WINDOWS REMOTE DESKTOP LICENSING SERVICE REMOTE
CODE EXECUTION (CVE-2024-38077)

July 2024 Windows Updates brought a patch for CVE-2024-38077, a memory
corruption vulnerability in Remote Desktop Licensing Service that could
potentially allow an attacker in a Windows network to remotely execute arbitrary
code on a computer running this service.

Security researchers Lewis Lee, Chunyang Han and Zhiniang Peng found this
vulnerability and reported it to Microsoft. On August 9 they also published an
article (subsequently deleted) with some details about this vulnerability and an
incomplete pseudo-code POC. We had confirmed that said POC was not working as-is
but combining various sources, we were able to create our own working POC.

THE VULNERABILITY

The vulnerability resides in the Remote Desktop Licensing Service, a service
only running on Windows Servers and not installed by default: one has to add the
"Remote Desktop Licensing" role to have it installed.

The flaw is in a fixed-size buffer being used for user-supplied data, which can
result in a buffer overflow. Careful selection of user-supplied data could
potentially lead to execution of arbitrary code on the server hosting the Remote
Desktop Licensing Service, running as Local System.

Microsoft's patch checks for the buffer overflow and exits the affected function
with error before it occurs.

OUR MICROPATCH

Our micropatch is simpler but logically equivalent to Microsoft's.

Here's the source code of our micropatch.

;XX-2326
MODULE_PATH
"..\AffectedModules\lserver.dll_6.3.9600.18226_Server-2012_64-bit_u2023-1\lserver.dll"
PATCH_ID 1000002
PATCH_FORMAT_VER 2
VULN_ID 7834
PLATFORM win64
patchlet_start
PATCHLET_ID 1
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x7bb8f
N_ORIGINALBYTES 5
JUMPOVERBYTES 0
PIT lserver.dll!0x7bbf5,kernel32.dll!GetModuleHandleA
code_start
push rax
push rcx
push rdx
push r8
push r9 ;push all the volatile registers to save the initial
state
push r10
push r11
push r12
mov r11, 0x0 ;move a 0x0 flag to r11
mov r12, rax ;save the current counter value to r12
call STR1 ;load the current module name to stack so we can call
GetModuleHandle
db 'lserver.dll',0
STR1:
pop rcx ;pop the string pointer to the first arg
sub rsp, 0x20 ;create the shadowspace
call PIT_GetModuleHandleA ;call GeModuleHandle to get the current module
base address
add rsp, 0x20 ;delete the shadowspace
cmp rax, 0x0 ;check if the call succeeded
je EXIT ;if GetModuleHandle call failed jump out of the patch
without doing anything
cmp r12d, dword[rax+0xa873c] ;compare the current counter value to the
size of the buffer
;that is saved in a global variable on base address +
0xa873c
jb EXIT ;if the counter is less then the buffer size skip the
flag setting instruction
mov r11, 0x1 ;otherwise set the flag and continue
EXIT:
cmp r11, 0x1 ;check the flag so we can use a conditional jump after
restoring registers
pop r12
pop r11
pop r10
pop r9 ;restore the original register states
pop r8
pop rdx
pop rcx
pop rax
je PIT_0x7bbf5 ;if the flag was set jump to the error block as an
overflow is
;about to occur- else continue normally
code_end
patchlet_end

The video below shows our micropatch in action: first, the target server (on the
left) has 0patch disabled, and running our POC against it from another machine
in the domain causes the Remote Desktop Licensing Service to crash. The same
test with 0patch enabled - and therefore our micropatch applied - does not lead
to the crash.

MICROPATCH AVAILABILITY

Micropatches were written for the following security-adopted versions of Windows
with all available Windows Updates installed:

1. Windows Server 2008 R2 - no ESU, ESU 1-4
2. Windows Server 2012 - no ESU
3. Windows Server 2012 R2 - no ESU

Micropatches have already been distributed to, and applied on, all affected
online computers with 0patch Agents in PRO or Enterprise accounts (unless
Enterprise group settings prevent that).

We would like to thank Lewis Lee, Chunyang Han and Zhiniang Peng for sharing
their analysis, which made it possible for us to create a micropatch for this
issue.

To learn more about 0patch, please visit our Help Center.

No comments:
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest

MONDAY, JULY 29, 2024

Posted by Mitja Kolsek on July 29, 2024

PATCHES FOR TWO WINDOWS BLUETOOTH VULNERABILITIES (CVE-2023-23388,
CVE-2023-24871)

March 2023 Windows updated brought patches for two Windows Bluetooth
vulnerabilities: CVE-2023-23388, a Windows Bluetooth Driver Elevation of
Privilege Vulnerability, and CVE-2023-24871, a Windows Bluetooth Service Remote
Code Execution Vulnerability. Both were reported to Microsoft by security
researcher Miloš (a.k.a. goodbyeselene).

Miloš subsequently wrote a series of detailed articles and published POCs for
these issues (POC 1, POC 2). These allowed us to reproduce both issues and
create micropatches for affected legacy Windows systems, which are no longer
receiving security updates from Microsoft.

WINDOWS BLUETOOTH SERVICE REMOTE CODE EXECUTION VULNERABILITY (CVE-2023-24871)

This is a vulnerability inside of Microsoft's Low Energy Bluetooth
implementation. The Windows.Internal.Bluetooth.dll library implements parsing
and processing of Bluetooth data received locally or remotely. Bluetooth Low
Energy implements a functionality called "Advertising" which, without going into
too much detail, is a way of sending data packets to all participants.
Advertising data can be sent by two events: LE Advertising Report and LE
Extended Advertising Report. Bluetooth 5.0 introduced the new LE Extended
Advertising Report, which now allows for a packet to contain more data (1650
bytes instead of 32, but split into multiple PDUs of 254 bytes). This can be
exploited by an attacker to overflow a function that counts the number of
advertising sections inside a packet, as the counter is an 8-bit integer. When
the counter reaches 0xff, the next iteration overflows it to 0x00 (and continues
to count as 0x01, 0x02, 0x03...) then the final value is used to allocate a
memory buffer. When such buffer with insufficient size is used, an access
violation occurs that could potentially be used for arbitrary code execution.

Microsoft patched this by limiting the advertising section counter to 0xff. If
0xff is reached, the parsing function now errors out and stops the exploit from
continuing.

Our patch is logically identical to Microsoft's, and successfully stops the
vulnerability from overflowing in function BthLELib_ADValidateEx.

WINDOWS BLUETOOTH DRIVER ELEVATION OF PRIVILEGE VULNERABILITY (CVE-2023-23388)

This issue also resides in Windows.Internal.Bluetooth.dll library. The root
cause of this vulnerability is a signed comparison of a user-supplied value
representing an operation number. If the passed value is a negative number, the
original jge instruction treats this value as "not greater than or equal to 7"
and continues with execution, leading to an access violation.

Microsoft patched this issue by replacing the signed comparison using jge with
an unsigned comparison using jae. This effectively catches a negative number
when comparing it to 7 (0 to 6 are valid operation numbers), and errors out.

We patched this similarly by injecting a jae instruction right after the
original jge operation, leading to a logically identical behavior.

MICROPATCH AVAILABILITY

Micropatches for CVE-2023-23388 were written for all affected security-adopted
versions of Windows with all available Windows Updates installed:

1. Windows 10 v21H1 - fully updated
2. Windows 10 v2004 - fully updated
3. Windows 10 v1909 - fully updated
4. Windows 10 v1809 - fully updated
5. Windows 10 v1803 - fully updated

Micropatches for CVE-2023-24871 were written for all affected security-adopted
versions of Windows with all available Windows Updates installed:
1. Windows 10 v21H1 - fully updated
2. Windows 10 v2004 - fully updated

These micropatches have already been distributed to, and applied on, all online
0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings
prevent that).

We would like to thank Miloš (a.k.a. goodbyeselene) for sharing their analysis,
POCs, and their prompt assistance with porting POCs to 32-bit systems, which all
made it possible for us to create micropatches for these issues.

To learn more about 0patch, please visit our Help Center.

No comments:
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest

TUESDAY, JULY 23, 2024

Posted by Mitja Kolsek on July 23, 2024

MICROPATCHES RELEASED FOR WINDOWS MSHTML PLATFORM SPOOFING (CVE-2024-38112)

July 2024 Windows Updates brought a patch for CVE-2024-38112, a vulnerability in
Windows that allows an attacker to create a Windows Internet Shortcut file
(extension .url) that will look exactly like a PDF document, while clicking on
it opens attacker's web page in Internet Explorer. The problem there is that
Internet Explorer, which is still present on Windows computers and integrated
into many applications, is easier to exploit as it has no real sandbox.

This issue was reported to Microsoft by Haifei Li with Check Point Research,
whose researchers noticed it being used by threat actors. Haifei later wrote an
article detailing the vulnerability, demonstrating how a malicious executable
could be executed using this trick. In addition, exploitation of the same issue
was also detected in the wild by Trend Micro; they, too, reported it to
Microsoft.

Microsoft patched this by deleting a small piece of code from ieframe.dll which
allowed for Internet Explorer to be launched via a URL file.

Unsupported Windows versions that we have security-adopted were also affected by
this issue, so we created a micropatch for them. Our micropatch is logically
equivalent to Microsoft's, containing a single JMP instruction to jump over the
code that Microsoft removed on supported Windows versions.

MICROPATCH AVAILABILITY

Micropatches were written for the following security-adopted versions of Windows
with all available Windows Updates installed:

1. Windows 11 v21H2 - fully updated
2. Windows 10 v21H2 - fully updated
3. Windows 10 v21H1 - fully updated
4. Windows 10 v20H2 - fully updated
5. Windows 10 v2004 - fully updated
6. Windows 10 v1909 - fully updated
7. Windows 10 v1809 - fully updated
8. Windows 10 v1803 - fully updated
9. Windows 7 - fully updated with no ESU, ESU 1/2/3
10. Windows Server 2008 R2 - fully updated with no ESU, ESU 1/2/3/4

Micropatches have already been distributed to, and applied on, all online 0patch
Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent
that).

If you're new to 0patch, create a free account in 0patch Central with a free
monthly trial, then install and register 0patch Agent (link in 0patch Central).
Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Haifei Li with Check Point Research for sharing their
analysis and POC, which made it possible for us to create a micropatch for this
issue.

To learn more about 0patch, please visit our Help Center.

No comments:
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest

Older Posts Home

ABOUT 0PATCH

0patch (pronounced 'zero patch') is a platform for instantly distributing,
applying and removing microscopic binary patches to/from running processes
without having to restart these processes (much less reboot the entire
computer). Brought to you by ACROS Security.

BLOG ARCHIVE

* ▼ 2024 (20)
* ▼ November (2)
* Fixing a Bunch of Scripting Engine Vulnerabilities...
* Micropatches Released for Remote Registry Service ...
* ► October (2)
* ► September (1)
* ► July (2)
* ► June (2)
* ► May (1)
* ► April (4)
* ► March (1)
* ► February (4)
* ► January (1)

* ► 2023 (26)
* ► November (3)
* ► October (3)
* ► September (2)
* ► August (1)
* ► July (1)
* ► June (5)
* ► May (1)
* ► April (1)
* ► March (5)
* ► February (2)
* ► January (2)

* ► 2022 (26)
* ► December (3)
* ► October (6)
* ► September (3)
* ► August (2)
* ► July (2)
* ► June (3)
* ► May (2)
* ► March (4)
* ► January (1)

* ► 2021 (23)
* ► December (2)
* ► November (3)
* ► October (2)
* ► September (1)
* ► August (3)
* ► July (2)
* ► June (1)
* ► May (3)
* ► March (2)
* ► February (2)
* ► January (2)

* ► 2020 (19)
* ► December (2)
* ► November (2)
* ► September (1)
* ► August (2)
* ► July (3)
* ► June (2)
* ► May (2)
* ► March (1)
* ► February (2)
* ► January (2)

* ► 2019 (7)
* ► September (1)
* ► June (1)
* ► April (2)
* ► February (2)
* ► January (1)

* ► 2018 (11)
* ► October (2)
* ► September (2)
* ► August (1)
* ► May (2)
* ► March (1)
* ► February (1)
* ► January (2)

* ► 2017 (19)
* ► December (1)
* ► November (4)
* ► October (2)
* ► September (2)
* ► August (1)
* ► July (1)
* ► June (1)
* ► May (1)
* ► March (2)
* ► February (3)
* ► January (1)

* ► 2016 (7)
* ► September (1)
* ► July (1)
* ► June (3)
* ► January (2)

LINKEDIN AND GOOGLE TAGS

This site uses cookies from Google to deliver its services and to analyse
traffic. Your IP address and user agent are shared with Google, together with
performance and security metrics, to ensure quality of service, generate usage
statistics and to detect and address abuse.Learn moreGot it

blog.0patch.com Open in urlscan Pro 2a00:1450:4001:81c::2013 Public Scan

Form analysis 0 forms found in the DOM

Text Content

blog.0patch.com Open in urlscan Pro
2a00:1450:4001:81c::2013 Public Scan

Form analysis
0 forms found in the DOM