An toàn máy tính & Mạng

Sandboxing – hộp cát

Thực thi mã không tin cậy

 Nhiều khi phải thực thi các đoạn mã lạ/không rõ nguồn gốc/không tin cậy:
• Chương trình tải từ site không tin cậy trên Internet:
• toolbars, viewers, media player codec…
• Các ứng dụng cũ, không an toàn: ghostview,..
• Các dịch vụ: sendmail, bind
• ..
 Vấn đề: xử lý thế nào khi ứng dụng thực thi sai (misbehaves)
Hủy tiến trình
Tiếp cận: hạn chế phạm vi/giam hãm

 Giam hãm: đảm bảo ứng dụng không thể thực thi lệch ra khỏi cách thức đã được quy định
trước
 Có thể cài đặt ở các tầng khác nhau:
• Thiết bị: thực thi ứng dụng trên phần cứng tách biệt (vd air gap)
• => khó quản lý
• Máy ảo: tách riêng nhiều HĐH trên 1 nền tảng phần cứng
• Chặn giữa các lời gọi dịch vụ hệ thống/HĐH:
• Tách biệt các tiến trình trên cùng 1 HĐH
• Phân tách riêng các thread chia sẻ cùng không gian địa chỉ:
• Cơ chế Software Fault Isolation (SFI)
• Đặc thù theo ứng dụng: vd sandbox trong trình duyệt web
Cài đặt việc giam hãm - jail

Thành phần quan trọng: reference monitor – quản trị tham chiếu
• Làm trung gian yêu xử lý cầu từ ứng dụng
• Cài đặt chính sách bảo vệ
• Bắt buộc việc tách biệt và giam hãm
• Phải luôn được gọi đến:
• Bất kỳ lời gọi/yêu cầu nào của ứng dụng đều phải được thực thi qua trung gian
• Đảm bảo kiểm soát:
• Tiến trình Reference monitor không thể bị hủy
• Nếu bị hủy => các tiến trình bị theo dõi cũng phải hủy
• Đủ nhỏ để đánh giá
Ví dụ: với lệnh chroot

 Thường dùng cho tài khoản “guest” trên các ftp

 Để thực hiện: (quyền root)

chroot /tmp/guest -- root dir “/” sẽ trỏ tới “/tmp/guest”
su guest -- đổi sang “guest”

 Từ đây, "/tmp/guest" được thêm vào khi truy cập file system bởi các
ứng dụng được đặt trong phạm vi giam hãm (jail), vd
open("/etc/passwd", "r")  open("/tmp/guest/etc/passwd", "r")
=> Ứng dụng không thể truy cập các file bên ngoài phạm vi giam hãm
Jailkit project
• jailkit project: auto builds files, libs, and dirs needed in jail
environment
• jk_init: creates jail environment
• jk_check: checks jail env for security problems
• checks for any modified programs,
• checks for world writable directories, etc.
• jk_lsh: restricted shell to be used inside jail

• note: simple chroot jail does not limit network access

 Problem: all utility progs (ls, ps, vi) must live inside jail
Escaping from jails
 Early escapes: relative paths
open( “../../etc/passwd”, “r”) 
open(“/tmp/guest/../../etc/passwd”, “r”)

 chroot should only be executable by root

• otherwise jailed app can do:
• create dummy file “/aaa/etc/passwd”
• run chroot “/aaa”
• run su root to become root
(bug in Ultrix 4.0)
Many ways to escape jail as root

 Create device that lets you access raw disk

 Send signals to non chrooted process

 Reboot system

 Bind to privileged ports

Freebsd jail
 Stronger mechanism than simple chroot

 To run:
jail jail-path hostname IP-addr cmd
• calls hardened chroot (no “../../” escape)
• can only bind to sockets with specified IP address
and authorized ports
• can only communicate with process inside jail
• root is limited, e.g. cannot load kernel modules
Problems with chroot and jail

 Coarse policies:
• All or nothing access to file system
• Inappropriate for apps like web browser
• Needs read access to files outside jail
(e.g. for sending attachments in gmail)

 Do not prevent malicious apps from:

• Accessing network and messing with other machines
• Trying to crash host OS
Cơ chế chặn các lời gọi hàm hệ thống
Chặn giữa lời gọi hệ thống

 Nhận xét: để phá hỏng hệ thống (vd ghi virus vào file), các ứng dụng cần thực thi các lời
gọi hệ thống, vd
• Để delete/overwrite files: cần gọi hàm như open, write
• Để tấn công mạng: cần gọi hàm socket, bind, connect, send

 Ý tưởng
• Theo dõi các lời gọi hệ thống và chặn/cấm các lời gọi không được phép
 Ví dụ cài đặt:
• Chạy ở chế độ kernel: GSWTK
• Chạy ở chế độ user: program shepherding
• Chế độ lai: Systrace
Vd: Janus

 Công cụ Linux ptrace: theo dõi hành vi của tiến trình

• theo dõi các lời gọi của tiến trình: ptrace (… , pid_t pid , …)
• kích hoạt khi tiến trình pid thực hiện lời gọi.

user space
monitored
application monitor
(outlook)

 open(“etc/passwd”,
Hủy tiến trình ứng dụng nếu cố thực hiện yêu“r”)
cầu không được phép

OS Kernel
Biến đổi

 Nếu ứng dụng phân chia => công cụ monitor cũng phân chia
• Tiến trình monitor phân tách sẽ theo dõi ứng dụng phân tách

 Nếu ứng dụng monitor gapwj sự cố => ứng dụng phải bị hủy
 Công cụ Monitor thường theo dõi tất cả trạng thái HĐH gắn với ứng dụng, vd
• Current working dir, UID, GID
• Khi thay đổi, vd “cd path” => monitor cũng cập nhật thông tin
Problems with ptrace (process trace)
 Ptrace too coarse for this application
• Trace all system calls or none
• e.g. no need to trace “close” system call
• Monitor cannot abort sys-call without killing app

 Security problems: race conditions

• Example: symlink: me -> mydata.dat
proc 1: open(“me”)
monitor checks and authorizes
proc 2: me -> /etc/passwd
time

OS executes open(“me”)
• Classic TOCTOU bug: time-of-check / time-of-use not atomic
Alternate design: systrace
user space
monitored
application monitor policy file
(outlook) for app

open(“etc/passwd”, “r”)

sys-call
systrace
gateway
permit/deny
OS Kernel
 systrace only forwards monitored sys-calls to monitor (saves context
switches)
 systrace resolves sym-links and replaces sys-call
path arguments by full path to target
 When app calls execve, monitor loads new policy file
Policy
 Sample policy file:
path allow /tmp/*
path deny /etc/passwd
network deny all

 Specifying policy for an app is quite difficult

• Systrace can auto-gen policy by learning how app behaves on “good” inputs
• If policy does not cover a specific sys-call, ask user
… but user has no way to decide

 Difficulty with choosing policy for specific apps (e.g.

browser) is main reason this approach is not widely used
Ví dụ native client

Browser Quake
NPAPI
HTML
JavaScript

NaCl runtime

 Quake: mã không tin cậy

 Dùng 2 sandboxes:
• outer sandbox: hạn chế quyền dùng cơ chế chặn lời gọi hệ thống
• Inner sandbox: dùng cơ chế phân đoạn bộ nhớ x86 để to isolate
application memory from one another
Dùng cơ chế máy ảo
Máy ảo – virtual machine

VM2 VM1

Apps Apps

Guest OS 2 Guest OS 1
Virtual Machine Monitor (VMM)

Host OS
Hardware

Ví dụ: Vmware, HyperV, VirtualBox, NSA NetTop

Sự phổ biến

 Máy ảo trong những năm 1960:

• Một vài máy >< nhiều người dùng
• Máy ảo cho phép nhiều người dùng chia sẻ chung 1 máy (vật lý)
 Từ 2000:
• Quá nhiều máy chủ, vd
• Print server, Mail server, Web server,
File server, Database server, …
• Lãng phí tài nguyên khi thực thi mỗi dịch vụ trên 1 phàn cứng
• Máy ảo tiết kiệm tài nguyên thiết bị trong khi vẫn đảm bảo phân tách riêng biệt dịch vụ
• Hơn nữa: điện toán đám mây – máy ảo là 1 thành phần quan trọng
Giả thiết về bảo mật với máy ảo

 Giả thiết
• Mã độc hại (malware) có thể ảnh hưởng đến guest OS và guest apps (HĐH khách và ứng dụng khách -
trên máy ảo)
• Mã độc không thể vượt ra khỏi phạm vi máy ảo bị ảnh hưởng:
• không thể ảnh hưởng đến host OS (HĐH chủ)
• không thể ảnh hưởng đến các máy ảo khác trên cùng phần cứng

 Đòi hỏi máy ảo tự bảo vệ mình và không bị lỗi

• Thường máy ảo đơn giản hơn cả HĐH đầy đủ
• … chú ý trình điều khiển thiết bị chạy trên nền HĐH chủ
Vấn đề: trao đổi ngầm

 Trao đổi ngầm (covert channel): kênh trao đổi giữa các cấu thành đã được phân tách riêng
• Có thể được dùng để làm rò rỉ thông tin mật từ cấu thành bảo mật sang cấu thành công khai

Classified VM Public VM

secret
malware

doc covert
listener
channel

VMM
Ví dụ kênh ngầm

 Các máy ảo chạy trên cùng 1 nền thiết bị

 Có nhiều kênh có thể bị lợi dụng:
• File lock status, cache contents, interrupts, …
• Khó ngăn chặn hết

 Ví dụ gửi bit b  {0,1}, malware có thể:

• Nếu b= 1: lúc 1:30.00am bắt CPU thực hiện tính toán nhiều
• Nếu b= 0: lúc 1:30.00am không thực hiện gì
 Vào 1:30.00am bên nhận yêu cầu tính toán và đo thời gian thực thi, tính b dựa trên tương
quan
• b=1  thời gian thực thi > 1 ngưỡng
Máy ảo: cơ chế tự xem xét phòng chống virus
Phát hiện xâm nhập, chống virus

 Thường chạy như 1 phần trong chế độ hạt nhân

• Kernel root kit có thể can thiệp sâu, vd tắt hệ thống
• Root kit đang được các malware học tập
 Giải pháp chuẩn mực: thực thi IDS trên mạng
• Vấn đề: có thể không đủ quyền theo dõi máy tính của người dùng cuối
 Phương án khác: thực thi IDS như là phần của máy ảo (hy vọng bảo vệ khỏi malware)
• VMM có thể theo dõi các hành động bất thường
• VMI- Virtual Machine Introspection:
• Là cơ chế cho phép VMM kiểm tra vào bên trong HĐH khách
Ví dụ kiểm tra

 Giấu diếm mã độc: thường che dấu qua

• Tạo tiến trình không hiển thị trên danh sách khi thực thi lệnh “ps”
• Mở socket không hiển thị với lệnh “netstat”
 1. Kiểm tra phát hiện mâu thuẫn
• Mục đích: phát hiện dấu vết tồn tại malware che dấu khỏi danh sách tiến trình & tác vụ mạng
• Ví dụ Phương pháp phát hiện:
• VMM liệt kê các tiến trình đang thực thi trong HĐH khách
• VMM yêu cầu HĐH khách liệt kê danh sách tiến trình
• Nếu không khớp: hủy VM
Ví dụ kiểm tra

 2. Kiểm tra tính toàn vẹn của mã

• VMM tính giá trị băm của chương trình/mã thực thi trong VM
• So sánh với giá trị băm nguyên thủy
• hủy VM nếu có tiến trình lạ
 3. Đảm bảo toàn vẹn của hạt nhân HĐH
• Ví dụ: phát hiện thay đổi của sys_call_table
 4. Phát hiện dấu hiệu virus
• Tìm sự xuất hiện đặc trưng của virus trong bộ nhớ
Phá vỡ
Subvirt

 Virus & VMM:

• Cài đặt mã độc vào VMM
• Virus ẩn trong VMM
=> Chương trình phát hiện virus chạy trong VM không phát hiện được

Anti-virus

Anti-virus

OS
OS VMM and virus
HW HW
The MATRIX
Mã độc trên nền VM (blue pill virus)

 VMBR: là virus cài đặt phần mềm VMM (hypervisor) có mã độc

 Microsoft Security Bulletin: (Oct, 2006)

http://www.microsoft.com/whdc/system/platform/virtual/CPUVirtExt.mspx
• Khuyến cáo cấm tính năng ảo hóa trên máy khách
 Có thể chống VMBR:
• Thường HĐH khách có thể nhận biết nó chạy trên nền ảo hóa hay vật lý
Phát hiện VMM

 HĐH có thể nhận biết đang chạy trên nền ảo hóa VMM?
 Ứng dụng:
• Phần mềm nhận dạng virus có thể phát hiện VMBR
• Mã virus (non-VMBR) có thể phát hiện VMM
=> Chống chạy debug để lần ngược mã(reverse engineering)
• Phần mềm gắn kết thiết bị (vd MS Windows) có thể chặn không chạy trên VMM
Phát hiện VMM (red pill techniques)

 Nền tảng VM thường giả lập phần ứng đơn giản

• Vd VMWare giả lập chipset cũ i440bx
• … nhưng báo cáo 8GB RAM, dual Opteron CPUs, ...
 VMM đưa ra thời gian trễ khác nhau
• Memory cache được xử lý khác biệt khi có VMM
• Dẫn đến: thời gian tương đối thực thi 2 tác vụ có thể khác nhau
 VMM chia sẻ TLB (bảng ánh xạ) cùng HĐH khách
• HĐH khách có thể phát hiện giảm kích thước của TLB
 …
Phát hiện VMM

 VMM không hoàn hảo

 Xu hướng VMMs (vd VMWare) tập trung vào:
• Tương thích: đảm bảo các ứng dụng thực thi
• Hiệu năng: giảm thiểu ảnh hưởng do VMM
Cô lập lỗi phần mềm
Cô lập lỗi phần mềm

 Mục tiêu: bảo vệ ứng dụng thực thi trên cùng không gian địa chỉ, vd
• Codec không được ảnh hưởng đến media player
• Trình điều khiển thiết bị không được làm hỏng kernel

 Giải pháp đơn giản: các ứng dụng chạy trên các không gian địa chỉ tách biệt
• Nhược điểm: nếu thường xuyên trao đổi thông tin => chậm
Cô lập lỗi phần mềm

 Tiếp cận:
• Phân bộ nhớ => các đoạn, vd đoạn mã, đoạn dữ liệu

code data code data

segment segment segment segment

app #1 app #2
• Xác định các lệnh không an toàn, vd: jmp, load
• Khi biên dịch, thêm các chỉ thị bảo vệ
• Khi nạp mã lệnh, đảm bảo các chỉ thị bảo vệ có
Segment matching technique
 Designed for MIPS processor. Many registers available.
 dr1, dr2: dedicated registers not used by binary
• Compiler pretends these registers don’t exist
• dr2 contains segment ID
Guard ensures code doe
 Indirect load instruction R12  [addr]
becomes: load data from another se
dr1  addr
scratch-reg  (dr1 >> 20) : get segment ID
compare scratch-reg and dr2 : validate seg. ID
trap if not equal
R12  [addr] : do load
Address sandboxing technique
 dr2: holds segment ID

 Indirect load instruction R12  [addr]

becomes:
dr1  addr & segment-mask : zero out seg bits
dr1  dr1 | dr2 : set valid seg ID
R12  [dr1] : do load

 Fewer instructions than segment matching

… but does not catch offending instructions

 Lots of room for optimizations: reduce # of guards

Cross domain calls
caller callee
domain domain
stub draw:
call draw
return

br addr
stub br addr
br addr

 Only stubs allowed to make croos-domain jumps

 Jump table contains allowed exit points from callee
• Addresses are hard coded, read-only segment
SFI: concluding remarks
 For shared memory: use virtual memory hardware
• Map same physical page to two segments in addr space

 Performance
• Usually good: mpeg_play, 4% slowdown

 Limitations of SFI: harder to implement on x86 :

• variable length instructions: unclear where to put guards
• few registers: can’t dedicate three to SFI
• many instructions affect memory: more guards needed
Tổng kết

 Có khá nhiều cơ chế sandboxing khác nhau:

• Máy ảo (VMMs),
• Chặn lời gọi hệ thống (System call interposition)
• Cô lập lỗi phần mềm (Software Fault isolation)
• Đặc thù của ứng dụng (Javascript)

 Thường hoàn toàn cô lập là không hợp lý

• Do các ƯD thường yc tương tác của các giao diện chuẩn (interface)

 Khía cạnh phức tạp nhất khi dùng sandboxing:

• Định nghĩa rõ và đủ các chính sách (policy)