GunP4ng/README.md

## README.md

      
    Raw
  

              README.md
            
          
    CVE-2025-64699


Public reference for CVE-2025-64699 (Issue: incorrect DACL/ACL).


Product / Affected Versions


Vendor: SevenCs GmbH
Product: ORCA™ G2 (ECS) / SevenCs EC2007 ECDIS Kernel
Affected version(s): ORCA G2 v2.0.1.35 / EC2007 Kernel v5.22
Component(s): regService (Windows service), related requester component: regTest.exe (or ORCA module triggering the request path)


Summary

A privileged component (regService, running as SYSTEM) modifies the security of the Windows volume device object (e.g., \\.\C:) in an unsafe way.
Specifically, regService applies a Security Descriptor to \\.\C: using SetFileSecurityA(..., DACL_SECURITY_INFORMATION, ...) while the Security Descriptor has no explicitly configured DACL. As observed in verification, this results in a NULL DACL state on the device object (bDaclPresent=TRUE, pDacl=NULL), effectively removing access control.
After the ACL/DACL is altered, a non-administrative local user can open \\.\C: and perform unauthorized raw disk operations. This can lead to system disruption (DoS) and exposure of sensitive data, and may facilitate local privilege escalation depending on the environment and attacker capabilities.

Vulnerability Type / CWE


Type: Incorrect Permission Assignment / Improper Access Control
CWE: CWE-732 (Incorrect Permission Assignment for Critical Resource)
(Also related: CWE-284 (Improper Access Control))


Impact


DoS: Yes
(Unauthorized raw disk writes can corrupt boot records / critical on-disk structures.)
Information disclosure: Yes
(Raw disk reads can bypass file-level protections and expose sensitive data.)
Privilege escalation: Possible
(Depending on environment and attacker capability, raw disk access can enable offline credential material access and subsequent administrative compromise.)
Attack requirements: Local authenticated standard user after the ACL/DACL has been applied by the privileged component.


High-level Verification / Reproduction (no weaponized details)


The steps below are intended to confirm the incorrect permission state and should not include destructive actions.


Trigger the service code path that applies the ACL/DACL (this occurs via regService named pipe request handling; typically invoked by ORCA components such as regTest.exe).
Verify effective permissions on the volume device object, for example:

Using Sysinternals accesschk to observe broad permissions on \\.\C: (e.g., Everyone RW).


Confirm the DACL state via Windows security APIs:

Retrieve the security descriptor for \\.\C: and call GetSecurityDescriptorDacl.
Affected state is indicated by:

bDaclPresent = TRUE
pDacl = NULL
→ NULL DACL confirmed (access control effectively removed)


Confirm that opening a raw disk handle as a non-admin succeeds (high-level check only; no destructive reads/writes).

Verification Output (test.exe):
>test.exe
[+] NULL DACL (present=TRUE, pDacl=NULL) -> full access for everyone

test.exe is a non-destructive verifier that calls GetSecurityInfo/GetNamedSecurityInfo (or equivalent) on \\.\C: and prints the DACL presence/pointer state.

Verification Output (accesschk.exe):
>accesschk.exe -d \\.\C:

Accesschk v6.15 - Reports effective permissions for securable objects
Copyright (C) 2006-2022 Mark Russinovich
Sysinternals - www.sysinternals.com

\\.\C:
  RW Everyone
  RW BUILTIN\Administrators

Observed after triggering the regService request path as described above, on ORCA G2 v2.0.1.35 / EC2007 Kernel v5.22


Technical Notes / Root Cause (for triage)


Location (example from reverse engineering):

Function: regService + 0x43AE50
Behavior: constructs \\.\<systemdrive>: (e.g., \\.\C:) and calls:

InitializeSecurityDescriptor(...)
SetSecurityDescriptorSacl(...)
SetFileSecurityA(Destination, DACL_SECURITY_INFORMATION, pSecurityDescriptor)


No SetSecurityDescriptorDacl(...) call is present prior to applying DACL_SECURITY_INFORMATION.


Mitigation / Fix Guidance


Do not apply permissive ACLs to core device objects like \\.\C: unless absolutely necessary.
If modification is unavoidable:

Explicitly apply a least-privilege DACL (e.g., SYSTEM and Administrators only).
Ensure the final descriptor is not NULL DACL and does not grant broad access (Everyone/Users/Authenticated Users).


Validate the post-change security descriptor programmatically (e.g., GetSecurityDescriptorDacl) and add regression tests.
Consider redesign to avoid raw device object ACL modification for system identification workflows.


Credits


Discovered by: TaeYong LEE
Team: WHS3 SeaBugs
No results found