Shenwenbo, researcher of the Hundred Talents Program of Zhejiang University: kernel security in the container scenario

The guest | Shen Wenbo Arrangement | Which zha

Produce | CSDN Cloud native

2022 year 6 month 7 Japan , stay CSDN Cloud native series online Summit 7 period “ Security Technology Summit ” On , Researcher of the Hundred Talents Program of Zhejiang University 、 Shen Wenbo, a doctoral tutor, takes the evolution of traditional kernel attack and protection as a breakthrough , Shared the new challenges that containers bring to kernel security —— Abstract resource attacks and memory counting problems .

According to statistics ,2008-2019 year ,Linux The amount of kernel code has increased sharply , To 2019 Years have passed 2300 Line ten thousand , The latest statistics show that ,Linux The amount of kernel code is close 2800 Line ten thousand .

meanwhile ,Linux It's just Android Part of ecology , stay Linux On top of the kernel , also HAL、Runtime、Framework、Applications Equal multilayer .

We know , The amount of code is the same as Bug The number may be directly proportional to the number of vulnerabilities , in other words , More code ,Bug Number 、 The larger the number of vulnerabilities . These vulnerabilities are often exploited by attackers , Generate new attacks .

meanwhile , New types of attacks have spawned new types of protection , Therefore, the attack and defense of the operating system kernel are evolved and upgraded in the continuous confrontation , There is no absolutely safe system , There is no absolutely strong means of attack .

Kernel traditional attack and defense evolution

Attack and defense generally revolve around code injection 、 code reuse 、 Fight against data attacks . The following figure shows the evolution of kernel attack and protection .

Code injection attack and defense

Through kernel vulnerabilities

• Tampering with existing code text section

• Inject new code

• Or jump to the user code , such as jump-to-user

The system has great control capability

• Executable new code

• Great harm

It is often seen in the early stage Linux

• such as Kernel Text RWX（Android 2013）

Kernel code injection protection

• Protect existing code W^X

• Hardware support , No injection

• Data is not executable （2001 XN ARM; NX AMD）

• Privileges are not executable （2011 SMEP Intel; PXN ARM）

Through the kernel page table

• Set the corresponding protection bit in the kernel page table , Achieve protection

• Most of the Android equipment , contain Google Pixel

• Weak defensiveness , The kernel page table becomes invalid when it is changed

• The kernel page table is not protected

• An attacker can tamper with the page table , Remove the protection

• And then tamper with the code    

Protect the kernel page table by isolating the environment

• By isolating the environment , Avoid kernel vulnerabilities

• Achieved defense in depth defense-in-depth

Kernel code reuse attack

Kernel code reuse attack is also known as control flow hijacking attack , This attack cannot inject new code , Instead, reuse existing code . Generally, the flow is controlled by tampering , Splicing existing function fragments , Implement attack functions .

There are two ways to attack ：

• Return-oriented programming (ROP) ： By injecting malicious return address , Construct attack function

• Jump-oriented programming (JOP)： By tampering with function pointers , Construct attack function

Kernel data attack

After the control data is protected , An attacker proposes an uncontrolled data attack

• Return data other than address and function pointer

• Data-oriented programming

• Affect key safety features ： Only using non control data attacks to achieve kernel authorization

Non control data protection  

• There are many kinds of species , It is difficult to implement unified and effective protection

• Mainstream operating systems are lack Effective protection against data attacks

On the whole , Attack evolution presents

• Attack difficulty increases exponentially

• Complexity increases exponentially

• Concealment is increasing

• control Reduced capacity

• Data attacks can still root kernel

The evolution of protection presents

• Software to hardware

• From academic prototype to industrial practical solution

• There is a lag

Security issues of the kernel in the container scenario

Containers are operating system level virtualization , It is a virtual instance of multiple user spaces from the same kernel , Instances of each user space , No need to maintain a pure kernel . Instances of user space , Also called container instances , It doesn't have to maintain the kernel alone , So it's efficient 、 Fast start , And the configuration is flexible , Will be widely used in code .

In the container scenario , Security is mainly reflected in abstract resource attacks 、 Memory count problem .

Abstract resource attack

The essence of container is process based resource isolation , from namespaces In charge of isolation , Current kernel support 8 Kind of namespaces, contain UTS、IPC、mount、PID、network、user、time、cgroup; from control groups Limit , Current kernel support 13 Kind of cgroups, Mainly used to limit CPU、 Memory and device resources .

Containers focus on limiting physical resources , Ignore Abstract resources , Such as kernel variables . We found that , These abstract resources can also be DoS attack , For example, open a large number of files , Run out of nr_files; All new open file operations will fail , The new program cannot be run . Simultaneous discovery , Large cloud vendors can be attacked by abstract resources .

therefore , Kernel data also determines the availability of operating system functions , Easily lead to DoS attack ; kernel data dependency complex , It is difficult to solve completely DoS problem ; Virtual machine isolation is recommended for scenarios with high security requirements .

Memory count problem

Kernel dependencies memcg Count the memory , and memcg Without systematic safety analysis , There are safety risks . therefore , For memory counting , We've done a lot of work .

• Formalize the steps that define the memory count

• Analysis of the policy design The problem of

• Design automated tool analysis implementation problem

• Found out policy design The problem of missing count caused by

• An automatic analysis tool based on compiler is designed , Yes policy implementation Conduct systematic analysis

Up to now , We found out 53 Count Bug, One of them has been confirmed 34 And submit patch.

In conclusion , The kernel security has been greatly improved in the confrontation , However, the protection against data attacks is still insufficient . The container scenario brings new opportunities to the kernel , It also brings new security challenges , Including abstract resource attacks and memory counting problems .

---

Focusing cloud native New Technology 、 New practice , Help the developer community win in the new era of development paradigm shift . Welcome to your attention CSDN Cloud native WeChat official account ～