# Wrong owner SID on privileged object

Kernel or privileged service creates objects under impersonation with wrong owner SID or permissive DACL

_Area: Memory corruption and native code. Seen in 3 disclosed reports; latest 2026-01-26. Updated 2026-10-23._

## How it works
A privileged component creates or assigns an object (device directory, token, file capability, registration record) while running under a less-privileged identity, or derives the object's owner from the wrong token. The access check that should have gated creation is skipped or the owner SID falls back to a token the attacker controls, so a limited user ends up owning or controlling an object the system later treats as trusted. The broken assumption is that "the creator is the privileged principal" or "the owner SID reflects the intended security boundary."

## Where it shows up
- Lazy object creation inside impersonation blocks, especially with access checks disabled (e.g. `ZwCreateDirectoryObject`)
- Owner SID derived from a primary token while an identification-level token is impersonated
- Distro-patched internal helpers (`__vfs_*`) that bypass the checked wrapper (`vfs_*`)
- Copy paths for xattrs, file capabilities, or SUID bits that skip namespace conversion
- Registration/status APIs that validate the calling process signature but not the payload
- Objects created with explicit DACLs granting write/control to a broad group

## How to review
Identify every privileged object creation and ask: which token's SID becomes the owner, and is that the intended principal? Verify the access check is not disabled during creation, and that impersonation of identification-level tokens cannot influence owner assignment. For copy paths, confirm the checked wrapper is used and namespace scoping (`cap_convert_nscap`) runs. The invariant: an object's owner and DACL must be derived from the privileged principal, never from an attacker-influenced token, and creation must be access-checked.

## Variants seen
- Lazy kernel creation of a per-session DOS device directory under an identification token, owner SID taken from primary token [E1](https://bugbountylibrary.com/r/blog%3Aprojectzero-google-2026-26-windows-administrator-protection-html.md)
- OverlayFS copy of file capabilities via `__vfs_setxattr_noperm`, skipping namespace scoping [E2](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-ubuntu-overlayfs-vulnerability.md)
- Security-product registration trusting caller signature, not payload, allowing fake AV registration [E3](https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-defendnot-detecting-malicious-security-product-bypass-techniques.md)

## Why fixes fail
Blocking one primitive (SUID) left the sibling capability/xattr copy path open [E2](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-ubuntu-overlayfs-vulnerability.md). Signature validation on the process, not the payload, leaves injection into a signed binary viable [E3](https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-defendnot-detecting-malicious-security-product-bypass-techniques.md).

## Impact and severity
Silent admin escalation [E1](https://bugbountylibrary.com/r/blog%3Aprojectzero-google-2026-26-windows-administrator-protection-html.md), root on ~40% of Ubuntu cloud workloads [E2](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-ubuntu-overlayfs-vulnerability.md), and Defender disabled [E3](https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-defendnot-detecting-malicious-security-product-bypass-techniques.md). Severity is high because the object is trusted downstream; worse when the primitive is easy to trigger and the fix only covers one sibling path.

## Evidence
- E1: https://bugbountylibrary.com/r/blog%3Aprojectzero-google-2026-26-windows-administrator-protection-html.md
- E2: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-ubuntu-overlayfs-vulnerability.md
- E3: https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-defendnot-detecting-malicious-security-product-bypass-techniques.md