SlideShare a Scribd company logo
1 of 84
Semzhu-Project
A self-made new world
of embedded hypervisors and attack detection methods
at CODE BLUE 2019
Yoshifumi Shu (YIwen Zhu)
Who am I
Yoshifumi Shu (YIwen Zhu)
● A 12th grade student
○ at SETAGAYA GAKUEN High School (世田谷学園高等学校)
● Interests
Embedded system
● Security Camp National Convention 2017 graduate
● SecHack365 2018 Excellent graduate
● Twitter : @envzhu
2
SecHack365 -The starting point of Semzhu-Project
➢ A Japanese U-25 security hackathon for one year
○ Conducted by NICT in order to train young security innovators
○ Includes seven times training camp
○ For student member, NICT covers all costs associated with participation.
○ Activity period: 2018/5 ~ 2019/3
4
What is the result when one high school student created an
embedded hypervisor and security functions ?
Today’s Topic
5
① Development of an embedded hypervisor
○ Background:
○ There are few embedded hypervisors which are easy to add one`s own
modification and to test its validity for individual interests.
○ Output:
○ Development of Semzhu-Visor, a simple embedded hypervisor for AArch64, which
runs on a CPU emulator.
Abstract (1/2)
6
② Research and development of security functions for embedded systems
○ Background: Few attack detection methods are applicable for embedded
systems.
■ Constraints on security functions for embedded systems:
● Support proprietary software
● Ensure real-time performance
○ Outputs: Development of two attack detection methods for embedded
systems, with a hypervisor.
■ AsROP
■ AsCOP
Abstract (2/2)
Agenda
➢ The core idea
➢ Development of Semzhu-Visor
➢ Raise a problem in previous research
➢ Propose “AsROP” and “AsCOP” as solutions
➢ Conclusion
7
The core idea of Semzhu-Project
What is an embedded system?
➢ A computer system which is dedicated to specific functions.
➢ e.g. camera, car, artificial satellite, MRI
➢ Often required …
➢ Small
➢ Power saving
➢ Real-time
9
What is a hypervisor?
➢ Technology and platform for virtualizing CPU and OS very fast.
10
Hypervisor
general purpose
OS
general purpose
OS
general purpose
OS
User Space User Space User Space
Physical CPU
What is an embedded hypervisor?
➢ A hypervisor specialized for embedded systems
11
Semzhu-Visor (Hypervisor)
general purpose
OS
Embedded OS① Embedded OS②
User Space User Space User Space
Physical CPU
Background
➢ The use and study of embedded hypervisors is active now.
○ e.g. ACRN, Xvisor, TOPPERS SafeG
12
Background
➢ The use and study of embedded hypervisors is active now.
○ e.g. ACRN, Xvisor, TOPPERS SafeG
➢ There are few hypervisors which are simple and small enough to add one`s own
modification and to test its validity easily.
13
Background
➢ The use and study of embedded hypervisors is active now.
○ e.g. ACRN, Xvisor, TOPPERS SafeG
➢ There are few hypervisors which are simple and small enough to add one`s own
modification and to test its validity easily.
➢ The start of study on embedded hypervisors is not long.
○ New ways of using hypervisors have the possibility to solve various problems in
computer systems.
○ Is it possible to develop new security functions with embedded hypervisors?
14
15
The origin of the name “Semzhu-Project”
Senju kannon,千手観音
● The thousand-armed Buddhist Goddess of Mercy
● Supports us behind by his 1,000 arms
■ Support something without being noticed but strongly.
Semzhu = Senju
The final goal of Semzhu-Project
Develop an embedded hypervisor which is easy to add
modifications
Propose unique ways of using a hypervisor
+
16
The current outputs of Semzhu-Project
Develop a simple embedded hypervisor, Semzhu-Visor
Develop new security functions with a hypervisor,
AsROP and AsCOP
+
17
Develop an embedded hypervisor, Semzhu-Visor
The Features of Semzhu-Visor (1/2)
➢ Development policy
○ Develop from scratch (i.e., also make a printf function)
○ Compiler independent
○ Shorter than 10,000 code of lines (Current: 7,000 lines)
○ Run on a CPU emulator
19
The Features of Semzhu-Visor (2/2)
● Specification
○ Type-1, bare-metal hypervisor
○ Linux and KOZOS(an embedded OS) can run as guest OS.
○ Ensure Real-Time Performance
○ Run on a modified QEMU
➢Target board:Raspberry Pi 3 (64bit/AArch64)
○ However, real machine operations are not conformed.
➢Development environment : Clang/LLVM
20
The Features of Semzhu-Visor (2/2)
● Specification
○ Type-1, bare-metal hypervisor
○ Linux and KOZOS(an embedded OS) can run as guest OS.
○ Ensure Real-Time Performance
○ Run on a modified QEMU
➢Target board:Raspberry Pi 3 (64bit/AArch64)
○ However, real machine operations are not conformed.
➢Development environment : Clang/LLVM
21
22
Fixed bugs and added the following functions to QEMU(*) so that the hypervisor runs.
● Added a function for hypervisors to cause exceptions virtually on guest VMs.
● Added a function for hypervisors to tarp the abort exceptions that is taken on guest VMs.
● Fixed a bug which causes an interrupt regardless of interrupt enable state of the guest VMs, when
trapping the interrupt and exception function is enabled.
● Fixed a bug that a part of the page table format in the hypervisor MMU cannot be interpreted
correctly.
Modified Qemu
* QEMU ・・・ a widely-used open source CPU emulator
The current functions of Semzhu-Visor
Implement only the minimum necessary functions as an embedded hypervisor
➢Scheduler for Guest VMs
➢Virtualization of Guest VM
○ Exclusive management of peripheral devices such as serial devices
○ Virtualization of interrupts and exceptions
○ Virtualization of timers
23
Realize these functions with only 7,000 lines of code!
General view of Semzhu-Visor
Semzhu-Visor (Hypervisor)
General-
Purpose OS
Embedded
OS①
Embedded
OS②
User Space User Space User Space
Targeted CPU (AArch64)
24
Modified Qemu (CPU emulator)
Host PC
Develop security functions for embedded
systems with a hypervisor
25
26
Threat Model
Assume that target embedded systems have …
DEP or any equivalent functions
● No memory is both writable and executable.
○ → Almost all embedded systems have this condition
● → It is impossible to attack by injecting any code.
● → First of all, attackers will attempt to capture control by code-reuse attacks
such as ROP and COP.
27
Threat Model
Assume that target embedded systems have …
DEP or any equivalent functions
● No memory is both writable and executable.
○ → Almost all embedded systems have this condition
● → It is impossible to attack by injecting codes.
● → First of all, attackers will attempt to capture control by code-reuse attacks such as
ROP and COP.
We need to detect ROP and COP.
28
Detection Target : ROP
➢ ROP(Return-oriented programming)
○ Attack by overwriting return address with an arbitrary address and executing
sequences of instructions that ends with a ret instruction (called “ROP gadget”).
○ Chaining multiple gadgets together enables attackers to make complicated attacks.
function1:
...
ldr x0, [x29, 28]
ldp x29, x30, [sp], #32
ret
nop
example of AArch64
29
Detection Target : COP
➢ COP(Call-oriented programming)
○ While ROP is based on “ret” instructions, COP is based on “indirect call”
instructions,
○ Not as frequent as ROP gadgets
○ COP gadgets have instructions with good operability such as argument operations.
function:
...
ldr x0, [sp, #8]
ldr x8, [sp, #16]
blr x8
…
example of AArch64
Widely used defense against ROP and COP
● ASLR(Address space layout randomization)
○ By randomize the location of stack and code, make difficult to make an attack.
○ However, attackers can bypass ASLR by Brute Force Attack or Information
Leakage.
■ ASLR doesn't become a solution to the root of the problem.
30
Previous research on attack detection
32
Existing defenses against ROP and COP fall in two categories.
① CFI (Control-flow integrity)
② Behavior-based Heuristics
Previous research on attack detection methods
① CFI(Control-Flow Integrity)
➢ Proposed in 2005. [1]
➢ The Core idea: Guard against flows of control not intended by the original
problems.
➢ Verify the correctness of the branch destination address of indirect jumps, indirect
calls, and returns from functions.
➢ Implementation :At compile time, insert verifying codes into target binaries.
33
[1] M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti. Control-flow integrity. In Proceedings of the
12th ACM conference on Computer and communications security, pages 340–353. ACM, 2005.
https://users.soe.ucsc.edu/~abadi/Papers/cfi-tissec-revised.pdf
① The Practical Problems of CFI(Control-Flow Integrity)
➢ Require the source code of the target program
➢ Cannot be applied to proprietary software.
➢ High overheads (25% ~ 50%)
→ To overcome these shortcomings, many researchers have tried to invent
practical variants of CFI since the inception of original CFI in 2005.
34
② Behavior-based Heuristics
➢ Use detection theories based on empirical laws of program behaviors.
➢ e.g., Judge whether it is a ROP attack by the length of branch distance by return
execution.
➢ In most cases…
➢ Implemented in kernel space such as a kernel driver.
➢ Work at run-time
35
② The Characteristics of Behavior-based Heuristics
➢ Can be applied to proprietary software.
➢ Less overhead
➢ In most cases, they are implemented with a kernel driver. So detection
processes are performed collectively at specific timings.
➢ Real-time performance is lost.
36
Raise problems in previous research
37
38
● Support proprietary software
○ Because embedded developers often use software whose source code is not available.
● Ensure Real-Time performance
[Discussion] The constraints on security functions for
embedded systems
Compare previous research with the constraints
➢ CFI
➢ Implemented in compiler layer
➢ Work both at compile time and at run time.
○ → cannot be applied to proprietary software
➢ Behavior-based Heuristics
○ Implemented in kernel spaces such as a kernel driver
○ Work at run time
○ Real-time performance will be lost.
39
Compare previous research with the constraints
➢ CFI
➢ Implemented in compiler layer
➢ Work both at compile time and at run time.
○ → cannot be applied to proprietary software
➢ Behavior-based Heuristics
○ Implemented in kernel spaces such as a kernel driver
○ Work at run time
○ Real-time performance will be lost.
Either methods does not meet all the constraints.
40
Raise a problem
There is no previous research meets all the constraints on security
functions for embedded systems.
Little research addresses security functions for embedded systems.
41
42
Is it possible to create security functions which is applicable
to embedded systems?
[Background] Motivation to develop security functions
So, how can we clear all the constraints ?
Compare previous research with the constraints
➢ CFI
➢ Implemented in compiler layer
➢ Work both at compile time and at run time.
○ Cannot be applied to proprietary software
➢ Behavior-based Heuristics
○ Implemented in kernel spaces such as a kernel driver
○ Work at run time
○ Real-time performance is lost.
44
Compare previous research with the constraints
➢ CFI
➢ Implemented in compiler layer
➢ Work both at compile time and at run time.
○ Cannot be applied to proprietary software
➢ Behavior-based Heuristics
○ Implemented in kernel spaces such as a kernel driver
○ Work at run time
○ Real-time performance is lost.
45
The characteristic of detection method and implementation method have a strong
correlation.
We need to devise a new implementation method which enables security functions
to meet all the constraints.
[Proposal] Implementation methods of security funtions
Extend CPU instructions Virtually with Hypervisors
46
[Mechanism] How to extend CPU instructions virtually
➢ No prevailed CPU architecture has any systems which enable to extend instructions.
47
[Mechanism] How to extend CPU instructions virtually
➢ No prevailed CPU architecture has any systems which enable to extend instructions.
➢ Realized by collaboration among multiple layers.
○ [During development] : Assign the target CPU instruction to an unused instruction.
○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception.
○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction
48
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
Convert
Hypervisor
GuestVM
During development
[Mechanism] How to extend CPU instructions virtually
➢ No prevailed CPU architecture has any systems which enable to extend instructions.
➢ Realized by collaboration among multiple layers.
○ [During development] : Assign the target CPU instruction to an unused instruction.
○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception.
○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction
49
Convert
Hypervisor
GuestVM
CPU layer
When an extended Instruction is executedfunction:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
An exception
occurs
[Mechanism] How to extend CPU instructions virtually
➢ No prevailed CPU architecture has any systems which enable to extend instructions.
➢ Realized by collaboration among multiple layers.
○ [During development] : Assign the target CPU instruction to an unused instruction.
○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception.
○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction
50
Convert
Hypervisor
GuestVM
An exception
occurs
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
An exception
occurs
CPU layer
When an extended Instruction is executed
[Mechanism] How to extend CPU instructions virtually
➢ No prevailed CPU architecture has any systems which enable to extend instructions.
➢ Realized by collaboration among multiple layers.
○ [During development] : Assign the target CPU instruction to an unused instruction.
○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception.
○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction
51
Convert
Hypervisor
GuestVM
An exception
occurs
Trap
Hypervisor layer
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
An exception
occurs
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
[Mechanism] How to extend CPU instructions virtually
➢ No prevailed CPU architecture has any systems which enable to extend instructions.
➢ Realized by collaboration among multiple layers.
○ [During development] : Assign the target CPU instruction to an unused instruction.
○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception.
○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction
52
Convert
An exception
occurs
Hypervisor
GuestVM
An exception
occurs
Trap
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
[Mechanism] How to extend CPU instructions virtually
➢ No prevailed CPU architecture has any systems which enable to extend instructions.
➢ Realized by collaboration among multiple layers.
○ [During development] : Assign the target CPU instruction to an unused instruction.
○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception.
○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction
○ * This time, I use hypervisor calls instead of unused instructions
53
Convert
An exception
occurs
Hypervisor
GuestVM
An exception
occurs
Trap
54
● Applicable to proprietary software.
● Available on other CPU architectures which has a hypervisor layer.
● [Important] Collaboration among multiple layers is available, which is difficult
on the real CPU layer.
○ Collaboration with static analysis tools, etc. (used for overhead reduction
techniques in AsROP, which I describe later)
[Discussion] The advantages of virtually extended CPU
instructions
55
[Discussion] The advantages of security functions with
hypervisors
In some implementations, …
● Applicable to kernel spaces
● Can ensure real-time performance
● Doesn’t require to modify guest OS
● Become easy for developers to utilize embedded OSs, by hypervisors taking
over security functions and reducing roles of guest embedded Oss.
56
What kind of virtually extended instructions works
as security functions?
57
Show security functions with virtually extended CPU instructions in the next slides.
● AsROP
● AsCOP
Security functions with virtually extended CPU instructions
AsROP,
an attack detection method against ROP
58
59
● The core theory
○ Based on ROPGuard(*).Normally, “ret” instructions returns back to an instruction following a
corresponding “bl“ instruction (called “call-preceded”).By checking this call-precedence, detect
ROP(in this talk, we call “call-precedence check”).
● Implementation
○ Add this call-precedence check process to the “ret” instruction
■ Called the “sec_ret” instruction
AsROP Mechanism
* Reference[2] ROPGuard I. Fratric. “ROPGuard: Runtime prevention of return-oriented programming
attacks.” 2012
function1:
...
3. bl function2
4. stur x0, [x29, #-16]
5. ...
6. ret
function2:
...
9. ret
CPU is expected to return
here from function 2
60
In normal software, the “ret” instruction is executed frequently. The CPU
overhead is very high. Therefore, AsROP reduces overhead by the following
techniques:
① Code ROP detection process in AArch64 assembly.
② Reduce the number of the “ret” instruction which apply ROP detection process.
The overhead reduction techniques of attack detection
methods against ROP
61
② Reduce the number of the “ret” instruction which apply ROP detection process.
● There some ret instructions which is impossible to abuse for attack.(“harmless ret
instruction”)
○ This time, AsROP defines ret instructions of functions that does not use any pointer and buffer
as “harmless ret instruction”.
● By working in cooperation with static analysis, execute “harmless ret instructions” as
they are without converting them to "sec_ret" instructions.
The overhead reduction techniques of attack detection
methods against ROP
62
② Reduce the number of the “ret” instruction which apply ROP detection process.
● There some ret instructions which is impossible to abuse for attack.(“harmless ret
instruction”)
○ This time, AsROP defines ret instructions of functions that does not use any pointer and buffer
as “harmless ret instruction”.
● By working in cooperation with static analysis, execute “harmless ret instructions” as
they are without converting them to "sec_ret" instructions.
→ With implementations in a kernel driver and in a compiler layer, it is difficult to
realize this idea.
But, with my implementation by virtually extended instruction, it is very easy to realize!
The overhead reduction techniques of attack detection
methods against ROP
63
「ROP is Still Dangerous: Breking Modern Defenses」[4]
● Mention the possibility for attack detection methods checking call-precedence check to be bypassed.
○ If an executable binary is 70KB or lager, there is usually a possibility to mount an attack only
with call-preceded ROP, i.e., the instruction before each gadget is a call instruction.
■ This is a peculiar story of x86, which is susceptible to ROP attack because of its variable length
instructions. So it is not applicable to other CPU architectures which are relatively difficult to attack with
ROP.
■ The attack method requires that ASLR is disabled
○ → It is very difficult to attack CPUs other than x86 with ASLR enabled and with call-preceded
ROP only.
○ → I think there is virtually no possibility to bypass AsROP with call-preceded ROP.
○ We need more research and verification in real applications !
[Supplementary Discussion]
The possibility that AsROP is bypassed
64
Execute script to display “Hello world” with mruby on guest OS, Linux.
➢ Compile to intermediate language + execute intermediate language
The Performance Evaluation of AsROP
Semzhu-Visor(Hypervisor)
Linux(Kernel Space)
mruby VM(User Space)
CPU(AArch64)
65
AsROP Performance Evaluation
Implementation CPU cycles in
total
CPU Overhead Number of
executions of
sec_ret
execution cycles
of sec_ret
(cycles per
execution)
Off AsROP
(Normal case)
45,026,014 0 0 0
Code in C language 80,580,786 35,554,772
(+79%)
113602 313
Code in assembly 59,887,536 14,861,522
(+33%)
113602 130
Code in assembly &
Apply the reducing
overhead techniques
56,433,742 11,407,728
(+25%)
83643 136
66
● One execution of detection process is sure to finish within 200 cycles.
○ Succeed in ensuring Real-Time performance
● Work without any modifying OS.
● CPU overhead is 25%
○ Not practical.
○ → AsROP has to reduce more the number of the “ret” instruction which apply
ROP detection process. (Future Work)
[Discussion] The Characteristic of AsROP
AsCOP,
an attack detection method against COP
68
● The core theory
○ Normally, an indirect call (in AArch64, the blr instruction) branches to a prologue of a function.
However, in a COP gadget is execution, indirect call branches to a halfway point of a function.
○ Detect COP by checking whether the branch destination is a prologue of a function in the
execution of the blr instruction.
● How can we check whether an address points to a prologue of a function?
○ List the addresses of the function from the execution binary in advance with a static analysis
tool.
○ Add a behavior that checks whether the branch destination is a function by matching the
branch destination address with the function list to blr instruction. (called “sec_blr instruction”)
AsCOP Mechanism
69
● Very high overhead.
● Real-time performance is lost.
● In some case, guest OS may need to be modified to apply functions to user
space.
○ When the memory space is isolated for each user application, the OS needs to
associate the function list with the corresponding user application.
The problems of function list matching
70
The solutions to the problems of function list matching
In most cases, we can instantly judge if an address points prologue of the function.
① Return address saving process check
○ In executable binaries generated by a compiler …
■ Return address saving process are placed at a specific position in functions.
■ And the instruction used to save is not used in other situation..
○ If this process is detected in a function,
■ we can say the address points to the prologue of the function.
② ret instruction precedence check
○ With exception, ret are always placed just before prologues of functions.
• For ret instructions in the middle of the function ,
• AsCOP rewrite it as a branch to the ret instruction at the end of the function.
○ If an instruction is just after a ret, its address also points to the prologue.
List only exceptional functions, which are implemented in assembly and not just after ret instructions.
○ → Successful in reducing function list (1953 → 17) & matching times (10791 → 0)
…
1: add sp, sp, #32
2: ret
function:
3: sub sp, sp, #32
4: stp x29, x30, [sp, #16]
…
71
Execute script to display “Hello world” with mruby on guest OS, Linux.
➢ Compile to intermediate language + execute intermediate language
The Performance Evaluation of AsCOP
Semzhu-Visor(Hypervisor)
Linux(Kernel Space)
mruby VM(User Space)
CPU(AArch64)
72
The Performance Evaluation of AsCOP
CPU cycles in total CPU Overhead Number of
executions of
sec_blr
execution cycles of
sec_blr
46,698,998 total 1,672,984(+3.7%) 10791 total 155 cycles per
execution
73
● CPU overhead was 3.7%; very practical !
● Ensuring Real-Time performance
● Don’t require to modify guest OS
[Evaluation] The Characteristic of AsCOP
74
● video:https://drive.google.com/open?id=1w2NKRa2cPYaSPgCjSM33F6U0jEh58oSo
● A ROP gadget will be conducted, after executing the user program.
○ /demo/rop.elf : not defensed /demo/anti_rop.elf : defensed by AsROP
○ Left side : Log of guest OS, Linux Right side : Log of Semzhu-Visor
DEMO AsROP
75
76
Log of Semzhu-VisorLog of Guest OS, Linux
AsROP detects a ROP.
And Semzhu-Visor causes an error exceptionon on
Guest VM virtually.
77
AsROP detects a ROP.
And Semzhu-Visor causes an error exceptionon on
Guest VM virtually.
An error exception occurring,
Guest OS terminates abnormally the
user program
Log of Semzhu-VisorLog of Guest OS, Linux
Time’s up !
78
79
● Make Semzhu-Visor more sophisticated and convenient.
● Through the project, I got new ideas and saw massive potential in hypervisor.
○ e.g.
○ The risk of a “ret” instruction being abused for attack might depend on the
place of that instruction. Optimizing behaviors according to the places might
decrease CPU overhead.
○ Changing behaviors of extended instructions randomly might make it difficult
to attack.
○ Also in other fields, I would like to seek the possibility of new ways of using
hypervisors.
Future work
80
● Developed Semzhu-Visor, a simple embedded hypervisor running on a CPU emulator.
● Proposed an implementation method with virtually extended CPU instruction.
● Devised overhead reduction techniques that take advantage of virtually extended CPU
instruction, and developed attack detection methods which is applicable to embedded
systems, AsROP and AsCOP.
■ Applicable to proprietary software.
■ Applicable to kernel spaces.
■ Don’t require to modify OS.
■ Ensure Real-Time performance.
○ For AsCOP, the performance experiment show that it is practical.
Summary
81
Semzhu-Project is the result of research and development in SecHack365,
a Japanese security hackathon conducted by NICT in order to train young
security innovators.
Acknowledgements
82
There is a new world of embedded hypervisors.
83
Even one ignorant high school student is able to create
a hypervisor and new security functions.
84
Why don’t you create your own new world of hypervisors?

More Related Content

What's hot

VM Forking and Hypervisor-based Fuzzing with Xen
VM Forking and Hypervisor-based Fuzzing with XenVM Forking and Hypervisor-based Fuzzing with Xen
VM Forking and Hypervisor-based Fuzzing with XenTamas K Lengyel
 
LAS16-504: Secure Storage updates in OP-TEE
LAS16-504: Secure Storage updates in OP-TEELAS16-504: Secure Storage updates in OP-TEE
LAS16-504: Secure Storage updates in OP-TEELinaro
 
BUD17-510: Power management in Linux together with secure firmware
BUD17-510: Power management in Linux together with secure firmwareBUD17-510: Power management in Linux together with secure firmware
BUD17-510: Power management in Linux together with secure firmwareLinaro
 
HKG18-219 - Threat Modeling for IoT
HKG18-219 - Threat Modeling for IoTHKG18-219 - Threat Modeling for IoT
HKG18-219 - Threat Modeling for IoTLinaro
 
SFO15-200: Linux kernel generic TEE driver
SFO15-200: Linux kernel generic TEE driverSFO15-200: Linux kernel generic TEE driver
SFO15-200: Linux kernel generic TEE driverLinaro
 
IoT exploitation: from memory corruption to code execution by Marco Romano
IoT exploitation: from memory corruption to code execution by Marco RomanoIoT exploitation: from memory corruption to code execution by Marco Romano
IoT exploitation: from memory corruption to code execution by Marco RomanoCodemotion
 
Embedded Fest 2019. Игорь Опанюк. Das U-boot v2019: a look under the hood
Embedded Fest 2019. Игорь Опанюк. Das U-boot v2019: a look under the hoodEmbedded Fest 2019. Игорь Опанюк. Das U-boot v2019: a look under the hood
Embedded Fest 2019. Игорь Опанюк. Das U-boot v2019: a look under the hoodEmbeddedFest
 
VM Forking and Hypervisor-based fuzzing
VM Forking and Hypervisor-based fuzzingVM Forking and Hypervisor-based fuzzing
VM Forking and Hypervisor-based fuzzingTamas K Lengyel
 
Las16 200 - firmware summit - ras what is it- why do we need it
Las16 200 - firmware summit - ras what is it- why do we need itLas16 200 - firmware summit - ras what is it- why do we need it
Las16 200 - firmware summit - ras what is it- why do we need itLinaro
 
SFO15-205: OP-TEE Content Decryption with Microsoft PlayReady on ARM
SFO15-205: OP-TEE Content Decryption with Microsoft PlayReady on ARMSFO15-205: OP-TEE Content Decryption with Microsoft PlayReady on ARM
SFO15-205: OP-TEE Content Decryption with Microsoft PlayReady on ARMLinaro
 
Virtual Machine Introspection with Xen on ARM
Virtual Machine Introspection with Xen on ARMVirtual Machine Introspection with Xen on ARM
Virtual Machine Introspection with Xen on ARMTamas K Lengyel
 
SGX Trusted Execution Environment
SGX Trusted Execution EnvironmentSGX Trusted Execution Environment
SGX Trusted Execution EnvironmentKernel TLV
 
LAS16-100K1: Welcome Keynote
LAS16-100K1: Welcome KeynoteLAS16-100K1: Welcome Keynote
LAS16-100K1: Welcome KeynoteLinaro
 
Lcu14 101- coresight overview
Lcu14 101- coresight overviewLcu14 101- coresight overview
Lcu14 101- coresight overviewLinaro
 
LAS16-405:OpenDataPlane: Software Defined Dataplane leader
LAS16-405:OpenDataPlane: Software Defined Dataplane leaderLAS16-405:OpenDataPlane: Software Defined Dataplane leader
LAS16-405:OpenDataPlane: Software Defined Dataplane leaderLinaro
 
Linux Conference Australia 2018 : Device Tree, past, present, future
Linux Conference Australia 2018 : Device Tree, past, present, futureLinux Conference Australia 2018 : Device Tree, past, present, future
Linux Conference Australia 2018 : Device Tree, past, present, futureNeil Armstrong
 
emips_overview_apr08
emips_overview_apr08emips_overview_apr08
emips_overview_apr08Neil Pittman
 
Elc Europe 2020 : u-boot- porting and maintaining a bootloader for a multimed...
Elc Europe 2020 : u-boot- porting and maintaining a bootloader for a multimed...Elc Europe 2020 : u-boot- porting and maintaining a bootloader for a multimed...
Elc Europe 2020 : u-boot- porting and maintaining a bootloader for a multimed...Neil Armstrong
 
LAS16-111: Easing Access to ARM TrustZone – OP-TEE and Raspberry Pi 3
LAS16-111: Easing Access to ARM TrustZone – OP-TEE and Raspberry Pi 3LAS16-111: Easing Access to ARM TrustZone – OP-TEE and Raspberry Pi 3
LAS16-111: Easing Access to ARM TrustZone – OP-TEE and Raspberry Pi 3Linaro
 

What's hot (20)

VM Forking and Hypervisor-based Fuzzing with Xen
VM Forking and Hypervisor-based Fuzzing with XenVM Forking and Hypervisor-based Fuzzing with Xen
VM Forking and Hypervisor-based Fuzzing with Xen
 
LAS16-504: Secure Storage updates in OP-TEE
LAS16-504: Secure Storage updates in OP-TEELAS16-504: Secure Storage updates in OP-TEE
LAS16-504: Secure Storage updates in OP-TEE
 
BUD17-510: Power management in Linux together with secure firmware
BUD17-510: Power management in Linux together with secure firmwareBUD17-510: Power management in Linux together with secure firmware
BUD17-510: Power management in Linux together with secure firmware
 
HKG18-219 - Threat Modeling for IoT
HKG18-219 - Threat Modeling for IoTHKG18-219 - Threat Modeling for IoT
HKG18-219 - Threat Modeling for IoT
 
SFO15-200: Linux kernel generic TEE driver
SFO15-200: Linux kernel generic TEE driverSFO15-200: Linux kernel generic TEE driver
SFO15-200: Linux kernel generic TEE driver
 
IoT exploitation: from memory corruption to code execution by Marco Romano
IoT exploitation: from memory corruption to code execution by Marco RomanoIoT exploitation: from memory corruption to code execution by Marco Romano
IoT exploitation: from memory corruption to code execution by Marco Romano
 
Embedded Fest 2019. Игорь Опанюк. Das U-boot v2019: a look under the hood
Embedded Fest 2019. Игорь Опанюк. Das U-boot v2019: a look under the hoodEmbedded Fest 2019. Игорь Опанюк. Das U-boot v2019: a look under the hood
Embedded Fest 2019. Игорь Опанюк. Das U-boot v2019: a look under the hood
 
VM Forking and Hypervisor-based fuzzing
VM Forking and Hypervisor-based fuzzingVM Forking and Hypervisor-based fuzzing
VM Forking and Hypervisor-based fuzzing
 
Las16 200 - firmware summit - ras what is it- why do we need it
Las16 200 - firmware summit - ras what is it- why do we need itLas16 200 - firmware summit - ras what is it- why do we need it
Las16 200 - firmware summit - ras what is it- why do we need it
 
SFO15-205: OP-TEE Content Decryption with Microsoft PlayReady on ARM
SFO15-205: OP-TEE Content Decryption with Microsoft PlayReady on ARMSFO15-205: OP-TEE Content Decryption with Microsoft PlayReady on ARM
SFO15-205: OP-TEE Content Decryption with Microsoft PlayReady on ARM
 
Virtual Machine Introspection with Xen on ARM
Virtual Machine Introspection with Xen on ARMVirtual Machine Introspection with Xen on ARM
Virtual Machine Introspection with Xen on ARM
 
SGX Trusted Execution Environment
SGX Trusted Execution EnvironmentSGX Trusted Execution Environment
SGX Trusted Execution Environment
 
FreeRTOS introduction
FreeRTOS introductionFreeRTOS introduction
FreeRTOS introduction
 
LAS16-100K1: Welcome Keynote
LAS16-100K1: Welcome KeynoteLAS16-100K1: Welcome Keynote
LAS16-100K1: Welcome Keynote
 
Lcu14 101- coresight overview
Lcu14 101- coresight overviewLcu14 101- coresight overview
Lcu14 101- coresight overview
 
LAS16-405:OpenDataPlane: Software Defined Dataplane leader
LAS16-405:OpenDataPlane: Software Defined Dataplane leaderLAS16-405:OpenDataPlane: Software Defined Dataplane leader
LAS16-405:OpenDataPlane: Software Defined Dataplane leader
 
Linux Conference Australia 2018 : Device Tree, past, present, future
Linux Conference Australia 2018 : Device Tree, past, present, futureLinux Conference Australia 2018 : Device Tree, past, present, future
Linux Conference Australia 2018 : Device Tree, past, present, future
 
emips_overview_apr08
emips_overview_apr08emips_overview_apr08
emips_overview_apr08
 
Elc Europe 2020 : u-boot- porting and maintaining a bootloader for a multimed...
Elc Europe 2020 : u-boot- porting and maintaining a bootloader for a multimed...Elc Europe 2020 : u-boot- porting and maintaining a bootloader for a multimed...
Elc Europe 2020 : u-boot- porting and maintaining a bootloader for a multimed...
 
LAS16-111: Easing Access to ARM TrustZone – OP-TEE and Raspberry Pi 3
LAS16-111: Easing Access to ARM TrustZone – OP-TEE and Raspberry Pi 3LAS16-111: Easing Access to ARM TrustZone – OP-TEE and Raspberry Pi 3
LAS16-111: Easing Access to ARM TrustZone – OP-TEE and Raspberry Pi 3
 

Similar to [CB19] Semzhu-Project – A self-made new world of embedded hypervisors and attack detection methods by Yoshifumi Shu (Yiwen Zhu)

Unikraft: Fast, Specialized Unikernels the Easy Way
Unikraft: Fast, Specialized Unikernels the Easy WayUnikraft: Fast, Specialized Unikernels the Easy Way
Unikraft: Fast, Specialized Unikernels the Easy WayScyllaDB
 
Heterogeneous multiprocessing on androd and i.mx7
Heterogeneous multiprocessing on androd and i.mx7Heterogeneous multiprocessing on androd and i.mx7
Heterogeneous multiprocessing on androd and i.mx7Kynetics
 
Embedded platform choices
Embedded platform choicesEmbedded platform choices
Embedded platform choicesTavish Naruka
 
XPDDS17: NoXS: Death to the XenStore - Filipe Manco, NEC
XPDDS17:  NoXS: Death to the XenStore - Filipe Manco, NECXPDDS17:  NoXS: Death to the XenStore - Filipe Manco, NEC
XPDDS17: NoXS: Death to the XenStore - Filipe Manco, NECThe Linux Foundation
 
DOST: Ceph in a security critical OpenStack cloud
DOST: Ceph in a security critical OpenStack cloudDOST: Ceph in a security critical OpenStack cloud
DOST: Ceph in a security critical OpenStack cloudDanny Al-Gaaf
 
BPF & Cilium - Turning Linux into a Microservices-aware Operating System
BPF  & Cilium - Turning Linux into a Microservices-aware Operating SystemBPF  & Cilium - Turning Linux into a Microservices-aware Operating System
BPF & Cilium - Turning Linux into a Microservices-aware Operating SystemThomas Graf
 
Linux 开源操作系统发展新趋势
Linux 开源操作系统发展新趋势Linux 开源操作系统发展新趋势
Linux 开源操作系统发展新趋势Anthony Wong
 
Quick and Easy Device Drivers for Embedded Linux Using UIO
Quick and Easy Device Drivers for Embedded Linux Using UIOQuick and Easy Device Drivers for Embedded Linux Using UIO
Quick and Easy Device Drivers for Embedded Linux Using UIOChris Simmonds
 
PuppetConf 2016: Why Network Automation Matters, and What You Can Do About It...
PuppetConf 2016: Why Network Automation Matters, and What You Can Do About It...PuppetConf 2016: Why Network Automation Matters, and What You Can Do About It...
PuppetConf 2016: Why Network Automation Matters, and What You Can Do About It...Puppet
 
[CONFidence 2016] Sławomir Kosowski - Introduction to iOS Application Securit...
[CONFidence 2016] Sławomir Kosowski - Introduction to iOS Application Securit...[CONFidence 2016] Sławomir Kosowski - Introduction to iOS Application Securit...
[CONFidence 2016] Sławomir Kosowski - Introduction to iOS Application Securit...PROIDEA
 
Kubernetes Deployments: A "Hands-off" Approach
Kubernetes Deployments: A "Hands-off" ApproachKubernetes Deployments: A "Hands-off" Approach
Kubernetes Deployments: A "Hands-off" ApproachRodrigo Reis
 
Introduction to iOS Penetration Testing
Introduction to iOS Penetration TestingIntroduction to iOS Penetration Testing
Introduction to iOS Penetration TestingOWASP
 
An In-Depth Look Into Microcontrollers
An In-Depth Look Into MicrocontrollersAn In-Depth Look Into Microcontrollers
An In-Depth Look Into MicrocontrollersICS
 
Getting Started with Node.js
Getting Started with Node.jsGetting Started with Node.js
Getting Started with Node.jsJustin Reock
 
Processor Verification Using Open Source Tools and the GCC Regression Test Suite
Processor Verification Using Open Source Tools and the GCC Regression Test SuiteProcessor Verification Using Open Source Tools and the GCC Regression Test Suite
Processor Verification Using Open Source Tools and the GCC Regression Test SuiteDVClub
 
Deploying Specter Desktop - Mechanism, not Policy
Deploying Specter Desktop - Mechanism, not PolicyDeploying Specter Desktop - Mechanism, not Policy
Deploying Specter Desktop - Mechanism, not Policyk9ert
 
Kernel Recipes 2018 - Zinc: minimal lightweight crypto API - Jason Donenfeld
Kernel Recipes 2018 - Zinc: minimal lightweight crypto API - Jason DonenfeldKernel Recipes 2018 - Zinc: minimal lightweight crypto API - Jason Donenfeld
Kernel Recipes 2018 - Zinc: minimal lightweight crypto API - Jason DonenfeldAnne Nicolas
 

Similar to [CB19] Semzhu-Project – A self-made new world of embedded hypervisors and attack detection methods by Yoshifumi Shu (Yiwen Zhu) (20)

Unikraft: Fast, Specialized Unikernels the Easy Way
Unikraft: Fast, Specialized Unikernels the Easy WayUnikraft: Fast, Specialized Unikernels the Easy Way
Unikraft: Fast, Specialized Unikernels the Easy Way
 
Heterogeneous multiprocessing on androd and i.mx7
Heterogeneous multiprocessing on androd and i.mx7Heterogeneous multiprocessing on androd and i.mx7
Heterogeneous multiprocessing on androd and i.mx7
 
Embedded platform choices
Embedded platform choicesEmbedded platform choices
Embedded platform choices
 
XPDDS17: NoXS: Death to the XenStore - Filipe Manco, NEC
XPDDS17:  NoXS: Death to the XenStore - Filipe Manco, NECXPDDS17:  NoXS: Death to the XenStore - Filipe Manco, NEC
XPDDS17: NoXS: Death to the XenStore - Filipe Manco, NEC
 
DOST: Ceph in a security critical OpenStack cloud
DOST: Ceph in a security critical OpenStack cloudDOST: Ceph in a security critical OpenStack cloud
DOST: Ceph in a security critical OpenStack cloud
 
BPF & Cilium - Turning Linux into a Microservices-aware Operating System
BPF  & Cilium - Turning Linux into a Microservices-aware Operating SystemBPF  & Cilium - Turning Linux into a Microservices-aware Operating System
BPF & Cilium - Turning Linux into a Microservices-aware Operating System
 
Linux 开源操作系统发展新趋势
Linux 开源操作系统发展新趋势Linux 开源操作系统发展新趋势
Linux 开源操作系统发展新趋势
 
Quick and Easy Device Drivers for Embedded Linux Using UIO
Quick and Easy Device Drivers for Embedded Linux Using UIOQuick and Easy Device Drivers for Embedded Linux Using UIO
Quick and Easy Device Drivers for Embedded Linux Using UIO
 
PuppetConf 2016: Why Network Automation Matters, and What You Can Do About It...
PuppetConf 2016: Why Network Automation Matters, and What You Can Do About It...PuppetConf 2016: Why Network Automation Matters, and What You Can Do About It...
PuppetConf 2016: Why Network Automation Matters, and What You Can Do About It...
 
[CONFidence 2016] Sławomir Kosowski - Introduction to iOS Application Securit...
[CONFidence 2016] Sławomir Kosowski - Introduction to iOS Application Securit...[CONFidence 2016] Sławomir Kosowski - Introduction to iOS Application Securit...
[CONFidence 2016] Sławomir Kosowski - Introduction to iOS Application Securit...
 
SnakeGX (full version)
SnakeGX (full version) SnakeGX (full version)
SnakeGX (full version)
 
Kubernetes Deployments: A "Hands-off" Approach
Kubernetes Deployments: A "Hands-off" ApproachKubernetes Deployments: A "Hands-off" Approach
Kubernetes Deployments: A "Hands-off" Approach
 
Introduction to iOS Penetration Testing
Introduction to iOS Penetration TestingIntroduction to iOS Penetration Testing
Introduction to iOS Penetration Testing
 
An In-Depth Look Into Microcontrollers
An In-Depth Look Into MicrocontrollersAn In-Depth Look Into Microcontrollers
An In-Depth Look Into Microcontrollers
 
HPC on OpenStack
HPC on OpenStackHPC on OpenStack
HPC on OpenStack
 
Getting Started with Node.js
Getting Started with Node.jsGetting Started with Node.js
Getting Started with Node.js
 
Vm final
Vm finalVm final
Vm final
 
Processor Verification Using Open Source Tools and the GCC Regression Test Suite
Processor Verification Using Open Source Tools and the GCC Regression Test SuiteProcessor Verification Using Open Source Tools and the GCC Regression Test Suite
Processor Verification Using Open Source Tools and the GCC Regression Test Suite
 
Deploying Specter Desktop - Mechanism, not Policy
Deploying Specter Desktop - Mechanism, not PolicyDeploying Specter Desktop - Mechanism, not Policy
Deploying Specter Desktop - Mechanism, not Policy
 
Kernel Recipes 2018 - Zinc: minimal lightweight crypto API - Jason Donenfeld
Kernel Recipes 2018 - Zinc: minimal lightweight crypto API - Jason DonenfeldKernel Recipes 2018 - Zinc: minimal lightweight crypto API - Jason Donenfeld
Kernel Recipes 2018 - Zinc: minimal lightweight crypto API - Jason Donenfeld
 

More from CODE BLUE

[cb22] Hayabusa Threat Hunting and Fast Forensics in Windows environments fo...
[cb22] Hayabusa  Threat Hunting and Fast Forensics in Windows environments fo...[cb22] Hayabusa  Threat Hunting and Fast Forensics in Windows environments fo...
[cb22] Hayabusa Threat Hunting and Fast Forensics in Windows environments fo...CODE BLUE
 
[cb22] Tales of 5G hacking by Karsten Nohl
[cb22] Tales of 5G hacking by Karsten Nohl[cb22] Tales of 5G hacking by Karsten Nohl
[cb22] Tales of 5G hacking by Karsten NohlCODE BLUE
 
[cb22] Your Printer is not your Printer ! - Hacking Printers at Pwn2Own by A...
[cb22]  Your Printer is not your Printer ! - Hacking Printers at Pwn2Own by A...[cb22]  Your Printer is not your Printer ! - Hacking Printers at Pwn2Own by A...
[cb22] Your Printer is not your Printer ! - Hacking Printers at Pwn2Own by A...CODE BLUE
 
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...CODE BLUE
 
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(4) by 板橋 博之
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(4) by 板橋 博之[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(4) by 板橋 博之
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(4) by 板橋 博之CODE BLUE
 
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...CODE BLUE
 
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(3) by Lorenzo Pupillo
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(3) by Lorenzo Pupillo[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(3) by Lorenzo Pupillo
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(3) by Lorenzo PupilloCODE BLUE
 
[cb22] ”The Present and Future of Coordinated Vulnerability Disclosure” Inte...
[cb22]  ”The Present and Future of Coordinated Vulnerability Disclosure” Inte...[cb22]  ”The Present and Future of Coordinated Vulnerability Disclosure” Inte...
[cb22] ”The Present and Future of Coordinated Vulnerability Disclosure” Inte...CODE BLUE
 
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(2)by Allan Friedman
[cb22]  「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(2)by Allan Friedman [cb22]  「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(2)by Allan Friedman
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(2)by Allan Friedman CODE BLUE
 
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...CODE BLUE
 
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション (1)by 高橋 郁夫
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション (1)by  高橋 郁夫[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション (1)by  高橋 郁夫
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション (1)by 高橋 郁夫CODE BLUE
 
[cb22] Are Embedded Devices Ready for ROP Attacks? -ROP verification for low-...
[cb22] Are Embedded Devices Ready for ROP Attacks? -ROP verification for low-...[cb22] Are Embedded Devices Ready for ROP Attacks? -ROP verification for low-...
[cb22] Are Embedded Devices Ready for ROP Attacks? -ROP verification for low-...CODE BLUE
 
[cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka
[cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka [cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka
[cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka CODE BLUE
 
[cb22] Under the hood of Wslink’s multilayered virtual machine en by Vladisla...
[cb22] Under the hood of Wslink’s multilayered virtual machine en by Vladisla...[cb22] Under the hood of Wslink’s multilayered virtual machine en by Vladisla...
[cb22] Under the hood of Wslink’s multilayered virtual machine en by Vladisla...CODE BLUE
 
[cb22] CloudDragon’s Credential Factory is Powering Up Its Espionage Activiti...
[cb22] CloudDragon’s Credential Factory is Powering Up Its Espionage Activiti...[cb22] CloudDragon’s Credential Factory is Powering Up Its Espionage Activiti...
[cb22] CloudDragon’s Credential Factory is Powering Up Its Espionage Activiti...CODE BLUE
 
[cb22] From Parroting to Echoing: The Evolution of China’s Bots-Driven Info...
[cb22]  From Parroting to Echoing:  The Evolution of China’s Bots-Driven Info...[cb22]  From Parroting to Echoing:  The Evolution of China’s Bots-Driven Info...
[cb22] From Parroting to Echoing: The Evolution of China’s Bots-Driven Info...CODE BLUE
 
[cb22] Who is the Mal-Gopher? - Implementation and Evaluation of “gimpfuzzy”...
[cb22]  Who is the Mal-Gopher? - Implementation and Evaluation of “gimpfuzzy”...[cb22]  Who is the Mal-Gopher? - Implementation and Evaluation of “gimpfuzzy”...
[cb22] Who is the Mal-Gopher? - Implementation and Evaluation of “gimpfuzzy”...CODE BLUE
 
[cb22] Mal-gopherとは?Go系マルウェアの分類のためのgimpfuzzy実装と評価 by 澤部 祐太, 甘粕 伸幸, 野村 和也
[cb22] Mal-gopherとは?Go系マルウェアの分類のためのgimpfuzzy実装と評価 by 澤部 祐太, 甘粕 伸幸, 野村 和也[cb22] Mal-gopherとは?Go系マルウェアの分類のためのgimpfuzzy実装と評価 by 澤部 祐太, 甘粕 伸幸, 野村 和也
[cb22] Mal-gopherとは?Go系マルウェアの分類のためのgimpfuzzy実装と評価 by 澤部 祐太, 甘粕 伸幸, 野村 和也CODE BLUE
 
[cb22] Tracking the Entire Iceberg - Long-term APT Malware C2 Protocol Emulat...
[cb22] Tracking the Entire Iceberg - Long-term APT Malware C2 Protocol Emulat...[cb22] Tracking the Entire Iceberg - Long-term APT Malware C2 Protocol Emulat...
[cb22] Tracking the Entire Iceberg - Long-term APT Malware C2 Protocol Emulat...CODE BLUE
 
[cb22] Fight Against Malware Development Life Cycle by Shusei Tomonaga and Yu...
[cb22] Fight Against Malware Development Life Cycle by Shusei Tomonaga and Yu...[cb22] Fight Against Malware Development Life Cycle by Shusei Tomonaga and Yu...
[cb22] Fight Against Malware Development Life Cycle by Shusei Tomonaga and Yu...CODE BLUE
 

More from CODE BLUE (20)

[cb22] Hayabusa Threat Hunting and Fast Forensics in Windows environments fo...
[cb22] Hayabusa  Threat Hunting and Fast Forensics in Windows environments fo...[cb22] Hayabusa  Threat Hunting and Fast Forensics in Windows environments fo...
[cb22] Hayabusa Threat Hunting and Fast Forensics in Windows environments fo...
 
[cb22] Tales of 5G hacking by Karsten Nohl
[cb22] Tales of 5G hacking by Karsten Nohl[cb22] Tales of 5G hacking by Karsten Nohl
[cb22] Tales of 5G hacking by Karsten Nohl
 
[cb22] Your Printer is not your Printer ! - Hacking Printers at Pwn2Own by A...
[cb22]  Your Printer is not your Printer ! - Hacking Printers at Pwn2Own by A...[cb22]  Your Printer is not your Printer ! - Hacking Printers at Pwn2Own by A...
[cb22] Your Printer is not your Printer ! - Hacking Printers at Pwn2Own by A...
 
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
 
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(4) by 板橋 博之
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(4) by 板橋 博之[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(4) by 板橋 博之
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(4) by 板橋 博之
 
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
 
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(3) by Lorenzo Pupillo
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(3) by Lorenzo Pupillo[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(3) by Lorenzo Pupillo
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(3) by Lorenzo Pupillo
 
[cb22] ”The Present and Future of Coordinated Vulnerability Disclosure” Inte...
[cb22]  ”The Present and Future of Coordinated Vulnerability Disclosure” Inte...[cb22]  ”The Present and Future of Coordinated Vulnerability Disclosure” Inte...
[cb22] ”The Present and Future of Coordinated Vulnerability Disclosure” Inte...
 
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(2)by Allan Friedman
[cb22]  「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(2)by Allan Friedman [cb22]  「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(2)by Allan Friedman
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション(2)by Allan Friedman
 
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
[cb22] "The Present and Future of Coordinated Vulnerability Disclosure" Inter...
 
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション (1)by 高橋 郁夫
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション (1)by  高橋 郁夫[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション (1)by  高橋 郁夫
[cb22] 「協調された脆弱性開示の現在と未来」国際的なパネルディスカッション (1)by 高橋 郁夫
 
[cb22] Are Embedded Devices Ready for ROP Attacks? -ROP verification for low-...
[cb22] Are Embedded Devices Ready for ROP Attacks? -ROP verification for low-...[cb22] Are Embedded Devices Ready for ROP Attacks? -ROP verification for low-...
[cb22] Are Embedded Devices Ready for ROP Attacks? -ROP verification for low-...
 
[cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka
[cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka [cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka
[cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka
 
[cb22] Under the hood of Wslink’s multilayered virtual machine en by Vladisla...
[cb22] Under the hood of Wslink’s multilayered virtual machine en by Vladisla...[cb22] Under the hood of Wslink’s multilayered virtual machine en by Vladisla...
[cb22] Under the hood of Wslink’s multilayered virtual machine en by Vladisla...
 
[cb22] CloudDragon’s Credential Factory is Powering Up Its Espionage Activiti...
[cb22] CloudDragon’s Credential Factory is Powering Up Its Espionage Activiti...[cb22] CloudDragon’s Credential Factory is Powering Up Its Espionage Activiti...
[cb22] CloudDragon’s Credential Factory is Powering Up Its Espionage Activiti...
 
[cb22] From Parroting to Echoing: The Evolution of China’s Bots-Driven Info...
[cb22]  From Parroting to Echoing:  The Evolution of China’s Bots-Driven Info...[cb22]  From Parroting to Echoing:  The Evolution of China’s Bots-Driven Info...
[cb22] From Parroting to Echoing: The Evolution of China’s Bots-Driven Info...
 
[cb22] Who is the Mal-Gopher? - Implementation and Evaluation of “gimpfuzzy”...
[cb22]  Who is the Mal-Gopher? - Implementation and Evaluation of “gimpfuzzy”...[cb22]  Who is the Mal-Gopher? - Implementation and Evaluation of “gimpfuzzy”...
[cb22] Who is the Mal-Gopher? - Implementation and Evaluation of “gimpfuzzy”...
 
[cb22] Mal-gopherとは?Go系マルウェアの分類のためのgimpfuzzy実装と評価 by 澤部 祐太, 甘粕 伸幸, 野村 和也
[cb22] Mal-gopherとは?Go系マルウェアの分類のためのgimpfuzzy実装と評価 by 澤部 祐太, 甘粕 伸幸, 野村 和也[cb22] Mal-gopherとは?Go系マルウェアの分類のためのgimpfuzzy実装と評価 by 澤部 祐太, 甘粕 伸幸, 野村 和也
[cb22] Mal-gopherとは?Go系マルウェアの分類のためのgimpfuzzy実装と評価 by 澤部 祐太, 甘粕 伸幸, 野村 和也
 
[cb22] Tracking the Entire Iceberg - Long-term APT Malware C2 Protocol Emulat...
[cb22] Tracking the Entire Iceberg - Long-term APT Malware C2 Protocol Emulat...[cb22] Tracking the Entire Iceberg - Long-term APT Malware C2 Protocol Emulat...
[cb22] Tracking the Entire Iceberg - Long-term APT Malware C2 Protocol Emulat...
 
[cb22] Fight Against Malware Development Life Cycle by Shusei Tomonaga and Yu...
[cb22] Fight Against Malware Development Life Cycle by Shusei Tomonaga and Yu...[cb22] Fight Against Malware Development Life Cycle by Shusei Tomonaga and Yu...
[cb22] Fight Against Malware Development Life Cycle by Shusei Tomonaga and Yu...
 

Recently uploaded

ISO 25964-1Working Group ISO/TC 46/SC 9/WG 8
ISO 25964-1Working Group ISO/TC 46/SC 9/WG 8ISO 25964-1Working Group ISO/TC 46/SC 9/WG 8
ISO 25964-1Working Group ISO/TC 46/SC 9/WG 8Access Innovations, Inc.
 
The Real Story Of Project Manager/Scrum Master From Where It Came?!
The Real Story Of Project Manager/Scrum Master From Where It Came?!The Real Story Of Project Manager/Scrum Master From Where It Came?!
The Real Story Of Project Manager/Scrum Master From Where It Came?!Loay Mohamed Ibrahim Aly
 
Machine learning workshop, CZU Prague 2024
Machine learning workshop, CZU Prague 2024Machine learning workshop, CZU Prague 2024
Machine learning workshop, CZU Prague 2024Gokulks007
 
Burning Issue presentation of Zhazgul N. , Cycle 54
Burning Issue presentation of Zhazgul N. , Cycle 54Burning Issue presentation of Zhazgul N. , Cycle 54
Burning Issue presentation of Zhazgul N. , Cycle 54ZhazgulNurdinova
 
Communication Accommodation Theory Kaylyn Benton.pptx
Communication Accommodation Theory Kaylyn Benton.pptxCommunication Accommodation Theory Kaylyn Benton.pptx
Communication Accommodation Theory Kaylyn Benton.pptxkb31670
 
Juan Pablo Sugiura - eCommerce Day Bolivia 2024
Juan Pablo Sugiura - eCommerce Day Bolivia 2024Juan Pablo Sugiura - eCommerce Day Bolivia 2024
Juan Pablo Sugiura - eCommerce Day Bolivia 2024eCommerce Institute
 
Dynamics of Professional Presentationpdf
Dynamics of Professional PresentationpdfDynamics of Professional Presentationpdf
Dynamics of Professional Presentationpdfravleel42
 
Communication Accommodation Theory Kaylyn Benton.pptx
Communication Accommodation Theory Kaylyn Benton.pptxCommunication Accommodation Theory Kaylyn Benton.pptx
Communication Accommodation Theory Kaylyn Benton.pptxkb31670
 

Recently uploaded (8)

ISO 25964-1Working Group ISO/TC 46/SC 9/WG 8
ISO 25964-1Working Group ISO/TC 46/SC 9/WG 8ISO 25964-1Working Group ISO/TC 46/SC 9/WG 8
ISO 25964-1Working Group ISO/TC 46/SC 9/WG 8
 
The Real Story Of Project Manager/Scrum Master From Where It Came?!
The Real Story Of Project Manager/Scrum Master From Where It Came?!The Real Story Of Project Manager/Scrum Master From Where It Came?!
The Real Story Of Project Manager/Scrum Master From Where It Came?!
 
Machine learning workshop, CZU Prague 2024
Machine learning workshop, CZU Prague 2024Machine learning workshop, CZU Prague 2024
Machine learning workshop, CZU Prague 2024
 
Burning Issue presentation of Zhazgul N. , Cycle 54
Burning Issue presentation of Zhazgul N. , Cycle 54Burning Issue presentation of Zhazgul N. , Cycle 54
Burning Issue presentation of Zhazgul N. , Cycle 54
 
Communication Accommodation Theory Kaylyn Benton.pptx
Communication Accommodation Theory Kaylyn Benton.pptxCommunication Accommodation Theory Kaylyn Benton.pptx
Communication Accommodation Theory Kaylyn Benton.pptx
 
Juan Pablo Sugiura - eCommerce Day Bolivia 2024
Juan Pablo Sugiura - eCommerce Day Bolivia 2024Juan Pablo Sugiura - eCommerce Day Bolivia 2024
Juan Pablo Sugiura - eCommerce Day Bolivia 2024
 
Dynamics of Professional Presentationpdf
Dynamics of Professional PresentationpdfDynamics of Professional Presentationpdf
Dynamics of Professional Presentationpdf
 
Communication Accommodation Theory Kaylyn Benton.pptx
Communication Accommodation Theory Kaylyn Benton.pptxCommunication Accommodation Theory Kaylyn Benton.pptx
Communication Accommodation Theory Kaylyn Benton.pptx
 

[CB19] Semzhu-Project – A self-made new world of embedded hypervisors and attack detection methods by Yoshifumi Shu (Yiwen Zhu)

  • 1. Semzhu-Project A self-made new world of embedded hypervisors and attack detection methods at CODE BLUE 2019 Yoshifumi Shu (YIwen Zhu)
  • 2. Who am I Yoshifumi Shu (YIwen Zhu) ● A 12th grade student ○ at SETAGAYA GAKUEN High School (世田谷学園高等学校) ● Interests Embedded system ● Security Camp National Convention 2017 graduate ● SecHack365 2018 Excellent graduate ● Twitter : @envzhu 2
  • 3. SecHack365 -The starting point of Semzhu-Project ➢ A Japanese U-25 security hackathon for one year ○ Conducted by NICT in order to train young security innovators ○ Includes seven times training camp ○ For student member, NICT covers all costs associated with participation. ○ Activity period: 2018/5 ~ 2019/3
  • 4. 4 What is the result when one high school student created an embedded hypervisor and security functions ? Today’s Topic
  • 5. 5 ① Development of an embedded hypervisor ○ Background: ○ There are few embedded hypervisors which are easy to add one`s own modification and to test its validity for individual interests. ○ Output: ○ Development of Semzhu-Visor, a simple embedded hypervisor for AArch64, which runs on a CPU emulator. Abstract (1/2)
  • 6. 6 ② Research and development of security functions for embedded systems ○ Background: Few attack detection methods are applicable for embedded systems. ■ Constraints on security functions for embedded systems: ● Support proprietary software ● Ensure real-time performance ○ Outputs: Development of two attack detection methods for embedded systems, with a hypervisor. ■ AsROP ■ AsCOP Abstract (2/2)
  • 7. Agenda ➢ The core idea ➢ Development of Semzhu-Visor ➢ Raise a problem in previous research ➢ Propose “AsROP” and “AsCOP” as solutions ➢ Conclusion 7
  • 8. The core idea of Semzhu-Project
  • 9. What is an embedded system? ➢ A computer system which is dedicated to specific functions. ➢ e.g. camera, car, artificial satellite, MRI ➢ Often required … ➢ Small ➢ Power saving ➢ Real-time 9
  • 10. What is a hypervisor? ➢ Technology and platform for virtualizing CPU and OS very fast. 10 Hypervisor general purpose OS general purpose OS general purpose OS User Space User Space User Space Physical CPU
  • 11. What is an embedded hypervisor? ➢ A hypervisor specialized for embedded systems 11 Semzhu-Visor (Hypervisor) general purpose OS Embedded OS① Embedded OS② User Space User Space User Space Physical CPU
  • 12. Background ➢ The use and study of embedded hypervisors is active now. ○ e.g. ACRN, Xvisor, TOPPERS SafeG 12
  • 13. Background ➢ The use and study of embedded hypervisors is active now. ○ e.g. ACRN, Xvisor, TOPPERS SafeG ➢ There are few hypervisors which are simple and small enough to add one`s own modification and to test its validity easily. 13
  • 14. Background ➢ The use and study of embedded hypervisors is active now. ○ e.g. ACRN, Xvisor, TOPPERS SafeG ➢ There are few hypervisors which are simple and small enough to add one`s own modification and to test its validity easily. ➢ The start of study on embedded hypervisors is not long. ○ New ways of using hypervisors have the possibility to solve various problems in computer systems. ○ Is it possible to develop new security functions with embedded hypervisors? 14
  • 15. 15 The origin of the name “Semzhu-Project” Senju kannon,千手観音 ● The thousand-armed Buddhist Goddess of Mercy ● Supports us behind by his 1,000 arms ■ Support something without being noticed but strongly. Semzhu = Senju
  • 16. The final goal of Semzhu-Project Develop an embedded hypervisor which is easy to add modifications Propose unique ways of using a hypervisor + 16
  • 17. The current outputs of Semzhu-Project Develop a simple embedded hypervisor, Semzhu-Visor Develop new security functions with a hypervisor, AsROP and AsCOP + 17
  • 18. Develop an embedded hypervisor, Semzhu-Visor
  • 19. The Features of Semzhu-Visor (1/2) ➢ Development policy ○ Develop from scratch (i.e., also make a printf function) ○ Compiler independent ○ Shorter than 10,000 code of lines (Current: 7,000 lines) ○ Run on a CPU emulator 19
  • 20. The Features of Semzhu-Visor (2/2) ● Specification ○ Type-1, bare-metal hypervisor ○ Linux and KOZOS(an embedded OS) can run as guest OS. ○ Ensure Real-Time Performance ○ Run on a modified QEMU ➢Target board:Raspberry Pi 3 (64bit/AArch64) ○ However, real machine operations are not conformed. ➢Development environment : Clang/LLVM 20
  • 21. The Features of Semzhu-Visor (2/2) ● Specification ○ Type-1, bare-metal hypervisor ○ Linux and KOZOS(an embedded OS) can run as guest OS. ○ Ensure Real-Time Performance ○ Run on a modified QEMU ➢Target board:Raspberry Pi 3 (64bit/AArch64) ○ However, real machine operations are not conformed. ➢Development environment : Clang/LLVM 21
  • 22. 22 Fixed bugs and added the following functions to QEMU(*) so that the hypervisor runs. ● Added a function for hypervisors to cause exceptions virtually on guest VMs. ● Added a function for hypervisors to tarp the abort exceptions that is taken on guest VMs. ● Fixed a bug which causes an interrupt regardless of interrupt enable state of the guest VMs, when trapping the interrupt and exception function is enabled. ● Fixed a bug that a part of the page table format in the hypervisor MMU cannot be interpreted correctly. Modified Qemu * QEMU ・・・ a widely-used open source CPU emulator
  • 23. The current functions of Semzhu-Visor Implement only the minimum necessary functions as an embedded hypervisor ➢Scheduler for Guest VMs ➢Virtualization of Guest VM ○ Exclusive management of peripheral devices such as serial devices ○ Virtualization of interrupts and exceptions ○ Virtualization of timers 23 Realize these functions with only 7,000 lines of code!
  • 24. General view of Semzhu-Visor Semzhu-Visor (Hypervisor) General- Purpose OS Embedded OS① Embedded OS② User Space User Space User Space Targeted CPU (AArch64) 24 Modified Qemu (CPU emulator) Host PC
  • 25. Develop security functions for embedded systems with a hypervisor 25
  • 26. 26 Threat Model Assume that target embedded systems have … DEP or any equivalent functions ● No memory is both writable and executable. ○ → Almost all embedded systems have this condition ● → It is impossible to attack by injecting any code. ● → First of all, attackers will attempt to capture control by code-reuse attacks such as ROP and COP.
  • 27. 27 Threat Model Assume that target embedded systems have … DEP or any equivalent functions ● No memory is both writable and executable. ○ → Almost all embedded systems have this condition ● → It is impossible to attack by injecting codes. ● → First of all, attackers will attempt to capture control by code-reuse attacks such as ROP and COP. We need to detect ROP and COP.
  • 28. 28 Detection Target : ROP ➢ ROP(Return-oriented programming) ○ Attack by overwriting return address with an arbitrary address and executing sequences of instructions that ends with a ret instruction (called “ROP gadget”). ○ Chaining multiple gadgets together enables attackers to make complicated attacks. function1: ... ldr x0, [x29, 28] ldp x29, x30, [sp], #32 ret nop example of AArch64
  • 29. 29 Detection Target : COP ➢ COP(Call-oriented programming) ○ While ROP is based on “ret” instructions, COP is based on “indirect call” instructions, ○ Not as frequent as ROP gadgets ○ COP gadgets have instructions with good operability such as argument operations. function: ... ldr x0, [sp, #8] ldr x8, [sp, #16] blr x8 … example of AArch64
  • 30. Widely used defense against ROP and COP ● ASLR(Address space layout randomization) ○ By randomize the location of stack and code, make difficult to make an attack. ○ However, attackers can bypass ASLR by Brute Force Attack or Information Leakage. ■ ASLR doesn't become a solution to the root of the problem. 30
  • 31. Previous research on attack detection
  • 32. 32 Existing defenses against ROP and COP fall in two categories. ① CFI (Control-flow integrity) ② Behavior-based Heuristics Previous research on attack detection methods
  • 33. ① CFI(Control-Flow Integrity) ➢ Proposed in 2005. [1] ➢ The Core idea: Guard against flows of control not intended by the original problems. ➢ Verify the correctness of the branch destination address of indirect jumps, indirect calls, and returns from functions. ➢ Implementation :At compile time, insert verifying codes into target binaries. 33 [1] M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti. Control-flow integrity. In Proceedings of the 12th ACM conference on Computer and communications security, pages 340–353. ACM, 2005. https://users.soe.ucsc.edu/~abadi/Papers/cfi-tissec-revised.pdf
  • 34. ① The Practical Problems of CFI(Control-Flow Integrity) ➢ Require the source code of the target program ➢ Cannot be applied to proprietary software. ➢ High overheads (25% ~ 50%) → To overcome these shortcomings, many researchers have tried to invent practical variants of CFI since the inception of original CFI in 2005. 34
  • 35. ② Behavior-based Heuristics ➢ Use detection theories based on empirical laws of program behaviors. ➢ e.g., Judge whether it is a ROP attack by the length of branch distance by return execution. ➢ In most cases… ➢ Implemented in kernel space such as a kernel driver. ➢ Work at run-time 35
  • 36. ② The Characteristics of Behavior-based Heuristics ➢ Can be applied to proprietary software. ➢ Less overhead ➢ In most cases, they are implemented with a kernel driver. So detection processes are performed collectively at specific timings. ➢ Real-time performance is lost. 36
  • 37. Raise problems in previous research 37
  • 38. 38 ● Support proprietary software ○ Because embedded developers often use software whose source code is not available. ● Ensure Real-Time performance [Discussion] The constraints on security functions for embedded systems
  • 39. Compare previous research with the constraints ➢ CFI ➢ Implemented in compiler layer ➢ Work both at compile time and at run time. ○ → cannot be applied to proprietary software ➢ Behavior-based Heuristics ○ Implemented in kernel spaces such as a kernel driver ○ Work at run time ○ Real-time performance will be lost. 39
  • 40. Compare previous research with the constraints ➢ CFI ➢ Implemented in compiler layer ➢ Work both at compile time and at run time. ○ → cannot be applied to proprietary software ➢ Behavior-based Heuristics ○ Implemented in kernel spaces such as a kernel driver ○ Work at run time ○ Real-time performance will be lost. Either methods does not meet all the constraints. 40
  • 41. Raise a problem There is no previous research meets all the constraints on security functions for embedded systems. Little research addresses security functions for embedded systems. 41
  • 42. 42 Is it possible to create security functions which is applicable to embedded systems? [Background] Motivation to develop security functions
  • 43. So, how can we clear all the constraints ?
  • 44. Compare previous research with the constraints ➢ CFI ➢ Implemented in compiler layer ➢ Work both at compile time and at run time. ○ Cannot be applied to proprietary software ➢ Behavior-based Heuristics ○ Implemented in kernel spaces such as a kernel driver ○ Work at run time ○ Real-time performance is lost. 44
  • 45. Compare previous research with the constraints ➢ CFI ➢ Implemented in compiler layer ➢ Work both at compile time and at run time. ○ Cannot be applied to proprietary software ➢ Behavior-based Heuristics ○ Implemented in kernel spaces such as a kernel driver ○ Work at run time ○ Real-time performance is lost. 45 The characteristic of detection method and implementation method have a strong correlation. We need to devise a new implementation method which enables security functions to meet all the constraints.
  • 46. [Proposal] Implementation methods of security funtions Extend CPU instructions Virtually with Hypervisors 46
  • 47. [Mechanism] How to extend CPU instructions virtually ➢ No prevailed CPU architecture has any systems which enable to extend instructions. 47
  • 48. [Mechanism] How to extend CPU instructions virtually ➢ No prevailed CPU architecture has any systems which enable to extend instructions. ➢ Realized by collaboration among multiple layers. ○ [During development] : Assign the target CPU instruction to an unused instruction. ○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception. ○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction 48 function: sub sp, sp, #32 stp x29, x30, [sp, #16] (省略) ldp x29, x30, [sp, #16] add sp, sp, #32 ret nop function: sub sp, sp, #32 stp x29, x30, [sp, #16] (省略) ldp x29, x30, [sp, #16] add sp, sp, #32 sec_ret nop Convert Hypervisor GuestVM During development
  • 49. [Mechanism] How to extend CPU instructions virtually ➢ No prevailed CPU architecture has any systems which enable to extend instructions. ➢ Realized by collaboration among multiple layers. ○ [During development] : Assign the target CPU instruction to an unused instruction. ○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception. ○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction 49 Convert Hypervisor GuestVM CPU layer When an extended Instruction is executedfunction: sub sp, sp, #32 stp x29, x30, [sp, #16] (省略) ldp x29, x30, [sp, #16] add sp, sp, #32 ret nop function: sub sp, sp, #32 stp x29, x30, [sp, #16] (省略) ldp x29, x30, [sp, #16] add sp, sp, #32 sec_ret nop An exception occurs
  • 50. [Mechanism] How to extend CPU instructions virtually ➢ No prevailed CPU architecture has any systems which enable to extend instructions. ➢ Realized by collaboration among multiple layers. ○ [During development] : Assign the target CPU instruction to an unused instruction. ○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception. ○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction 50 Convert Hypervisor GuestVM An exception occurs function: sub sp, sp, #32 stp x29, x30, [sp, #16] (省略) ldp x29, x30, [sp, #16] add sp, sp, #32 ret nop function: sub sp, sp, #32 stp x29, x30, [sp, #16] (省略) ldp x29, x30, [sp, #16] add sp, sp, #32 sec_ret nop An exception occurs CPU layer When an extended Instruction is executed
  • 51. [Mechanism] How to extend CPU instructions virtually ➢ No prevailed CPU architecture has any systems which enable to extend instructions. ➢ Realized by collaboration among multiple layers. ○ [During development] : Assign the target CPU instruction to an unused instruction. ○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception. ○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction 51 Convert Hypervisor GuestVM An exception occurs Trap Hypervisor layer function: sub sp, sp, #32 stp x29, x30, [sp, #16] (省略) ldp x29, x30, [sp, #16] add sp, sp, #32 ret nop function: sub sp, sp, #32 stp x29, x30, [sp, #16] (省略) ldp x29, x30, [sp, #16] add sp, sp, #32 sec_ret nop An exception occurs
  • 52. function: sub sp, sp, #32 stp x29, x30, [sp, #16] (省略) ldp x29, x30, [sp, #16] add sp, sp, #32 ret nop function: sub sp, sp, #32 stp x29, x30, [sp, #16] (省略) ldp x29, x30, [sp, #16] add sp, sp, #32 sec_ret nop [Mechanism] How to extend CPU instructions virtually ➢ No prevailed CPU architecture has any systems which enable to extend instructions. ➢ Realized by collaboration among multiple layers. ○ [During development] : Assign the target CPU instruction to an unused instruction. ○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception. ○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction 52 Convert An exception occurs Hypervisor GuestVM An exception occurs Trap
  • 53. function: sub sp, sp, #32 stp x29, x30, [sp, #16] (省略) ldp x29, x30, [sp, #16] add sp, sp, #32 ret nop function: sub sp, sp, #32 stp x29, x30, [sp, #16] (省略) ldp x29, x30, [sp, #16] add sp, sp, #32 sec_ret nop [Mechanism] How to extend CPU instructions virtually ➢ No prevailed CPU architecture has any systems which enable to extend instructions. ➢ Realized by collaboration among multiple layers. ○ [During development] : Assign the target CPU instruction to an unused instruction. ○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception. ○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction ○ * This time, I use hypervisor calls instead of unused instructions 53 Convert An exception occurs Hypervisor GuestVM An exception occurs Trap
  • 54. 54 ● Applicable to proprietary software. ● Available on other CPU architectures which has a hypervisor layer. ● [Important] Collaboration among multiple layers is available, which is difficult on the real CPU layer. ○ Collaboration with static analysis tools, etc. (used for overhead reduction techniques in AsROP, which I describe later) [Discussion] The advantages of virtually extended CPU instructions
  • 55. 55 [Discussion] The advantages of security functions with hypervisors In some implementations, … ● Applicable to kernel spaces ● Can ensure real-time performance ● Doesn’t require to modify guest OS ● Become easy for developers to utilize embedded OSs, by hypervisors taking over security functions and reducing roles of guest embedded Oss.
  • 56. 56 What kind of virtually extended instructions works as security functions?
  • 57. 57 Show security functions with virtually extended CPU instructions in the next slides. ● AsROP ● AsCOP Security functions with virtually extended CPU instructions
  • 58. AsROP, an attack detection method against ROP 58
  • 59. 59 ● The core theory ○ Based on ROPGuard(*).Normally, “ret” instructions returns back to an instruction following a corresponding “bl“ instruction (called “call-preceded”).By checking this call-precedence, detect ROP(in this talk, we call “call-precedence check”). ● Implementation ○ Add this call-precedence check process to the “ret” instruction ■ Called the “sec_ret” instruction AsROP Mechanism * Reference[2] ROPGuard I. Fratric. “ROPGuard: Runtime prevention of return-oriented programming attacks.” 2012 function1: ... 3. bl function2 4. stur x0, [x29, #-16] 5. ... 6. ret function2: ... 9. ret CPU is expected to return here from function 2
  • 60. 60 In normal software, the “ret” instruction is executed frequently. The CPU overhead is very high. Therefore, AsROP reduces overhead by the following techniques: ① Code ROP detection process in AArch64 assembly. ② Reduce the number of the “ret” instruction which apply ROP detection process. The overhead reduction techniques of attack detection methods against ROP
  • 61. 61 ② Reduce the number of the “ret” instruction which apply ROP detection process. ● There some ret instructions which is impossible to abuse for attack.(“harmless ret instruction”) ○ This time, AsROP defines ret instructions of functions that does not use any pointer and buffer as “harmless ret instruction”. ● By working in cooperation with static analysis, execute “harmless ret instructions” as they are without converting them to "sec_ret" instructions. The overhead reduction techniques of attack detection methods against ROP
  • 62. 62 ② Reduce the number of the “ret” instruction which apply ROP detection process. ● There some ret instructions which is impossible to abuse for attack.(“harmless ret instruction”) ○ This time, AsROP defines ret instructions of functions that does not use any pointer and buffer as “harmless ret instruction”. ● By working in cooperation with static analysis, execute “harmless ret instructions” as they are without converting them to "sec_ret" instructions. → With implementations in a kernel driver and in a compiler layer, it is difficult to realize this idea. But, with my implementation by virtually extended instruction, it is very easy to realize! The overhead reduction techniques of attack detection methods against ROP
  • 63. 63 「ROP is Still Dangerous: Breking Modern Defenses」[4] ● Mention the possibility for attack detection methods checking call-precedence check to be bypassed. ○ If an executable binary is 70KB or lager, there is usually a possibility to mount an attack only with call-preceded ROP, i.e., the instruction before each gadget is a call instruction. ■ This is a peculiar story of x86, which is susceptible to ROP attack because of its variable length instructions. So it is not applicable to other CPU architectures which are relatively difficult to attack with ROP. ■ The attack method requires that ASLR is disabled ○ → It is very difficult to attack CPUs other than x86 with ASLR enabled and with call-preceded ROP only. ○ → I think there is virtually no possibility to bypass AsROP with call-preceded ROP. ○ We need more research and verification in real applications ! [Supplementary Discussion] The possibility that AsROP is bypassed
  • 64. 64 Execute script to display “Hello world” with mruby on guest OS, Linux. ➢ Compile to intermediate language + execute intermediate language The Performance Evaluation of AsROP Semzhu-Visor(Hypervisor) Linux(Kernel Space) mruby VM(User Space) CPU(AArch64)
  • 65. 65 AsROP Performance Evaluation Implementation CPU cycles in total CPU Overhead Number of executions of sec_ret execution cycles of sec_ret (cycles per execution) Off AsROP (Normal case) 45,026,014 0 0 0 Code in C language 80,580,786 35,554,772 (+79%) 113602 313 Code in assembly 59,887,536 14,861,522 (+33%) 113602 130 Code in assembly & Apply the reducing overhead techniques 56,433,742 11,407,728 (+25%) 83643 136
  • 66. 66 ● One execution of detection process is sure to finish within 200 cycles. ○ Succeed in ensuring Real-Time performance ● Work without any modifying OS. ● CPU overhead is 25% ○ Not practical. ○ → AsROP has to reduce more the number of the “ret” instruction which apply ROP detection process. (Future Work) [Discussion] The Characteristic of AsROP
  • 67. AsCOP, an attack detection method against COP
  • 68. 68 ● The core theory ○ Normally, an indirect call (in AArch64, the blr instruction) branches to a prologue of a function. However, in a COP gadget is execution, indirect call branches to a halfway point of a function. ○ Detect COP by checking whether the branch destination is a prologue of a function in the execution of the blr instruction. ● How can we check whether an address points to a prologue of a function? ○ List the addresses of the function from the execution binary in advance with a static analysis tool. ○ Add a behavior that checks whether the branch destination is a function by matching the branch destination address with the function list to blr instruction. (called “sec_blr instruction”) AsCOP Mechanism
  • 69. 69 ● Very high overhead. ● Real-time performance is lost. ● In some case, guest OS may need to be modified to apply functions to user space. ○ When the memory space is isolated for each user application, the OS needs to associate the function list with the corresponding user application. The problems of function list matching
  • 70. 70 The solutions to the problems of function list matching In most cases, we can instantly judge if an address points prologue of the function. ① Return address saving process check ○ In executable binaries generated by a compiler … ■ Return address saving process are placed at a specific position in functions. ■ And the instruction used to save is not used in other situation.. ○ If this process is detected in a function, ■ we can say the address points to the prologue of the function. ② ret instruction precedence check ○ With exception, ret are always placed just before prologues of functions. • For ret instructions in the middle of the function , • AsCOP rewrite it as a branch to the ret instruction at the end of the function. ○ If an instruction is just after a ret, its address also points to the prologue. List only exceptional functions, which are implemented in assembly and not just after ret instructions. ○ → Successful in reducing function list (1953 → 17) & matching times (10791 → 0) … 1: add sp, sp, #32 2: ret function: 3: sub sp, sp, #32 4: stp x29, x30, [sp, #16] …
  • 71. 71 Execute script to display “Hello world” with mruby on guest OS, Linux. ➢ Compile to intermediate language + execute intermediate language The Performance Evaluation of AsCOP Semzhu-Visor(Hypervisor) Linux(Kernel Space) mruby VM(User Space) CPU(AArch64)
  • 72. 72 The Performance Evaluation of AsCOP CPU cycles in total CPU Overhead Number of executions of sec_blr execution cycles of sec_blr 46,698,998 total 1,672,984(+3.7%) 10791 total 155 cycles per execution
  • 73. 73 ● CPU overhead was 3.7%; very practical ! ● Ensuring Real-Time performance ● Don’t require to modify guest OS [Evaluation] The Characteristic of AsCOP
  • 74. 74 ● video:https://drive.google.com/open?id=1w2NKRa2cPYaSPgCjSM33F6U0jEh58oSo ● A ROP gadget will be conducted, after executing the user program. ○ /demo/rop.elf : not defensed /demo/anti_rop.elf : defensed by AsROP ○ Left side : Log of guest OS, Linux Right side : Log of Semzhu-Visor DEMO AsROP
  • 75. 75
  • 76. 76 Log of Semzhu-VisorLog of Guest OS, Linux AsROP detects a ROP. And Semzhu-Visor causes an error exceptionon on Guest VM virtually.
  • 77. 77 AsROP detects a ROP. And Semzhu-Visor causes an error exceptionon on Guest VM virtually. An error exception occurring, Guest OS terminates abnormally the user program Log of Semzhu-VisorLog of Guest OS, Linux
  • 79. 79 ● Make Semzhu-Visor more sophisticated and convenient. ● Through the project, I got new ideas and saw massive potential in hypervisor. ○ e.g. ○ The risk of a “ret” instruction being abused for attack might depend on the place of that instruction. Optimizing behaviors according to the places might decrease CPU overhead. ○ Changing behaviors of extended instructions randomly might make it difficult to attack. ○ Also in other fields, I would like to seek the possibility of new ways of using hypervisors. Future work
  • 80. 80 ● Developed Semzhu-Visor, a simple embedded hypervisor running on a CPU emulator. ● Proposed an implementation method with virtually extended CPU instruction. ● Devised overhead reduction techniques that take advantage of virtually extended CPU instruction, and developed attack detection methods which is applicable to embedded systems, AsROP and AsCOP. ■ Applicable to proprietary software. ■ Applicable to kernel spaces. ■ Don’t require to modify OS. ■ Ensure Real-Time performance. ○ For AsCOP, the performance experiment show that it is practical. Summary
  • 81. 81 Semzhu-Project is the result of research and development in SecHack365, a Japanese security hackathon conducted by NICT in order to train young security innovators. Acknowledgements
  • 82. 82 There is a new world of embedded hypervisors.
  • 83. 83 Even one ignorant high school student is able to create a hypervisor and new security functions.
  • 84. 84 Why don’t you create your own new world of hypervisors?