SFOP: Cách chuỗi Segmentation Fault có thể vượt qua cơ chế bảo vệ Intel CET trên Linux

Bằng cách lặp lại chuỗi này nhiều lần, kẻ tấn công có thể tạo ra một chuỗi hành động có kiểm soát, sử dụng chính các đoạn mã hợp lệ đã tồn tại trong chương trình hoặc thư viện của nó.

Điểm khác biệt so với các kỹ thuật quen thuộc như Return‑Oriented Programming (ROP) là SFOP không phụ thuộc vào việc thao túng địa chỉ return, mà dựa vào các sự kiện crash hợp lệ do hệ điều hành xử lý.

Vì sao Intel CET được thiết kế để ngăn chặn kiểu tấn công này?

Intel giới thiệu Control‑Flow Enforcement Technology (CET) nhằm chống lại các cuộc tấn công code‑reuse. Công nghệ này kết hợp nhiều cơ chế phần cứng nhằm kiểm soát luồng thực thi của chương trình.

Các thành phần chính gồm:

• Xác thực địa chỉ return thông qua shadow stack
• Kiểm soát các nhánh gián tiếp (indirect branch targets)

Mục tiêu là ngăn chặn việc nhảy tới các vị trí lệnh không mong muốn trong mã chương trình.

Tuy nhiên, CET chủ yếu bảo vệ các chuyển đổi control‑flow bất hợp lệ trong quá trình thực thi bình thường.

SFOP lại đi đường vòng: nó tận dụng các chuyển đổi control‑flow hợp lệ do hệ điều hành kích hoạt.

Cách SFOP vượt qua CET trên Linux

Ý tưởng cốt lõi của SFOP là: việc hệ điều hành gửi tín hiệu (signal delivery) vốn là một chuyển đổi luồng thực thi hợp lệ.

Chuỗi tấn công có thể diễn ra như sau:

1. Kẻ tấn công khiến chương trình truy cập vùng nhớ bị cấm.
2. Linux phát sinh tín hiệu SIGSEGV.
3. Hệ điều hành chuyển quyền điều khiển tới signal handler đã đăng ký.
4. Handler chuẩn bị điều kiện cho lỗi tiếp theo.
5. Chương trình tiếp tục crash và vòng lặp lặp lại.

Mỗi lần signal handler được gọi sẽ trở thành một mắt xích trong chuỗi điều khiển thực thi của kẻ tấn công.

Vì việc chuyển vào handler là hành vi hợp lệ do kernel quản lý, nên nó có thể vượt qua các kiểm tra control‑flow của CET vốn chỉ giám sát các nhánh gián tiếp và return bên trong chương trình.

Khi chuỗi đủ dài, kẻ tấn công có thể ghép các hành vi lại để đạt tới arbitrary code execution bằng cách tận dụng mã sẵn có trong chương trình.

Vai trò của cơ chế SIGSEGV trong Linux

Trong Linux, các chương trình có thể đăng ký signal handler để xử lý các tín hiệu như SIGSEGV. Thông thường điều này dùng để:

• ghi log lỗi
• dọn dẹp tài nguyên
• hoặc thử phục hồi chương trình

SFOP biến cơ chế này thành một primitive điều khiển luồng thực thi bằng cách:

• cố ý gây segmentation fault nhiều lần
• kích hoạt handler sau mỗi lần crash
• thay đổi hành vi thực thi ở từng bước

Do đó, bản thân cơ chế xử lý tín hiệu của hệ điều hành trở thành công cụ để xây dựng chuỗi tấn công.

Các biện pháp giảm thiểu được đề xuất

Tăng cường bảo mật Linux kernel

Một hướng phòng thủ là thay đổi hành vi xử lý signal của kernel nhằm hạn chế việc lợi dụng segmentation fault lặp lại như một primitive control‑flow.

Các báo cáo công khai đề cập tới việc phát triển kernel patches để giảm khả năng chuỗi hóa các SIGSEGV, dù chi tiết kỹ thuật của các bản vá vẫn chưa được công bố rộng rãi.

Lớp hardening PLaTypus

Một giải pháp khác được đề xuất là PLaTypus, một lớp tăng cường bảo mật nhằm củng cố CET trước các kỹ thuật code‑reuse hiện đại.

PLaTypus tập trung vào việc hạn chế các bước nhảy control‑flow giữa các thư viện khác nhau trong một chương trình.

Các nhà nghiên cứu nhận thấy rằng ngay cả khi CET được bật, kẻ tấn công vẫn có thể chuyển hướng thực thi giữa các thư viện chia sẻ.

PLaTypus giảm thiểu vấn đề này bằng cách:

• hạn chế các indirect jump ra ngoài thư viện hiện tại
• chỉ cho phép chuyển thư viện trong các trường hợp hợp lệ

Cách tiếp cận này giúp giảm đáng kể số lượng mục tiêu code‑reuse khả dụng, qua đó thu hẹp bề mặt tấn công.

Vì sao nghiên cứu SFOP quan trọng?

SFOP cho thấy một bài học quan trọng trong kiến trúc bảo mật hiện đại: bảo vệ phần cứng thôi là chưa đủ nếu hành vi của hệ điều hành vẫn có thể trở thành điểm khai thác.

Ngay cả những cơ chế tiên tiến như Intel CET cũng có thể bị vượt qua khi kẻ tấn công tìm ra cách điều hướng luồng thực thi thông qua các cơ chế hợp lệ của hệ thống, chẳng hạn như xử lý signal.

Đối với các kỹ sư bảo mật và nhà phát triển hệ thống, thông điệp rất rõ ràng: các lớp phòng thủ cần được thiết kế trên toàn bộ stack — từ CPU, hệ điều hành cho tới phần mềm. Chỉ cần một lớp còn lộ ra primitive điều khiển luồng thực thi, kẻ tấn công vẫn có thể tận dụng nó.