Defense in depth -- the Microsoft way (part 96): yet another SAFER (SRPv1) and AppLocker (SRPv2) loophole
好的,我现在需要帮用户总结这篇文章的内容,控制在100字以内,而且不需要特定的开头。首先,我得仔细阅读文章内容,抓住关键点。 文章主要讨论了Windows系统的安全机制,特别是SAFER和AppLocker。作者Stefan Kanthak提到,由于32位和64位应用的注册表处理不同,导致安全策略存在漏洞。例如,Windows Script Host的注册表项没有合并,使得即使在计算机层面禁用了WSH,普通用户仍能通过用户层面重新启用它。 接下来,作者展示了如何通过设置额外的注册表项来解决这个问题,并强调必须同时处理32位和64位的注册表分支。这说明微软的安全策略在实现上存在设计缺陷,容易被绕过。 总结时要突出关键点:Windows的安全机制、注册表处理问题、漏洞及其影响、解决方案以及揭示的设计缺陷。确保语言简洁明了,控制在100字以内。 </think> 文章揭示了Windows系统中SAFER和AppLocker的安全策略因32位与64位应用的注册表处理差异而存在的漏洞。由于某些注册表项未合并或被分割(如Windows Script Host),即使管理员禁用了相关功能,普通用户仍可通过用户层面重新启用或绕过限制。文章提供了具体的注册表设置示例,并强调需同时处理32位和64位分支以确保安全策略生效。 2026-3-12 22:0:51 Author: seclists.org(查看原文) 阅读量:1 收藏

fulldisclosure logo

Full Disclosure mailing list archives


From: Stefan Kanthak via Fulldisclosure <fulldisclosure () seclists org>
Date: Mon, 23 Feb 2026 17:36:44 +0100

Hi @ll,

about 2 months ago I posted
<https://seclists.org/fulldisclosure/2025/Dec/29>
"Defense in depth -- the Microsoft way (part 94):
 SAFER (SRPv1 and AppLocker alias SRPv2) bypass for dummies"

Here's the continuation...

About 23 years ago, 64-bit Windows introduced the WoW64 subsystem, which
performs a transpatent redirection of file system and registry accesses
for 32-bit applications.
To allow consistent appearance and behaviour of 64-bit and 32-bit variants
of applications like the "command processor" which reads its settings from
the registry key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor],
several branches or single keys of the split registry where joined: until
Vista via "registry reflection", since Windows 7 via "shared keys".

Some applications, for example the Windows Script Host, were but lobotomized:
the registry keys [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host]
and [HKEY_LOCAL_MACHINE\SOFTWARE\WoW6432Node\Microsoft\Windows Script Host]
are separate, NOT joined.

Demonstration
~~~~~~~~~~~~~

The article <https://technet.microsoft.com/en-us/library/ee198684.aspx>
"Disabling Windows Script Host" states:

| To disable WSH for all users of a particular computer, create this
| entry:
|
| [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings]
| "Enabled"=dword:00000000

It but needs a second, UNDOCUMENTED entry to enforce this setting:

| "IgnoreUserSettings"=dword:00000001

Without this entry, unprivileged users can enable WSH or exempt it from
SAFER, either Software Restriction Policies or AppLocker:

| [HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings]
| "Enabled"=dword:00000001
| "UseWINSAFER"=dword:00000000

With the first 2 entries for the computer in place, and NO entries set for
the user, start a command prompt, run %SystemRoot%\SysWoW64\CSCRIPT.EXE or
%SystemRoot%\SysWoW64\WSCRIPT.EXE without arguments and admire their help
messages on the console or in a dialog box: OOPS!

Due to the lobotomy the same entries MUST be set in the 32-bit branch of
the registry too! Since the key name \WoW6432Node\ is an implementation
detail you should NEVER use, run the proper command lines:

REG.EXE ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Hosts\Settings" /REG:32 /V Enabled /D 0
REG.EXE ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Hosts\Settings" /REG:32 /V IgnoreUserSettings /D 1

stay tuned, and far away from split brains
Stefan Kanthak
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/


Current thread:

  • Defense in depth -- the Microsoft way (part 96): yet another SAFER (SRPv1) and AppLocker (SRPv2) loophole Stefan Kanthak via Fulldisclosure (Mar 12)

文章来源: https://seclists.org/fulldisclosure/2026/Mar/5
如有侵权请联系:admin#unsafe.sh