Mitigating overflows using defense in-depth. What can your compiler do for you?Javier Tallón
Defense-in-depth is based on the principle that, while no security is perfect, the presence of many independent layers of defense will geometrically increase an attacker's difficulty in breaking through the walls and slowing them down to the point where the effort to carry out an attack is not worthwhile. Each layer multiplies the effects of the previous layer. If the outer wall deters 90% of attacks, and the inner walls deter 90% of attacks, then in combination they deter 99% of attacks. Defense-in-depth defense techniques place core assets behind varied and individually effective layers of security, each of which must be circumvented for an attack to succeed.
There are many options provided by your compiler that can help you mitigate known attacks such as buffer overflow without touching a single line of code. In this presentation, we will take a historical look at the mitigations proposed over time by cybersecurity researchers, and how they have been violated, forcing the development of new and ingenious countermeasures.
SystemVerilog Assertions verification with SVAUnit - DVCon US 2016 TutorialAmiq Consulting
SVAUnit is an UVM compliant package that addresses verification of SystemVerilog Assertions (SVAs) with several advantages:
- decouple assertion validation code from assertion definition code
- simplify the generation of a wide range of stimuli, from 1 bit signal toggling to transactions
- provide the ability to reuse scenarios
- provide self-checking mechanisms
- report test status automatically
- integrate with major simulators
This tutorial discusses SVA planning, coding guidelines, SVAUnit (SVAUnit framework, self-checking tests, debug), and test patterns. Planning includes parametrization, temporal sequence composition, sequence reuse and also consider how the SVA package will be integrated with other verification methods. Coding guidelines ensure efficiency as well as avoid common implementation pitfalls.
How Triton can help to reverse virtual machine based software protectionsJonathan Salwan
The first part of the talk is going to be an introduction to the Triton framework to expose its components and to explain how they work together. Then, the second part will include demonstrations on how it's possible to reverse virtual machine based protections using taint analysis, symbolic execution, SMT simplifications and LLVM-IR optimizations.
Dynamic Binary Analysis and Obfuscated Codes Jonathan Salwan
At this presentation we will talk about how a DBA (Dynamic Binary Analysis) may help a reverse engineer to reverse obfuscated code. We will first introduce some basic obfuscation techniques and then expose how it's possible to break some stuffs (using our open-source DBA framework - Triton) like detect opaque predicates, reconstruct CFG, find the original algorithm, isolate sensible data and many more... Then, we will conclude with a demo and few words about our future work.
Mitigating overflows using defense in-depth. What can your compiler do for you?Javier Tallón
Defense-in-depth is based on the principle that, while no security is perfect, the presence of many independent layers of defense will geometrically increase an attacker's difficulty in breaking through the walls and slowing them down to the point where the effort to carry out an attack is not worthwhile. Each layer multiplies the effects of the previous layer. If the outer wall deters 90% of attacks, and the inner walls deter 90% of attacks, then in combination they deter 99% of attacks. Defense-in-depth defense techniques place core assets behind varied and individually effective layers of security, each of which must be circumvented for an attack to succeed.
There are many options provided by your compiler that can help you mitigate known attacks such as buffer overflow without touching a single line of code. In this presentation, we will take a historical look at the mitigations proposed over time by cybersecurity researchers, and how they have been violated, forcing the development of new and ingenious countermeasures.
SystemVerilog Assertions verification with SVAUnit - DVCon US 2016 TutorialAmiq Consulting
SVAUnit is an UVM compliant package that addresses verification of SystemVerilog Assertions (SVAs) with several advantages:
- decouple assertion validation code from assertion definition code
- simplify the generation of a wide range of stimuli, from 1 bit signal toggling to transactions
- provide the ability to reuse scenarios
- provide self-checking mechanisms
- report test status automatically
- integrate with major simulators
This tutorial discusses SVA planning, coding guidelines, SVAUnit (SVAUnit framework, self-checking tests, debug), and test patterns. Planning includes parametrization, temporal sequence composition, sequence reuse and also consider how the SVA package will be integrated with other verification methods. Coding guidelines ensure efficiency as well as avoid common implementation pitfalls.
How Triton can help to reverse virtual machine based software protectionsJonathan Salwan
The first part of the talk is going to be an introduction to the Triton framework to expose its components and to explain how they work together. Then, the second part will include demonstrations on how it's possible to reverse virtual machine based protections using taint analysis, symbolic execution, SMT simplifications and LLVM-IR optimizations.
Dynamic Binary Analysis and Obfuscated Codes Jonathan Salwan
At this presentation we will talk about how a DBA (Dynamic Binary Analysis) may help a reverse engineer to reverse obfuscated code. We will first introduce some basic obfuscation techniques and then expose how it's possible to break some stuffs (using our open-source DBA framework - Triton) like detect opaque predicates, reconstruct CFG, find the original algorithm, isolate sensible data and many more... Then, we will conclude with a demo and few words about our future work.
The System Verilog UVM promises to improve verification productivity while enabling teams to share tests and test benches between projects and divisions. This promise can be achieved; the UVM is a powerful methodology for using constrained randomization to reach higher functional coverage goals and to explore combinations of tests without having to write each one individually. Unfortunately the UVM promise can be hard to reach without training, practice and some significant expertise. Verification is one of the most important activities in the flow of ASIC/VLSI design. Verification consumes large amount of design flow cycle & efforts to ensure design is bug free. Hence it becomes intense requirement for powerful and reusable methodology for verification.
Kernel Recipes 2014 - Writing Code: Keep It Short, Stupid!Anne Nicolas
The traditional KISS principle says that you are stupid if you can’t keep it simple. However, keeping it simple is actually very, very hard. But my lasting impression after reading a lot of code (linux kernel and otherwise) over the years is that there is no excuse for not keeping your code short. And usually, keeping it short is a very good first step towards keeping it simple. This presentation will give some simple tricks and pointers to keep your code short and I will also give some guidelines how to do design and implementation from a high-level point of view. These simple rules should make it easier for you to get your code accepted in open source projects such as the linux kernel.
Hans Verkuil
An Open Discussion of RISC-V BitManip, trends, and comparisons _ ClaireRISC-V International
Join RISC-V BitManip industry leader Claire Xenia Wolf and Dr. James Cuff for an open and lively discussion with an interactive Q&A on RISC-V and BitManip including trends and comparisons with the existing architecture landscape including x86 and ARM and what specifically makes RISC-V unique.
UVM is a standardized methodology for verifying complex IP and SOC in the semiconductor industry. UVM is an Accellera standard and developed with support from multiple vendors Aldec, Cadence, Mentor, and Synopsys. UVM 1.0 was released on 28 Feb 2011 which is widely accepted by verification Engineer across the world. UVM has evolved and undergone a series of minor releases, which introduced new features.
UVM provides the standard structure for creating test-bench and UVCs. The following features are provided by UVM
• Separation of tests from test bench
• Transaction-level communication (TLM)
• Sequences
• Factory and configuration
• Message reporting
• End-of-test mechanism
• Register layer
ATF(ARM Trusted Firmware)は、ARMv8では重要なソフトウェア。
全体を利用するのではなく、その一部を利用可能。
この資料では、BL31(EL3 Runtime Firmware)を単体で使う場合、どうすればいいのかを、Xilinx社のZynq UltraScale+ MPSoCを例に説明しています。
ATF (ARM Trusted Firmware) is an important software in ARMv8.
Instead of using the whole, part of it is available.
This document explains how to do when using BL31 (EL3 Runtime Firmware) alone, for example, with Xilinx's Zynq UltraScale + MPSoC.
The System Verilog UVM promises to improve verification productivity while enabling teams to share tests and test benches between projects and divisions. This promise can be achieved; the UVM is a powerful methodology for using constrained randomization to reach higher functional coverage goals and to explore combinations of tests without having to write each one individually. Unfortunately the UVM promise can be hard to reach without training, practice and some significant expertise. Verification is one of the most important activities in the flow of ASIC/VLSI design. Verification consumes large amount of design flow cycle & efforts to ensure design is bug free. Hence it becomes intense requirement for powerful and reusable methodology for verification.
Kernel Recipes 2014 - Writing Code: Keep It Short, Stupid!Anne Nicolas
The traditional KISS principle says that you are stupid if you can’t keep it simple. However, keeping it simple is actually very, very hard. But my lasting impression after reading a lot of code (linux kernel and otherwise) over the years is that there is no excuse for not keeping your code short. And usually, keeping it short is a very good first step towards keeping it simple. This presentation will give some simple tricks and pointers to keep your code short and I will also give some guidelines how to do design and implementation from a high-level point of view. These simple rules should make it easier for you to get your code accepted in open source projects such as the linux kernel.
Hans Verkuil
An Open Discussion of RISC-V BitManip, trends, and comparisons _ ClaireRISC-V International
Join RISC-V BitManip industry leader Claire Xenia Wolf and Dr. James Cuff for an open and lively discussion with an interactive Q&A on RISC-V and BitManip including trends and comparisons with the existing architecture landscape including x86 and ARM and what specifically makes RISC-V unique.
UVM is a standardized methodology for verifying complex IP and SOC in the semiconductor industry. UVM is an Accellera standard and developed with support from multiple vendors Aldec, Cadence, Mentor, and Synopsys. UVM 1.0 was released on 28 Feb 2011 which is widely accepted by verification Engineer across the world. UVM has evolved and undergone a series of minor releases, which introduced new features.
UVM provides the standard structure for creating test-bench and UVCs. The following features are provided by UVM
• Separation of tests from test bench
• Transaction-level communication (TLM)
• Sequences
• Factory and configuration
• Message reporting
• End-of-test mechanism
• Register layer
ATF(ARM Trusted Firmware)は、ARMv8では重要なソフトウェア。
全体を利用するのではなく、その一部を利用可能。
この資料では、BL31(EL3 Runtime Firmware)を単体で使う場合、どうすればいいのかを、Xilinx社のZynq UltraScale+ MPSoCを例に説明しています。
ATF (ARM Trusted Firmware) is an important software in ARMv8.
Instead of using the whole, part of it is available.
This document explains how to do when using BL31 (EL3 Runtime Firmware) alone, for example, with Xilinx's Zynq UltraScale + MPSoC.
It is about the SET that how it was launched and what were the problems which it faced after launched and what was new after it as a solution of the problems as the security experts found.
Applying Memory Forensics to Rootkit DetectionIgor Korkin
Volatile memory dump and its analysis is an essential part of digital forensics. Among a number of various software and hardware approaches for memory dumping there are authors who point out that some of these approaches are not resilient to various anti-forensic techniques, and others that require a reboot or are highly platform dependent. New resilient tools have certain disadvantages such as low speed or vulnerability to rootkits which directly manipulate kernel structures e.g. page tables. A new memory forensic system – Malware Analysis System for Hidden Knotty Anomalies (MASHKA) is described in this paper. It is resilient to popular anti-forensic techniques. The system can be used for doing a wide range of memory forensics tasks. This paper describes how to apply the system for research and detection of kernel mode rootkits and also presents analysis of the most popular anti-rootkit tools.
Applying Memory Forensics to Rootkit Detection #adfsl #Virginia #USA
http://bit.ly/cdfsl_paper
http://bit.ly/cdfsl_slides
http://bit.ly/cdfsl_speech
This white paper includes all the basic things about Rootkit, how they work, their types, detection methods, their uses, the concept of payload, and rootkit removal.
[Defcon] Hardware backdooring is practicalMoabi.com
This presentation will demonstrate that permanent backdooring of hardware is practical. We have built a generic proof of concept malware for the intel architecture, Rakshasa, capable of infecting more than a hundred of different motherboards. The first net effect of Rakshasa is to disable NX permanently and remove SMM related fixes from the BIOS, resulting in permanent lowering of the security of the backdoored computer, even after complete earasing of hard disks and reinstallation of a new operating system. We shall also demonstrate that preexisting work on MBR subvertions such as bootkiting and preboot authentication software bruteforce can be embedded in Rakshasa with little effort. More over, Rakshasa is built on top of free software, including the Coreboot project, meaning that most of its source code is already public. This presentation will take a deep dive into Coreboot and hardware components such as the BIOS, CMOS and PIC embedded on the motherboard, before detailing the inner workings of Rakshasa and demo its capabilities. It is hoped to raise awareness of the security community regarding the dangers associated with non open source firmwares shipped with any computer and question their integrity. This shall also result in upgrading the best practices for forensics and post intrusion analysis by including the afore mentioned firmwares as part of their scope of work.
Defeating x64: Modern Trends of Kernel-Mode RootkitsAlex Matrosov
Versions of Microsoft Windows 64 bits were considered resistant against kernel mode rootkits because integrity checks performed by the system code. However, today there are examples of malware that use methods to bypass the security mechanisms Implemented. This presentation focuses on issues x64 acquitectura security, specifically in the signature policies kernel mode code and the techniques used by modern malware to sauté. We analyze the techniques of penetration of the address space of kernel mode rootkits used by modern in-the-wild: - Win64/Olmarik (TDL4) - Win64/TrojanDownloader.Necurs (rootkit dropper) - NSIS / TrojanClicker.Agent.BJ (rootkit dropper) special attention is given to bootkit Win64/Olmarik (TDL4) for being the most prominent example of a kernel mode rootkit aimed at 64-bit Windows systems. Detail the remarkable features of TDL4 over its predecessor (TDL3/TDL3 +): the development of user mode components and kernel mode rootkit techniques used to bypass the HIPS, hidden and system files as bootkit functionality. Finally, we describe possible approaches to the removal of an infected computer and presents a free forensics tool for the dump file system hidden TDL.
12 Ways Not to get 'Hacked' your Kubernetes ClusterSuman Chakraborty
Kubernetes enable enterprises to automate many aspects of application deployment, providing tremendous business benefits. This talk aims to discuss best practices around Kubernetes security and how threats and exploits can be mitigated, minimizing service disruption on Kubernetes platform.
Es gibt viele Möglichkeiten hoch verfügbare und/oder skalierbare Dienste zu bauen, die weitläufig im Einsatz sind: DNS Round-Robin, ein Satz Loadbalancer oder Reverse-Proxies, etc. pp. An Anycast und BGP im eigenen Rechenzentrum trauen sich einige Admins und Entscheider nicht heran.
Warum es OK ist, wenn einige bis viele Server die selbe IP-Adresse haben, viele Wege nach Rom führen und wie man so ein Setup aufbaut und betreibt soll in diesem Vortrag praxisnah gezeigt werden. Wir bauen auf Basis von Debian Linux, Bird und Bind einen Cluster von Webservern und spielen ein bisschen damit herum (wenn noch genug Zeit ist).
I am Tim D. I am an Operating System Assignment Expert at programminghomeworkhelp.com. I hold a Ph.D. in Programming from, University of Waterloo, Canada. I have been helping students with their homework for the past 9 years. I solve assignments related to Operating systems.
Visit programminghomeworkhelp.com or email support@programminghomeworkhelp.com.
You can also call on +1 678 648 4277 for any assistance with Operating System Assignments.
Chapter 5 – Cloud Resource
Virtualization
Contents
Virtualization.
Layering and virtualization.
Virtual machine monitor.
Virtual machine.
Performance and security isolation.
Architectural support for virtualization.
x86 support for virtualization.
Full and paravirtualization.
Xen 1.0 and Xen 2.0.
Performance comparison of virtual machine monitors.
The darker side of virtualization.
Software fault isolation.
Cloud Computing: Theory and Practice. Chapter 5 2 Dan C. Marinescu
Motivation
There are many physical realizations of the fundamental
abstractions necessary to describe the operation of a computing
systems.
Interpreters.
Memory.
Communications links.
Virtualization is a basic tenet of cloud computing, it simplifies the
management of physical resources for the three abstractions.
The state of a virtual machine (VM) running under a virtual machine
monitor (VMM) can de saved and migrated to another server to
balance the load.
Virtualization allows users to operate in environments they are
familiar with, rather than forcing them to idiosyncratic ones.
Cloud Computing: Theory and Practice.
Chapter 5 3 Dan C. Marinescu
Motivation (cont’d)
Cloud resource virtualization is important for:
System security, as it allows isolation of services running on
the same hardware.
Performance and reliability, as it allows applications to migrate
from one platform to another.
The development and management of services offered by a
provider.
Performance isolation.
Cloud Computing: Theory and Practice.
Chapter 5 4 Dan C. Marinescu
Virtualization
Simulates the interface to a physical object by:
Multiplexing: creates multiple virtual objects from one instance
of a physical object. Example - a processor is multiplexed
among a number of processes or threads.
Aggregation: creates one virtual object from multiple physical
objects. Example - a number of physical disks are aggregated
into a RAID disk.
Emulation: constructs a virtual object from a different type of a
physical object. Example - a physical disk emulates a Random
Access Memory (RAM).
Multiplexing and emulation. Examples - virtual memory with
paging multiplexes real memory and disk; a virtual address
emulates a real address.
Cloud Computing: Theory and Practice.
Chapter 5 5 Dan C. Marinescu
Layering
Layering – a common approach to manage system complexity.
Minimizes the interactions among the subsystems of a complex
system.
Simplifies the description of the subsystems; each subsystem is
abstracted through its interfaces with the other subsystems.
We are able to design, implement, and modify the individual
subsystems independently.
Layering in a computer system.
Hardware.
Software.
Operating system.
Libraries.
Applications.
.
Chapter 5 – Cloud Resource
Virtualization
Contents
Virtualization.
Layering and virtualization.
Virtual machine monitor.
Virtual machine.
Performance and security isolation.
Architectural support for virtualization.
x86 support for virtualization.
Full and paravirtualization.
Xen 1.0 and Xen 2.0.
Performance comparison of virtual machine monitors.
The darker side of virtualization.
Software fault isolation.
Cloud Computing: Theory and Practice. Chapter 5 2 Dan C. Marinescu
Motivation
There are many physical realizations of the fundamental
abstractions necessary to describe the operation of a computing
systems.
Interpreters.
Memory.
Communications links.
Virtualization is a basic tenet of cloud computing, it simplifies the
management of physical resources for the three abstractions.
The state of a virtual machine (VM) running under a virtual machine
monitor (VMM) can de saved and migrated to another server to
balance the load.
Virtualization allows users to operate in environments they are
familiar with, rather than forcing them to idiosyncratic ones.
Cloud Computing: Theory and Practice.
Chapter 5 3 Dan C. Marinescu
Motivation (cont’d)
Cloud resource virtualization is important for:
System security, as it allows isolation of services running on
the same hardware.
Performance and reliability, as it allows applications to migrate
from one platform to another.
The development and management of services offered by a
provider.
Performance isolation.
Cloud Computing: Theory and Practice.
Chapter 5 4 Dan C. Marinescu
Virtualization
Simulates the interface to a physical object by:
Multiplexing: creates multiple virtual objects from one instance
of a physical object. Example - a processor is multiplexed
among a number of processes or threads.
Aggregation: creates one virtual object from multiple physical
objects. Example - a number of physical disks are aggregated
into a RAID disk.
Emulation: constructs a virtual object from a different type of a
physical object. Example - a physical disk emulates a Random
Access Memory (RAM).
Multiplexing and emulation. Examples - virtual memory with
paging multiplexes real memory and disk; a virtual address
emulates a real address.
Cloud Computing: Theory and Practice.
Chapter 5 5 Dan C. Marinescu
Layering
Layering – a common approach to manage system complexity.
Minimizes the interactions among the subsystems of a complex
system.
Simplifies the description of the subsystems; each subsystem is
abstracted through its interfaces with the other subsystems.
We are able to design, implement, and modify the individual
subsystems independently.
Layering in a computer system.
Hardware.
Software.
Operating system.
Libraries.
Applications.
.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
2. Speaker info
Edgar Barbosa
Security researcher
Currently employed at COSEINC
Experience with reverse engineering of Windows kernel
and x86/x64 cpu architecture
Published some articles at rootkit.com
Participated in the creation of BluePill, a virtualization
hardware based rootkit
5. Hardware virtualization
rootkits
Intel and AMD developed virtualization extensions to the
x86 architecture - VT-x and SVM.
There are 2 famous hardware virtualization based rootkits:
Vitriol, created by Dino Dai Zovi – uses Intel VT-x
Bluepill, designed by Joanna Rutkowska – uses AMD SVM
Source code not public
We will focus the Bluepill rootkit in this presentation, but
the concepts and methods are very similar to the Intel
plataform.
6. Bluepill
Designed by Joanna Rutkowska
Intellectual property of COSEINC
Uses AMD Secure Virtual Machine (SVM) extensions
Runs in 64-bit mode
Supports multicore systems
7. AMD SVM
SVM stands for “Secure Virtual Machine”
It’s a CPU extension to support Virtual Machine Monitors
(VMM), a.k.a. hypervisor.
8 new instructions:
VMRUN
VMSAVE
VMLOAD
VMMCALL
CLGI
STGI
SKINIT
INVLPGA
8. Initialization of a SVM rootkit
Before any SVM instruction can be used, the EFER.SVME
must be set to 1.
Trying to execute a SVM instruction with SVME equal 0
results in #UD (Invalid opcode) exception.
Allocates and initialize the VMCB structure.
VMCB (Virtual Machine Control Block) address must be 4KB-
aligned
VMCB describes a virtual machine to be executed.
It contains:
Instruction or events in the guest to be intercepted
Control bits
Guest processor state( General registers, RIP, CR registers, … )
9. Initialization of a SVM rootkit
After VMCB initialization, set the VM_HSAVE_PA MSR.
This is the physical address where the VMRUN instruction
saves host processor state information.
Then execute the VMRUN instruction with RAX register value
equal the physical address of the VMCB
11. VMRUN instruction
Available only at CPL-0
CPU enters in a new processor mode: Guest Mode
In guest mode the behavior of some instructions changes
to facilitate virtualization
Consistency checks on the host and guest state
Saves the host processor state
Load the guest process state configured in the VMCB
CPU now runs in guest mode until an intercept occurs
12. #VMEXIT
When a intercept triggers, the processor performs a #VMEXIT
On #VMEXIT the processor:
Disable interrupts
Clear all intercepts
Sets the host CPL to 0
Disable all breakpoints
Checks the reload host state for consistency
The reason of the #VMEXIT is saved in the EXITINFO field
of the VMCB structure
Execute the Bluepill interception handler routine
15. “Undetectable” rootkits
Popek and Goldberg VMM properties:
Efficiency
Resource control
Equivalence
Equivalence “implies that any program executing on a virtual machine must
behave in a manner identical to the way it would have behaved when
running directly on the native hardware” [1]
SVM/VT-x rootkits are only theoreticaly ‘undetectable’
However, the equivalence principle is not fully respected in the hardware
virtualization extensions
There are computer resources that hypervisor has not full control:
TLB (partially)
Branch prediction
SMP processing
16. Timing attacks
The most obvious attack against hardware virtualization
rootkits is timing attack.
We measure the time of execution of some probably
intercepted instruction and compare the value against some
trusted baseline.
But AMD and Intel hardware virtualization extensions has
support to intercept any internal source of timing:
RDTSC
RDMSR
I/O ports
Hardware virtualization even supports a TSC offset value to be
subtracted from every TSC access attempt.
This is the reason that local timing attacks fails
18. TLB
A Translation Lookaside Buffer (TLB) is a CPU cache that is
used to improve the speed of virtual address translation.
Detailed TLB information can be obtained by CPUID
instruction. Returns information like the number of entries of
each TLB, the type and the associativity of the cache.
For each line in the TLB is stored information like:
Tag, used to compare with the virtual address
Physical address, the result of the VA translation
Page attributes
If the translation is not store in the cache (cache miss), the
system must execute the ‘table-walk’ procedure. This is a
expensive clock-cycle operation.
19. TLB
The TLB has a limited number of entries.
The contents of each line is not accessible by software
However we can fill the TLB by accessing several pages.
The idea is to fill all the TLB entries and measure the time
to access these cached pages. Now we execute a
privileged instruction that must be intercepted by a
hypervisor. If there is a hypervisor running on the system,
it will evict some TLB entries. After executing the
privileged instruction we measure the time to execute the
previous cached pages. If it takes more time to be
accessed, there is a hypervisor running.
20. TLB
The idea of using TLB to detect hypervisor was first published
by Peter Ferrie [2]. However, in the second version of his paper
[3], Ferrie states that the TLB method does not work on AMD-
based hypervisors because they can direct the hardware to not
flush the TLB when a hypervisor event occurs.
Ferrie suggests the CPUID instruction to be used in the TLB
method. But Bluepill doesn’t need to intercept cpuid
instruction. Another instruction could be used instead, the
rdmsr EFER, which bluepill must intercept.
It is still possible to use the TLB method to detect bluepill even
if the hypervisor controls TLB flush! How?
21. TLB
TLB entries are tagged with ASID (Address Space Identifier) bits to
distinguish different host and/or guest space address.
ASID #00 assigned to VMM and #1..#63 to guests.
TLB_CONTROL field:
The VMM can control the TLB flush operations by setting the
TLB_CONTROL field on the VMCB. If set to 1, the VMRUN
instruction will flush the entire TLB (all ASID’s).
Even with tagged ASID TLB, we can evict all lines in the TLB. The
number of TLB entries are limited, so it will evict lines if necessary.
Opteron primary TLB has only 40 entries [4].
AMD optimization manual suggests to avoid using the
TLB_CONTROL = 1 to flush the guest TLB. Instead, it is best to
assign a new ASID to the guest!
22. Branch prediction
Studies have shown that the behavior of branch instruction is
highly predictable [5]
Execution trace history of branch instructions can be used to
predict its future behavior.
If a branch is predicted to be taken and this prediction turns out
to be incorrect, there is a huge performance penalty because all
the pipeline must be flushed.
There are a lot of branch prediction schemes. Explaining these
schemes are out of the scope of this presentation.
There are some very good references about this subject[5]
Branch prediction unit uses a small cache to store the history of
the branch instruction execution.
23. Branch prediction
There is another buffer to store the target address of the branch,
the BTB (Branch Target Buffer )
How to use the branch prediction unit (BPU) to detect
hypervisor code?
Using the prediction rules of static and dynamic predictors, we
can fill the entries of the branch history tables and measure the
time to execute our code. Now the detector executes a privileged
instruction that will be intercept if there is a hypervisor running.
The hypervisor code will affect the branch history tables. We
execute now the ‘branch test code’ again without the privileged
instruction and measure the time. If the execution of the
privileged instruction was intercepted, the measured times will be
different.
24. Branch prediction
The Branch Prediction Unit was successfully used to obtain a
512-bit encryption key by using a Branch Prediction Analysis
(BPA) attack[6]. This attack is based in some interesting
features of BPU:
The execution history cache is accessed using just a few low-
order bits from the branch instruction address. Two different
address can use the same history. This is called Branch Aliasing
or Branch Interference.
The cache is shared between all threads.
The spy thread was running simultaneously with the decryption
thread. Since the two threads was using the same branch
prediction cache (branch aliasing), the spy thread can
determine which branches the decryption thread has taken.
26. Branch prediction
It is not possible to use Branch Aliasing effect to detect
virtualization rootkits due to the fact that we do not know the
virtual address where the rootkit code is being executed.
To use our detection method we must know internal details of
the implementation of the branch prediction unit. However, this
information is not easy to find in the cpu manuals.
We can use some very clever benchmarks developed by Milena
Milenkovic, Aleksandar Milenkovic and Jeffrey Kulick [7].
These benchmarks give us very specific details of the BPU,
like the number of entries and associativiy of BTB, the bits
used from the branch address that are used as the set index and
the local branch history length.
27. Counter based detection
Bluepill can intercept attempts to read the TSC MSR or any
other clock.
However, we can create our own clock by using a simple
counter algorithm.
Using a multicore system, we can create two threads running
concurrently.
Thread #2 can measure how long Thread #1 takes to execute
some routine or instruction.
It is necessary a synchronization protocol between the threads
to signal when to start and when to finish the counter increment
operation.
SMP uses shared memory, which can be used for the
synchronization protocol.
28. Counter based detection
How this detection method really works?
Basic idea:
Thread #1 will set the ‘start counter’ synchronization signal
and wait the reply of thread #2.
Thread #1 will execute a instruction that bluepill must
intercept ( rdmsr EFER ), while thread #2 starts to increment
the counter at the same time.
After the intercepted instruction, thread #1 set the ‘stop
counter’ synchronization signal and thread #2 stops the
counting process.
Now we check the value of the counter
30. Counter based detection
Using a simple counter code like:
while( stopCounter == 0 )
counter++;
The results of a ‘rdmsr EFER’ test are:
Counter = 016h for a clean system.
Counter = 02000h for a system running a HBR
The counter code can be optimized using the AMD
optimization manual rules.
31. Counter based detection
To avoid detection, bluepill must stop thread #2 counter as
soon it intercepts any event.
However just the #VMEXIT control transferring process takes
around 1000h clock cycles!
The CPU#2 bluepill hypervisor is in ‘sleep mode’ while the
counter runs and even if the CPU#1 sends a IPI (Inter
processor interrupt ) to CPU#2, it will take even more time.
The CPU#1 hypervisor doesn’t have access to the CPU#2
registers context.
It is too late to change any thread schedule quantum value
32. Counter based detection
What if our counter code is interrupted by some external
interrupt, like the clock, at the start of the counter process?
It is good to avoid interrupts in our counter code, but not really
necessary
We can’t guarantee that the counter code will not be
interrupted
Clear interrupt methods are interceptable by the rootkit:
Temporarily disable the APIC (interceptable)
CLI instruction (interceptable)
PUSHF and POPF instructions (interceptable)
Solution:
We can run the detection code several times. All we need is a
weird counter value.
33. Counter based detection
There is another way for the rootkit to detect this detection
method?
Very difficult. We can implement several different
synchronization routines and algorithms to make sure that
the threads are running concurrently.
There is no time for the rootkit to unload itself to avoid
detection after the intercept.
34. BP in hibernation-mode
One interesting idea discussed is the possibility of bluepill
being able to unload itself while some attack is being executed
and reload itself after the finish of the attack.[8]
That’s a weird idea because if we know that the rootkit is
unloaded, we can load our own detector hypervisor and waits
for any code trying to get access to SVM resources! Remember
bluepill is predicted to be undetectable even if the source is
published.
However, the unload idea can be cleverly used against the next
detection idea. It is interesting to present this attack to know
how virtualization rootkits can use this ‘unload’ trick.
35. #GP detection
EFER (Extended Feature Enable Register ) is a model
specific register (MSR)
Can be accessed by RDMSR and WRMSR instructions.
MSR EFER index is 0xC0000080
Before using the AMD SVM extensions, it is necessary to
set the EFER.SVME bit to 1.
Bluepill intercepts all attempt of read or write in the
EFER.
There is a way to know the value of SVME bit without
being intercepted?
36. VMSAVE instruction
The VMSAVE instruction stores a subset of the processor state into
the VMCB specified by the physical address in the RAX register.
This is a Secure Virtual Machine Instruction.
This instruction generates a #UD exception if SVM is not enabled.
Pseudo code:
37. VMSAVE and EFER
What happens if we execute VMSAVE instruction with RAX
containing a invalid physical address and SVM?
If the EFER.SVME = 0 the system generates a #UD
exception!
If the EFER.SVME = 1 the system generates a #GP
exception!
The VMSAVE instruction microcode is able to read the real
value of the EFER.SVME register without being intercepted!
We can use the VMSAVE instruction to detect HVBR.
The VMSAVE in not the only one SVM instruction that can be
used for detection. Take a look at AMD manuals.
38. Counter-attack - I
If the rootkit set the VMCB to intercept the VMSAVE
instruction, it will not detect the attack because the system
will generate a exception before executing VMSAVE.
The rootkit can set the VMCB to intercept #GP
exceptions!
After a #GP exception intercept, the rootkit must verify it
the guest RIP is pointing to a VMSAVE instruction!
If the VMSAVE instruction is being executed and the guest
EFER.SVME = 0, it can now inject a #UD exception in the
guest.
39. #GP attack - II
The detection code must not allow the rootkit to detect the
VMSAVE instruction at the guest RIP.
We can use the Translation Lookaside Buffer to hide our
detection code.
Exactly before executing the VMSAVE instruction, the
detector will change the PTE of the detection code to make it
point to a fake page which will have another code that
generates a #GP exception.
When the rootkit intercepts the #GP, it will not be able to look
at the real code of RIP because the PTE is not showing the real
detection code page. The real address of the detection code is
inside the I-TLB and there is no way to access the contents of
the TLB cache.
40. Counter-attack II
The rootkit is not able to find the real detector page because it
is cached at ITLB. But it can detect if the PTE address of the
RIP is fake.
How?
The rootkit will write a 0xCC (int 0x3) opcode at the RIP address
and restart guest execution at the same RIP.
If the system generates a #BP exception, the page is not fake.
If the system generates a #GP again, the page is fake.
If the rootkit detects such attack, it can’t know what is the
correct exception that must be inject in the guest because the
hidden code can be any instruction able to generate a #GP
exception. If it injects a #UD exception it will be easily
detected!
41. Counter-attack II
What the rootkit can do now?
It knows that a exception must be generated.
It hooks the guest exception handlers.
Next, it unload the hypervisor and now it calls the intercepted
instruction again.
In this case, the instruction will generate the correct exception
that will be detected by the hooked exception handlers.
Now, the exception handler just needs to load the hypervisor
again!
Due to the #GP attack, every virtualization rootkit must
implement configure the VMCB to intercept #GP exceptions.
42. CPU bugs
It is possible to use CPU bugs to detect HVBR?
Yes, but it is not a reliable way to detect rootkits.
I found that the execution of the Address-Size Prefix (0x67)
opcode together with the VMSAVE instruction is aparently
able to freeze systems running hypervisors !
A detector which freezes the system is not very useful
outside of lab environments.
43. Credits
All the cool crypto research papers using cpu
microarchitecture based attacks.
Alexander Tereshkin, for the creation of the counter-
attacks against the #GP exception method to detect
Bluepill.
44. References
[1] J. Smith and R. Nair. Virtual Machines. Versatile platforms for systems and processes. Morgan Kaufmann, 2005.
[2]http://pferrie.tripod.com/papers/attacks.pdf
[3]http://pferrie.tripod.com/papers/attacks2.pdf
[4]http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html
[5]J. Shen and M. Lipasti. Modern Processor Design. Fundamentals of Superscalar processors. McGraw-Hill , 2005.
[6]O. Acuçmez, Ç. Koç and J. Seifert. On the power of simple branch prediction analysis. http://eprint.iacr.org/2006/351.pdf
[7] M. Milenkovic, A. Milenkovic and J. Kulick. Demystifying Intel Branch Predictors.
http://www.ece.wisc.edu/~wddd/2002/final/milenkovic.pdf
[8]http://blogs.zdnet.com/Ou/?p=297