Posts Tagged ‘PrivilegeEscalation’
[DefCon32] AMD Sinkclose – Universal Ring2 Privilege Escalation
In the intricate landscape of system security, Enrique Nissim and Krzysztof Okupski, researchers from IOActive, uncover a critical vulnerability in AMD processors, dubbed Sinkclose. Their presentation delves into the shadowy realm of System Management Mode (SMM), a powerful x86 execution mode that operates invisibly to operating systems and hypervisors. By exposing a silicon-level flaw undetected for nearly two decades, Enrique and Krzysztof reveal a universal ring -2 privilege escalation exploit, challenging the robustness of modern CPU security mechanisms.
Understanding System Management Mode
Enrique opens by elucidating SMM, a privileged mode that initializes hardware during boot and resides in a protected memory region called SMRAM. Invisible to antivirus, endpoint detection and response (EDR) systems, and anti-cheat engines, SMM’s isolation makes it a prime target for attackers seeking to deploy bootkits or firmware implants. The researchers explain how AMD’s security mechanisms, designed to safeguard SMM, falter due to a fundamental design flaw, enabling unauthorized access to this critical layer.
Exploiting the Sinkclose Vulnerability
Krzysztof details the methodology behind exploiting Sinkclose, a flaw in a critical SMM component. By reverse-engineering AMD’s processor architecture, they crafted an exploit that achieves arbitrary code execution in ring -2, bypassing even hypervisor-level protections. Their approach leverages precise engineering to manipulate SMRAM, demonstrating how attackers could install persistent malware undetectable by conventional defenses. The vulnerability’s longevity underscores the challenges in securing silicon-level components.
Implications for Critical Systems
The impact of Sinkclose extends to devices like the PlayStation 5, though its hypervisor mitigates some risks by trapping specific register accesses. Enrique emphasizes that the exploit’s ability to evade kernel and hypervisor defenses poses significant threats to critical infrastructure, gaming platforms, and enterprise systems. Their findings, promptly reported to AMD, prompted microcode updates, though the researchers note the complexity of fully mitigating such deep-seated flaws.
Future Directions for CPU Security
Concluding, Krzysztof advocates for enhanced firmware validation and real-time monitoring of SMM interactions. Their work highlights the need for vendors to prioritize silicon-level security and for researchers to probe low-level components for hidden weaknesses. By sharing their exploit methodology, Enrique and Krzysztof empower the community to strengthen defenses against similar vulnerabilities, ensuring robust protection for modern computing environments.
Links:
[DefCon32] Breaching AWS Through Shadow Resources
The complexity of cloud environments conceals subtle vulnerabilities, and Yakir Kadkoda, Michael Katchinskiy, and Ofek Itach from Aqua Security reveal how shadow resources in Amazon Web Services (AWS) can be exploited. Their research uncovers six critical vulnerabilities, ranging from remote code execution to information disclosure, enabling potential account takeovers. By mapping internal APIs and releasing an open-source tool, Yakir, Michael, and Ofek empower researchers to probe cloud systems while offering developers robust mitigation strategies.
Uncovering Shadow Resource Vulnerabilities
Yakir introduces shadow resources—services that rely on others, like S3 buckets, for operation. Their research identified vulnerabilities in AWS services, including CloudFormation, Glue, and EMR, where misconfigured buckets allowed attackers to assume admin roles. One severe flaw enabled remote code execution, potentially compromising entire accounts. By analyzing service dependencies, Yakir’s team developed a methodology to uncover these hidden risks systematically.
Mapping and Exploiting Internal APIs
Michael details their approach to mapping AWS’s internal APIs, identifying common patterns that amplify vulnerability impact. Their open-source tool, released during the talk, automates this process, enabling researchers to detect exposed resources. For instance, unclaimed S3 buckets could be hijacked, allowing attackers to manipulate data or escalate privileges. This methodical mapping exposed systemic flaws, highlighting the need for vigilant resource management.
Mitigation Strategies for Cloud Security
Ofek outlines practical defenses, such as using scoped IAM policies with resource account conditions to restrict access to trusted buckets. He recommends verifying bucket ownership with expected bucket owner headers and using randomized bucket names to deter hijacking. These measures, applicable to open-source projects, prevent dangling resources from becoming attack vectors. Ofek emphasizes proactive checks to ensure past vulnerabilities are addressed.
Future Research and Community Collaboration
The trio concludes by urging researchers to explore new cloud attack surfaces, particularly internal API dependencies. Their open-source tool fosters community-driven discovery, encouraging developers to adopt secure practices. By sharing their findings, Yakir, Michael, and Ofek aim to strengthen AWS environments, ensuring that shadow resources no longer serve as gateways for catastrophic breaches.
Links:
[DefCon32] Manipulating Shim and Office for Code Injection
The Windows ecosystem harbors hidden attack surfaces, and security researchers Ron Ben-Yizhak and David Shandalov from Deep Instinct unveil a sophisticated technique to exploit them. By manipulating the Application Compatibility Framework (shim) and OfficeClickToRun service, they achieve stealthy code injection and privilege escalation without traditional traces like registry modifications. Their reverse engineering of undocumented APIs and kernel drivers reveals novel methods to subvert system defenses, challenging assumptions about patched vulnerabilities.
Reviving the Shim Attack Surface
Ron introduces the Application Compatibility Framework, designed to ensure legacy software runs on modern Windows systems. The shim infrastructure, managed by a kernel driver, applies runtime fixes to processes. By exploiting undocumented APIs, Ron and David craft a malicious shim that injects code without disk-based evidence, evading detection by endpoint detection and response (EDR) systems. This approach, applied to 64-bit processes, bypasses traditional monitoring, as injection occurs before EDR hooks are established.
Exploiting OfficeClickToRun for Escalation
David details their attack surface research on OfficeClickToRun.exe, a service running as NT AUTHORITY\SYSTEM. By leveraging its undocumented RPC interfaces and Opportunistic Lock (OpLock) mechanisms, they inject a DLL into a high-privilege process, achieving escalation. This method requires specific conditions, which they meticulously engineered, demonstrating the power of combining disparate system components into a cohesive attack vector.
Methodology and Community Collaboration
The duo’s methodology hinges on deep reverse engineering, analyzing shim data structures and AVL tables to manipulate process behavior. They modernize a previously known technique, making it registry-free and elusive. Ron and David share their tools’ source code, inviting the community to refine these attacks and explore additional shim fixes. Their findings highlight the potential for OpLock and shim mechanisms to serve as building blocks for complex, multi-component attacks.
Defensive Measures and Future Research
To counter these threats, Ron and David urge developers to monitor early-stage process injections and scrutinize undocumented APIs. They encourage further exploration of shim data structures and AVL table manipulations, which could yield new attack vectors. By open-sourcing their tools, they foster collaborative advancements in offensive security, aiming to strengthen Windows defenses against such stealthy techniques.
Links:
[DefCon32] Sudos and Sudon’ts: Peering Inside Sudo for Windows
In a groundbreaking move, Microsoft introduced Sudo for Windows in February 2024, bringing a Unix-like privilege elevation mechanism to Windows 11 Insider Preview. Michael Torres, a security researcher at Google, delves into the architecture of this novel feature, exploring its implementation, inter-process communication, and potential vulnerabilities. Michael’s analysis, rooted in reverse engineering and Rust’s interaction with Windows APIs, uncovers security flaws that challenge the tool’s robustness. His open-source approach invites the community to scrutinize and enhance Sudo for Windows, ensuring it balances usability with security.
Understanding Sudo for Windows
Michael begins by demystifying Sudo for Windows, a utility designed to allow users to execute commands with elevated permissions directly from a non-elevated console. Unlike its Unix counterpart, it leverages User Account Control (UAC) for elevation and Advanced Local Procedure Call (ALPC) for communication between processes. Available in Windows 11 version 24H2, the tool supports three configurations: running commands in a new window, disabling input in the current window, or inline execution akin to Linux sudo. Michael highlights its open-source nature, hosted on GitHub, which enables researchers to dissect its codebase for potential weaknesses.
Security Implications and Rust Challenges
Delving into the technical intricacies, Michael examines how Sudo for Windows interoperates with Windows APIs through Rust, a language touted for memory safety. However, invoking native Windows APIs requires “unsafe” Rust code, introducing risks of memory corruption vulnerabilities—counterintuitive to Rust’s safety guarantees. He identifies non-critical issues reported to Microsoft’s Security Response Center (MSRC) and one embargoed vulnerability, emphasizing the need for rigorous scrutiny. For bug hunters, Michael advises focusing on unsafe Rust boundaries, where Windows API calls create exploitable seams.
Path Resolution and Process Coordination
Michael explores the path resolution process, critical for handling file and relative path inputs in Sudo for Windows. The tool’s reliance on ALPC for coordinating elevated and non-elevated processes introduces complexity, as it must maintain secure communication across privilege boundaries. Missteps in path handling or process elevation could lead to unintended escalations, a concern Michael flags for further investigation. His analysis underscores the delicate balance between functionality and security in this new feature.
Community Engagement and Future Directions
Encouraging community involvement, Michael praises the open-source release, urging researchers to probe the codebase for additional vulnerabilities. As Sudo for Windows rolls out to mainline Windows 11, its adoption could reshape administrative workflows, but only if security holds. He advocates for responsible bug hunting to prevent malicious exploitation, ensuring the tool delivers on its promise of seamless elevation without compromising system integrity.
Links:
[DefCon32] AMDSinkclose – Universal Ring2 Privilege Escalation
In the intricate landscape of hardware security, vulnerabilities often lurk within architectural designs that have persisted for years. Enrique Nissim and Krzysztof Okupski, principal security consultants at IOActive, unravel a profound flaw in AMD processors, dubbed AMDSinkclose. Their exploration reveals how this issue enables attackers to escalate privileges to System Management Mode (SMM), granting unparalleled access to system resources. By dissecting the mechanics of SMM and the processor’s memory handling, they demonstrate exploitation paths that bypass traditional safeguards, affecting a vast array of devices from laptops to servers.
SMM represents one of the most potent execution environments in x86 architectures, offering unrestricted control over I/O devices and memory. It operates stealthily, invisible to operating systems, hypervisors, and security tools like antivirus or endpoint detection systems. During boot, firmware initializes hardware and loads SMM code into a protected memory region called SMRAM. At runtime, the OS can invoke SMM services for tasks such as power management or security checks via System Management Interrupts (SMIs). When an SMI triggers, the processor saves its state in SMRAM, executes the necessary operations, and resumes normal activity. This isolation makes SMM an attractive target for persistence mechanisms, including bootkits or firmware implants.
The duo’s prior research focused on vendor misconfigurations and software flaws in SMM components, yielding tools for vulnerability detection and several CVEs in 2023. However, AMDSinkclose shifts the lens to an inherent processor defect. Unlike Intel systems, where SMM-related Model-Specific Registers (MSRs) are accessible only within SMM, AMD allows ring-0 access to these registers. While an SMM lock bit prevents runtime tampering with key configurations, a critical oversight in the documentation exposes two fields—TClose and AClose—not covered by this lock. TClose, in particular, redirects data accesses in SMM to Memory-Mapped I/O (MMIO) instead of SMRAM, creating a pathway for manipulation.
Architectural Foundations and the Core Vulnerability
At the heart of SMM security lies the memory controller’s role in protecting SMRAM. Firmware configures registers like TSEG Base, TSEG Mask, and SMM Base to overlap and shield this region. The TSEG Mask includes fields for enabling protections, but the unlocked TClose bit allows ring-0 users to set it, altering behavior without violating the lock. When activated, instruction fetches in SMM remain directed to DRAM, but data accesses divert to MMIO. This split enables attackers to control execution by mapping malicious content into the MMIO space.
The feature originated around 2006 to allow SMM code to access I/O devices using SMRAM’s physical addresses, though no vendors appear to utilize it. Documentation warns against leaving TClose set upon SMM exit, as it could misdirect state saves to MMIO. Yet, from ring-0, setting this bit and triggering an SMI causes immediate system instability—freezes or hangs—due to erroneous data handling. This echoes the 2015 Memory Sinkhole attack by Christopher Domas, which remapped the APIC to overlap TSEG, but AMDSinkclose affects the entire TSEG region, amplifying the impact.
Brainstorming exploits, Enrique and Krzysztof considered remapping PCI devices to overlay SMRAM, but initial attempts failed due to hardware restrictions. Instead, they targeted the SMM entry point, a vendor-defined layout typically following EDK2 standards. This includes a core area for support code, per-core SMM bases with entry points at offset 0x8000, and save states at 0xFE00. By setting TClose and invoking an SMI, data reads from these offsets redirect to MMIO, allowing control if an attacker maps a suitable device there.
Exploitation Techniques and Multi-Core Challenges
Exploiting AMDSinkclose requires precise manipulation of the Global Descriptor Table (GDT) and Interrupt Descriptor Table (IDT) within SMM. Upon SMI entry, the processor operates in real mode, loading a GDT from the save state to transition to protected mode. By controlling data fetches via TClose, attackers can supply a malicious GDT, enabling arbitrary code execution. The challenge lies in aligning MMIO mappings with SMM offsets, as direct PCI remapping proved ineffective.
The solution involves leveraging the processor’s address wraparound behavior. In protected mode, addresses exceeding 4GB wrap around, but SMM’s real-mode entry point operates at a lower level where this wraparound can be exploited. By setting the SMM base to a high address like 0xFFFFFFF0, data accesses wrap to low MMIO regions (0x0 to 0xFFF), where integrated devices like the Local APIC reside. This allows overwriting the GDT with controlled content from the APIC’s registers.
Multi-core systems introduce complexity, as all cores enter SMM simultaneously during a broadcast SMI. The exploit must handle concurrent execution, ensuring only one core performs the malicious action while others halt safely. Disabling Simultaneous Multithreading (SMT) simplifies this, but wraparound enables targeting specific cores. Testing on Ryzen laptops confirmed reliability, with code injection succeeding across threads.
Impact on Firmware and Mitigation Strategies
The ramifications extend to firmware persistence. Once in SMM, attackers disable SPI flash protections like ROM Armor, enabling writes to non-volatile storage. Depending on configurations—such as Platform Secure Boot (PSB)—outcomes vary. Fully enabled protections limit writes to variables, potentially breaking Secure Boot by altering keys. Absent PSB, full firmware implants become feasible, resistant to OS reinstalls or updates, as malware can intercept and falsify flash operations.
Research on vendor configurations reveals widespread vulnerabilities: many systems lack ROM Armor or PSB, exposing them to implants. Even with protections, bootkits remain possible, executing pre-OS loader. A fused disable of PSB ensures perpetual vulnerability.
AMD’s microcode update addresses the issue, though coverage may vary. OEMs can patch SMM entry points to detect and halt on TClose activation, integrable into EDK2 or Coreboot. Users might trap MSR accesses via hypervisors. Reported in October 2023, CVE-2023-31315 was assigned, with an advisory published recently. Exploit code is forthcoming, underscoring the need for deepened architectural scrutiny.