How to enable CoreOS to boot on top of iKGT (Intel Kernel Guard Technology) ?

Linked to here: 
https://01.org/intel-kgt/blogs or https://01.org/intel-kgt/blogs/bzhu5/2015/coreos-ikgt
<END>

Intel Kernel Guard Technology is released as opensource software

See the official site for details: https://01.org/intel-kgt
<END>

Common security design issues in privileged hypervisor or in any privileged emulators

Recently I've reviewed nearly 100 Xen Security Advisories (http://xenbits.xen.org/xsa/), except some bad security coding practices for any ordinary software, I found there are some specific security issues that we need to take into considerations when designing prvilieged hypervisors or privileged emulators.

Control-flow processor exceptions (single-stepping on branches) on control-flow branch instructions (jmp/call/ret)

"single-stepping on branches" is processor hardware feature of x86/Intel architecture. When it is enabled, the processor generates a single-step debug exception only after instructions that cause a branch. This mechanism
allows a debugger to single-step on control transfers caused by branches. What does this imply to defense against control-flow hijacking attacks (e.g. ROP or JOP) ? 

How to defend against Stack Pivoting attacks on existing 32-bit x86 processor architecture?

Stack Pivoting is a common technique widely used by vulnerability exploits to bypass hardware protections like NX/SMEP, or to chain ROP (Return-Oriented Programing, the Wikipedia link) gadgets. However, there is NO hardware protection solution to defend against it (at least for now:-). This blog will describe a software solution to detect Stack Pivoting at run time, and I will also point out some limitations due to current processor architecture implementations.  <Please let me know if this is NOT a new idea, or NOT doable.>

Using LBR (Last Branch Record) feature to detect ret2usr (return-to-user) attack w/ MMU paging structure corruption

SMEP (Supervisor Mode Execution Prevention) is a mitigation that aims to prevent the CPU from running code from user-mode while in kernel-mode, however this post (Windows 8 Kernel Memory Protections Bypass) presents a generic technique for exploiting kernel vulnerabilities with bypassing SMEP. Unlike my previous post (Page Table Structure Corruption Attacks - How to Mitigate it?) that presented a mitigation to that attack, this post will present a solution to detect such a ret2usr attack due to MMU paging structure corruption.

New security feature - Control Flow Guard (CFG) - available in Visual Studio 2015 Preview

This blog announced that the Preview for Visual Studio 2015 includes a new, work-in-progress feature, called Control Flow Guard (CFG). 

Defending Against ret2dir Attacks (partially) with Virtualization Technology?

I was so excited when recently reading the paper (ret2dir: Rethinking Kernel Isolation) from Vasileios P. Kemerlis. This post is basically going to introduce the idea of ret2dir attack, and how to prevent such an attack with hardware virtualization technology, actually partially. 

Improve Performance for Separating Kernel and User Address Space with Process-Context Identifiers (PCIDs)

This post is not talking about any new idea, just about what I'm thinking..

Page Table Structure Corruption Attacks - How to Mitigate it?

On x86 and many other processor architectures (with MMU), page tables are critical data structures for address translations. And many hardware-based page level protection technologies in my previous post, like SMEP, XD/DEP, highly depend on correct page table settings. so what if page tables are controlled by an attacker? ...At the end of this post, I will propose an extra solution to mitigate page table structure attacks.

Implement software-based SMEP with Non-Execute (NX) bit in page tables to secure kernel/user virtual memory address space.

In my previous post, I talked about how to implement a software-based SMEP (Supervisor Mode Execution Protection) with virtualization/hypervisor for fun. In this post, I'm going to detail yet another solution to implement software-based SMEP without virtualization technology. 

DMA Attacks Against McAfee DeepSafe

Rafal Wojtczuk (from Bromium, previously Invisible Things Lab) presented DMA attacks against DeepSafe. 

Latest researching status of ROP/JOP attacks and defenses

Control Flow Hijacking, like ROP, becomes a hot topic in recent years since ever DEP(W^X enforcement) and SMEP were introduced in h/w processor. Based upon the papers that I read recently, this post just gives a brief introduction on the recent researching status (though incomplete) about control flow attacks and defenses. 

How to Implement a software-based SMEP(Supervisor Mode Execution Protection) with Virtualization/Hypervisor Technology

As my previous post indicated, SMEP is a powerful security feature, and easy to deploy in modern commodity OS. However this feature requires H/W processor's support, for those processors that are not SMEP-capable, this post presents a software-based solution to emulate SMEP functionality with the help of Virtualization/Hypervisor technology. 

What does Transactional Synchronization Extensions (TSX) processor technology mean to vulnerability exploits (e.g. Brute Forcing)?

Intel Transactional Synchronization Extensions (TSX) was introduced since from Haswell processor with adding hardware transactional memory support. It was originally design to speed up execution of multi-threaded software through lock elision. Every new technology has both good side and evil side, then how about TSX extension? What can we use it to do for vulnerability exploits and its defenses?

Using LBR (Last Branch Record) Feature to Detect IDT-Shadowing-Based Malicious IDT Hooking

Thanks to Yushi who shared a presentation (ELI: Bare-Metal Performance for I/O Virtualization) with me. In that hypervisor (ELI), it innovates an idea of gust IDT shadow (or IDT virtualization) design for some specific usage models. I'm going to talk a little bit about this idea.

Security OS Design (cont.): Write Protection for Linux Kernel critical data structures (GDT, IDT, syscall table, task_strcture, mm_struct,...)

To be continued for previous post, let me review what must be changed in Linux kernel in order to prevent buffer overrun/overflow attacks from modifying the critical kernel data structures, like GDT, IDT, task_struct, mm_struct, etc.

Security OS Kernel Design: an idea to prevent malicious software overwriting the critical system kernel data structures

Recently, when reading this paper "HyperSafe - A Lightweight Approach to Provide Lifetime Hypervisor Control-Flow Integrity", an idea just comes out from my mind: using write protection (CR0.WP) and read-only (RO) page attribute to prevent the critical kernel data structures being overwritten by malicious software through buffer (stack, heap) overflow in an exploitable kernel module.

Control Flow Integrity (CFI)

Traditionally, arbitrary malicious code execution (e.g. caused by buffer overflow, stack or heap manipulation) is one of major threats in computer security. 

But due to the fact that there are many hardware-enforced security features are introduced in recent processors, for example in my previous post, the attackers are starting to explore the other advanced techniques.

ARM TrustZone (Security Extension) and Virtualization Extension vs x86 Virtualization Technology

A typical virtualization system on both x86 and ARM includes three major parts:

• CPU virtualization
• Memory virtualization, and 
• I/O virtualization (device, interrupt virtualization).