BAN CƠ YẾU CHÍNH PHỦ

HỌC VIỆN KỸ THUẬT MẬT MÃ

KHOA: AN TOÀN THÔNG TIN


THỰC TẬP CƠ SỞ CHUYÊN NGHÀNH

AN TOÀN PHẦN MỀM

NGHIÊN CỨU THỰC HÀNH CÁCH TẤN CÔNG

RETURN-TO-LIBC (RETURN-TO-LIBC ATTACK LAB)
……………………………………………………………………………………………..

Giảng viên hướng dẫn: PGS.TS Lương Thế Dũng

Sinh viên thực hiện: Trần Quốc Hoàng
Lớp: AT15H
Mã số sinh viên: AT150719
Nhóm: 13
Khóa: 2018-2023

TP. Hồ Chí Minh, tháng 11 năm 2021

1
 BAN CƠ YẾU CHÍNH PHỦ
HỌC VIỆN KỸ THUẬT MẬT MÃ
KHOA: AN TOÀN THÔNG TIN


THỰC TẬP CƠ SỞ CHUYÊN NGÀNH

AN TOÀN PHẦN MỀM

NGHIÊN CỨU THỰC HÀNH CÁCH TẤN CÔNG

RETURN-TO-LIBC (RETURN-TO-LIBC ATTACK LAB)

Nhận xét của giáo viên hướng dẫn:.....................................................................................

............................................................................................................................................
............................................................................................................................................
............................................................................................................................................
............................................................................................................................................
............................................................................................................................................
Điểm báo cáo: ....................................................................................................................

Xác nhận của giáo viên hướng dẫn:

2
 LỜI CẢM ƠN
Chúng em xin chân thành cảm ơn PGS.TS. Lương Thế Dũng–giảng viên trực
tiếp hướng dẫn, chỉ bảo, tạo mọi điều kiện thuận lợi giúp đỡ chúng em trong quá trình
thực hiện đề tài.
Để có được thành quả như ngày hôm nay, ngoài sự nỗ lực không ngừng nghỉ của
các thành viên trong nhóm thì một phần không nhỏ đóng góp nên thành công này là nhờ
sự quan tâm, chỉ bảo, giúp đỡ của các thầy cô, các anh chị khóa trên và bạn bè xung
quanh.
Tuy đã có rất nhiều cố gắng và sự nỗ lực của các thành viên để hoàn thiện đề tài,
nhưng chắc chắn đề tài “NGHIÊN CỨU THỰC HÀNH CÁCH TẤN CÔNG
RETURN-TO-LIBC (RETURN-TO-LIBC ATTACK LAB)” của chúng em còn nhiều
thiếu sót. Chúng em rất mong nhận được sự góp ý từ các thầy giáo để nhóm em có thể
hoàn thiện tốt hơn các đề tài nghiên cứu sau.
Chúng em xin chân thành cảm ơn!

3
 LỜI MỞ ĐẦU
Ngày nay, với xu hướng chuyển đổi số mạnh mẽ của các doanh nghiệp, công ty, tổ
chức dẫn đến việc tạo ra những phần mềm quản lý, điều hành và làm việc cũng hết sức
thiết yếu. Bên cạnh đó, ảnh hưởng của đại dịch COVID-19 cũng đã thúc đẩy nhanh việc
chuyển đổi số. Để đảm bảo an toàn cho phần mềm khi tạo ra và vận hành tránh bị kẻ xấu
tấn công gây thiệt hại nghiêm trọng. Đó cũng là lý do để chúng em chọn chuyên đề
Software Security và đặc biệt là nghiên cứu cách tấn công Return-to-Libc.

4
 MỤC LỤC

LỜI CẢM ƠN.................................................................................................................. 3

LỜI MỞ ĐẦU.................................................................................................................. 4
MỤC LỤC........................................................................................................................5
CHƯƠNG I: TỔNG QUAN VỀ RETURN-TO-LIBC ATTACK LAB....................6
1.1. Tổng quan mục tiêu, giới thiệu và nhiệm vụ của lab............................................6
1.2. Tổng quan về lý thuyết.........................................................................................6
CHƯƠNG II: CÀI ĐẶT MÔI TRƯỜNG THỰC HIỆN............................................7
1.1. Chuẩn bị cho bài Lab............................................................................................7
1.2. Cài đặt môi trường ảo Ubuntu v16.04 của SEED Labs.......................................10
CHƯƠNG III: TIẾN HÀNH THỰC HIỆN VÀ NGHIÊN CỨU CHUYÊN SÂU
BÀI LAB THEO THỨ TỰ TỪNG TASK..................................................................15
3.1. Cài đặt thiết lập ban đầu để thực hiện bài lab......................................................15
3.1.1. Address Space Randomization (Ngẫu nhiên hóa không gian địa chỉ).................15
3.1.2. Configuring /bin/sh.............................................................................................15
3.1.3. The StackGuard Protection Scheme....................................................................15
3.1.4. Non-Executable Stack.........................................................................................16
3.2. Giới thiệu về chương trình chứa lỗ hổng............................................................16
3.3. Task 1: Tìm địa chỉ của hàm libc........................................................................18
3.4. Task 2: Đưa chuỗi shell vào bộ nhớ (Putting the shell string in the memory).....20
3.5. Task 3: Khai thác lỗ hổng tràn bộ đệm (Exploiting the Buffer-Overflow
Vulnerability)................................................................................................................ 22
3.6. Task 4: Bật tính năng ngẫu nhiên hóa địa chỉ (Turning on Address
Randomization).............................................................................................................27
3.7. Task 5: Vượt qua các biện pháp an toàn của Shell (Defeat Shell’s
countermeasure)............................................................................................................ 31
CHƯƠNG IV: KẾT LUẬN..........................................................................................33
TÀI LIỆU THAM KHẢO............................................................................................34

5
 CHƯƠNG I: TỔNG QUAN VỀ RETURN-TO-LIBC ATTACK
LAB

1.1. Tổng quan mục tiêu, giới thiệu và nhiệm vụ của lab
Mục tiêu học tập của lab này là để ta có được trải nghiệm trực tiếp về một biến thể
thú vị của tấn công tràn bộ đệm; cuộc tấn công này có thể bỏ qua một sơ đồ bảo vệ hiện
có hiện được triển khai trong các hệ điều hành Linux chính. Một cách phổ biến để khai
thác lỗ hổng tràn bộ đệm là làm tràn bộ đệm bằng một mã shellcode độc hại, và sau đó
khiến chương trình dễ bị tấn công nhảy đến shellcode được lưu trữ trong ngăn xếp. Để
ngăn chặn các kiểu tấn công này, một số hệ điều hành cho phép quản trị viên hệ thống tạo
các ngăn xếp không thể thực thi được; do đó, việc nhảy đến shellcode sẽ khiến chương
trình bị lỗi.
Thật không may, chương trình bảo vệ ở trên không phải là chống đánh lừa; tồn tại
một biến thể của tấn công tràn bộ đệm được gọi là tấn công return-to-libc, không cần
ngăn xếp thực thi; nó thậm chí không sử dụng shell code. Thay vào đó, nó làm cho
chương trình dễ bị tấn công đến một số mã hiện có, chẳng hạn như hàm system () trong
thư viện libc, đã được tải vào bộ nhớ.
Trong lab này, ta được cung cấp một chương trình có lỗ hổng tràn bộ đệm; nhiệm
vụ của ta là phát triển một cuộc tấn công return-to-libc để khai thác lỗ hổng và cuối cùng
là giành được đặc quyền root. Ngoài các cuộc tấn công, ta sẽ được thực hiện một số
phương án bảo vệ đã được triển khai trong Ubuntu để chống lại các cuộc tấn công tràn bộ
đệm. Ta cần đánh giá xem các chương trình có hoạt động hay không và giải thích tại sao.

1.2. Tổng quan về lý thuyết

Return to libc là một phương pháp khai thác lỗi tràn bộ đệm trên hệ thống có ngăn
xếp không thực thi được, nó rất giống với tràn bộ đệm tiêu chuẩn, trong đó địa chỉ trả về
được thay đổi để trỏ đến một vị trí mới mà chúng ta có thể kiểm soát. Tuy nhiên, vì
không có mã thực thi nào được phép trên ngăn xếp, ta không thể chỉ gắn thẻ trong
shellcode.
Vì lí do đó ta sử dụng thủ thuật return to libc và sử dụng một hàm được cung cấp
bởi thư viện. Ta vẫn ghi đè địa chỉ trả về bằng một trong các hàm trong libc, chuyển cho
nó các đối số chính xác và thực thi nó cho ta. Vì các hàm này không nằm trên ngăn xếp,
ta có thể bỏ qua bảo vệ ngăn xếp và thực thi code.

6
7
 CHƯƠNG II: CÀI ĐẶT MÔI TRƯỜNG THỰC HIỆN
1.1. Chuẩn bị cho bài Lab
Truy cập đường link: https://www.virtualbox.org/wiki/Downloads . Để tải và cài
đặt
Sau khi tải về thì chạy chương trình để cài đặt vào máy. Chọn Next

8
Tiếp tục , chọn Next và cuối cùng là chọn Install

9
Chọn Finish để kết thúc quá trình cài đặt. Bên dưới là giao diện sau khi cài đặt
hoàn tất

10
1.2. Cài đặt môi trường ảo Ubuntu v16.04 của SEED Labs
Truy cập vào trang web : https://seedsecuritylabs.org/labsetup.html . Chọn version
16.04 như hình bên dưới và tải về theo đường dẫn đính kèm

Ở đây em chọn đường dẫn của “Google Drive” . Sau khi tải xong chúng ta giải nén
file rar.

Quay lại với Oracle VM VirtualBox , Chọn New ,lựa chọn các cài đặt như hình
bên dưới và chọn Next.

11
 Chọn Next cho đến khi đến phần Hark Disk . Chọn vào “Use an exitsting virtual
hard disk file” và chọn vào icon được khoanh vùng đen.

Chọn Add

12
 Chọn đến đường dẫn lúc nãy vừa giải nén file Ubuntu v16.04 và chọn vào file bên
dưới nhấn Open

Sau khi chọn đường dẫn xong sẽ hiện giống như ảnh màn hình sau và click vào
“SEEDUbuntu-16.04-32bit.vmdk” và chọn Choose

Sau đó ấn Create

Chọn Start để tiến hành cài đặt bên trong .

13
Quá trình cài đặt hoàn tắt .

14
 Lưu ý : Khi đóng máy Ubuntu ảo . Các bạn nên chọn “Save the machine state” .
Để có thể lưu lại những gì mình đang làm.

15
CHƯƠNG III: TIẾN HÀNH THỰC HIỆN VÀ NGHIÊN CỨU
CHUYÊN SÂU BÀI LAB THEO THỨ TỰ TỪNG TASK

3.1. Cài đặt thiết lập ban đầu để thực hiện bài lab
Ubuntu và các bản phân phối Linux khác đã triển khai một số cơ chế bảo mật để
làm cho cuộc tấn công tràn bộ đệm trở nên khó khăn. Để đơn giản là các cuộc tấn công
của ta, trước tiên cần phải vô hiệu hóa các cơ chế bảo mật ấy.
3.1.1. Address Space Randomization (Ngẫu nhiên hóa không gian địa chỉ)
Ubuntu và một số hệ thống dựa trên Linux khác sử dụng Address Space
Randomization để ngẫu nhiên hóa địa chỉ bắt đầu của heap và stack. Điều này làm cho
việc đoán các địa chỉ chính xác trở nên khó khăn; đoán địa chỉ là một trong những bước
quan trọng của các cuộc tấn công tràn bộ đệm (Buffer Overflow). Trong lab này, ta tiến
hành tắt các tính năng này bằng các lệnh sau.
sudo sysctl -w kernel.randomize_va_space=0

3.1.2. Configuring /bin/sh

Thay đổi default shell từ “dash” thành “zsh” để tránh các biện pháp đối phó được
thực hiện trong “bash” cho các chương trình SET-UID.

3.1.3. The StackGuard Protection Scheme

Trình biên dịch GCC thực hiện một cơ chế bảo mật được gọi là Stack Guard để
ngăn chặn lỗi tràn bộ đệm. Khi có sự bảo vệ này, các cuộc tấn công tràn bộ đệm sẽ không
hoạt động. Ta sẽ tắt tính năng bảo vệ này trong quá trình biên dịch bằng cách sử dụng tùy
chọn -fno-stack-protectionor.

16
3.1.4. Non-Executable Stack
Ở cơ chế này chúng ta sẽ cung cấp tham số “-z execstack”. Khi cung cấp tham số
này, ngăn xếp trở nên thực thi được, sau đó cho phép mã của chúng ta được thực thi khi ở
trong ngăn xếp. Theo mặc định, ngăn xếp là không thể thực thi và hệ điều hành biết liệu
ngăn xếp có thực thi được hay không bằng một tập bit nhị phân trong hệ thống. Bit này
có thể được trình biên dịch thao tác và trình biên dịch gcc đặt ngăn xếp là không thể thực
thi (Non-Executable Stack) theo mặc định.
3.2. Giới thiệu về chương trình chứa lỗ hổng
Trong bài lab đã cung cấp cho ta một chương trình có chứa lỗ hổng buffer
overflow (lỗi tràn bộ đệm) tên là retlib.c. Xuyên suốt lab này sẽ dùng đến chương trình.

17
 Tiếp theo, ta tiến hành thực hiện các thao tác tắt các cơ chế bảo mật và biện pháp
đối phó của linux và kiểm tra xem ta có thể tấn công bằng chương trình lỗ hổng trên và
sử dụng thư viện libc để tấn công hay không?

Ta cần đảm bảo rằng ta sử dụng shell / bin / zsh dễ bị tấn công. Biện pháp đối phó
ngẫu nhiên địa chỉ bị tắt. Chương trình retlib.c đã cho được tạo là chương trình dễ bị tấn
công mà ta sử dụng ở đây và nó có sự cố tràn bộ đệm (buffer overflow). Ta vô hiệu hóa
tính năng StackGuard protection có sẵn và biên dịch chương trình retlib. Sau khi biên
dịch, chuyển chương trình được tạo thành chương trình UID thuộc quyền sở hữu của user
root.

18
3.3. Task 1: Tìm địa chỉ của hàm libc
Mục đích của task này là di chuyển đến mã hiện có đã được tải vào bộ nhớ và sử
dụng hàm system () và exit () khỏi thư viện libc cho cuộc tấn công.
Để tìm địa chỉ của bất kỳ hàm libc nào, ta có thể sử dụng các lệnh gdb sau (a.out là
một chương trình tùy ý):

Ta gỡ lỗi chương trình có lỗ hổng retlib và tạo một điểm ngắt trong hàm main. Khi
chương trình được chạy và đạt đến điểm ngắt, chương trình sẽ được chạy từng dòng một.
Từ các lệnh gdb, chúng ta có thể tìm ra rằng địa chỉ cho hàm system () là 0xb7637da0 và
địa chỉ cho hàm exit () là 0xb762b9d0. Các địa chỉ thực tế trong hệ thống của từng máy
có thể khác với số này. Đây là những địa chỉ được dùng cho cuộc tấn công.

19
 Kết luận: Do ta cần sử dụng địa chỉ của hàm system() và exit() trong thư viện libc
cho cuộc tấn công, ta có thể tìm thấy chúng bằng cách sử dụng trình GNU gdb debugger.

20
3.4. Task 2: Đưa chuỗi shell vào bộ nhớ (Putting the shell string in the
memory)
Mục đích của tác vụ này là đưa chuỗi lệnh ‘/bin/sh’ vào bộ nhớ và biết địa chỉ của
nó. Để đạt được điều này, ta tạo một biến shell mới có tên MYSHELL chứa chuỗi lệnh /
bin/sh.

Biến MYSHELL có chuỗi shell trong tiến trình con. Bây giờ chúng ta tạo chương
trình envShellString.c đã cho để lấy địa chỉ của biến trong bộ nhớ. Chương trình sau đó
được biên dịch và chạy với retlib để lấy địa chỉ của biến.

Tiếp theo, chúng ta sử dụng chương trình getenv.c để tìm địa chỉ của biến
MYSHELL. Ta tiến hành biên dịch và chạy chương trình này. Nó sẽ cho ta output chính
xác địa chỉ và phục vụ cho các tasks tấn công sau.

21
 Kết luận: Địa chỉ của biến shell được truyền dưới dạng biến môi trường cho tiến
trình con có thể được tìm thấy và được sử dụng cho cuộc tấn công để đưa một số chuỗi
tùy ý vào bộ nhớ của tiến trình con.

22
3.5. Task 3: Khai thác lỗ hổng tràn bộ đệm (Exploiting the Buffer-Overflow
Vulnerability)
Mục đích của task này là tạo ra nội dụng của badfile bằng cách cung cấp dữ liệu
nhị phân. Qua cách sử dụng objdump trong chương trình retlib, chúng ta có thể tìm ra các
giá trị của X, Y, Z. Các giá trị này được đặt trong chương trình exploit2.c.

Dưới đây, ta có thể thấy dòng thứ ba cho biết không gian được cấp cho hàm bof ()
là 0x18. Địa chỉ offset của hàm system () là 24. Địa chỉ exit() của hàm này cao hơn 4 so
với hàm system().

23
 Chương trình exploit2.c chứa đầy đủ địa chỉ của các hàm system(), exit(), và địa
chỉ /bin/sh. Địa chỉ của các hàm trên được xác định ở các task phía trên.

24
 Tiếp theo, ta tiếp tục biên dịch và chạy chương trình exploit.c này. Ta có thể nhìn
thấy root shell có thể được sinh ra.

Khi làm điều này, ta có đặc quyền root. Bây giờ, địa chỉ trả về của system (), buf
[32] được thay thế bằng 0, tham số của setuid (), không có chỗ cho exit (). Đây là lý do
tại sao nó trả về lỗi phân đoạn khi chúng ta thoát khỏi trình bao gốc.
Kết luận: Bằng cách biết địa chỉ của hàm System (), địa chỉ của hàm exit () và địa
chỉ của biến shell được gửi đến quy trình con dưới dạng biến môi trường và cả các giá trị
chỉ mục mảng (X, Y, Z) của chuỗi đệm, ta có thể khai thác chương trình dễ bị tổn thương
có vấn đề tràn bộ đệm.

25
Trường hợp tấn công 1:
Mục đích của task trường hợp này là để tìm ra địa chỉ của hàm exit(). Trong
chương ‘exploit.c’, ta đã đưa ra địa chỉ của hàm exit() như dưới đây.\

Ta tiến hành biên dịch và chạy chương trình exploit và ‘retlib’. Ta có thể nhận
được trình shell của root.

26
 Kết luận: Như chúng ta thấy trong hình trên, địa chỉ hàm exit() đã được đưa ra. Ta
có thể nhận thấy rằng địa chỉ của hàm exit() là không cần thiết để thực hiện của tấn công
vào người dùng. Root shell được tạo ra mà không cung cấp địa chỉ của exit().

Trường hợp tấn công 2:

Mục đích của task này là thay đổi tên tệp ‘retlib’ thành ‘newretlib’ và cố gắng tấn
công người dùng mà không thay đổi nội dung của ‘badfile’.

Ở đây ta thay đổi tên của chương trình từ ‘retlib’ thành ‘newretlib’ và chạy
chương trình exploit2 và chương trình ‘newretlib’. Chúng tôi nhận thấy rằng chúng tôi
gặp lỗi và ta không thể lấy trình root shell và tiến hành tấn công người dùng.
Kết luận: Ta không thể tấn công người dùng. Cuộc tấn công không thành công vì
bất cứ khi nào ta đổi tên tệp, địa chỉ của tệp sẽ bị thay đổi và chúng ta phải lặp lại toàn bộ
tác vụ đã thực hiện trước đó để tìm lại địa chỉ. Ở đây ‘retlib’ có một địa chỉ khác và
‘newretlib’ bây giờ có một địa chỉ khác được sử dụng trong task sắp tới.

27
3.6. Task 4: Bật tính năng ngẫu nhiên hóa địa chỉ (Turning on Address
Randomization)
Ta đã biết rằng tất cả các cuộc tấn công được thực hiện đối với người dùng là bằng
cách tắt tính năng ngẫu nhiên hóa địa chỉ, biện pháp đối phó và tắt bảo vệ StackGuard
trong khi biên dịch chương trình chứa lỗ hổng. Bây giờ ta tiến hành bật lại tính năng ngẫu
nhiên hóa địa chỉ và kiểm tra xem biện pháp bảo vệ này có hiệu quả chống lại cuộc tấn
công Return-to-libc hay không.

Sau khi ta bật lại biện pháp đối phó ngẫu nhiên địa chỉ, chương trình ‘exploit2’ và
‘newretlib’ vẫn có thể chạy được.
Kết luận: Lần này nó cho ra kết quả Segmentation fault. Điều này là do xảy ra tràn
bộ đệm nhưng địa chỉ của system (), exit () và / bin / sh luôn thay đổi. Vì vậy, ta không
thể giữ một địa chỉ chính xác. Đây là lý do tại sao cuộc tấn công không thành công. Thêm
nữa, các giá trị X,Y và Z không thay đổi chỉ có địa chỉ của chúng bị thay đổi.
Khi ta bật ngẫu nhiên địa chỉ, ta chạy chương trình biến chuỗi shell mà ta đã tạo
trong task 2 để tìm ra địa chỉ của shell. Khi ta cho chạy đi chạy lại vài lần, mỗi lần chạy
sẽ cho một kết quả ngẫu nhiên.

Ta tiếp ta tiến hành gỡ lỗi ‘newretlib’ bằng trình gỡ lỗi ‘gdb’ để kiểm tra xem
ngẫu nhiên hóa địa chỉ có còn hiệu quả hay không.

28
 Khi kiểm tra xem ngẫu nhiên hóa địa chỉ có bị vô hiệu hóa hay không và nó cho
biết rằng nó đã bị vô hiệu hóa và ngẫu nhiên hóa địa chỉ sẽ tự động tắt sau khi trình gỡ lỗi
‘gdb’ được sử dụng.

29
 Ta tạo một điểm breakpoint trong hàm chính và chạy chương trình từng dòng sau
đó. Chúng tôi kiểm tra địa chỉ hàm system () và địa chỉ hàm exit () như dưới đây.

Tính năng ngẫu nhiên hóa địa chỉ được bật lại trong ‘gdb’ hoặc ta có thể nói rằng
tính năng ngẫu nhiên hóa vô hiệu hóa đã bị tắt. Sau đó, ta tạo một điểm breakpoint trong
hàm main () và chạy lại từng dòng chương trình để kiểm tra những gì đã thay đổi trong
các địa chỉ.

30
 Ta thấy địa chỉ hàm system () và địa chỉ hàm exit () đã thay đổi.

Kết luận: Ta nhận thấy rằng, ngay cả khi ta đã cố gắng trước đó để bật ngẫu nhiên
địa chỉ thành trong hệ điều hành, ‘gdb’ theo mặc định sẽ vô hiệu hóa ngẫu nhiên địa chỉ.
Ta phải tắt đặc biệt tính năng vô hiệu hóa ngẫu nhiên trong ‘gdb’ để duy trì biện pháp đối
phó ngẫu nhiên hóa địa chỉ.

31
3.7. Task 5: Vượt qua các biện pháp an toàn của Shell (Defeat Shell’s
countermeasure)
Đối với task này, trước tiên ta phải tắt ngẫu nhiên địa chỉ (address randomization).
Và sau đó liên kết /bin /sh với /bin/dash bằng lệnh sudo ln -sf /bin/dash /bin/sh.

Một số chương trình shell, chẳng hạn như dash và bash, có một biện pháp đối phó
là tự động loại bỏ các đặc quyền khi chúng được thực thi trong một quy trình Set-UID. Vì
vậy, với /bin/sh được liên kết với /bin/dash, ta không thể thực hiện khai thác lỗ hổng. Khi
chạy chương trình ‘newretlib’, một trình shell được tạo ra nhưng không phải là trình root
shell.

Để giải quyết vấn đề này, chúng ta cần gọi hàm setuid (0) trước khi gọi hàm
system (). Chúng ta có thể lấy địa chỉ của setuid () từ gdb giống như cách chúng ta lấy địa
chỉ của system () và exit (). Trên gdb, chúng ta có thể chạy p setuid để lấy địa chỉ của
setuid().

Bây giờ, ta biết rằng tham số của setuid () phải ở địa chỉ $ ebp + 8. Bây giờ ebp trỏ
đến 20, tham số, 0 phải ở 28 29 30 và 31 địa chỉ làm cho buf [32] = 0. Ta đặc biệt lấy 0
làm tham số vì uid = 0 đại diện cho người dùng root.

32
 Theo ta thấy tại đây, tại 24, setuid () được gọi, tham số của nó ở độ lệch 8, tức là
32. Sau đó, địa chỉ trả về trở thành 28, nơi chúng ta có thể gọi system () có tham số sẽ ở
độ lệch 8, tức là 36.
Khi làm điều này, ta có đặc quyền root. Bây giờ, địa chỉ trả về của system (), buf
[32] được thay thế bằng 0, tham số của setuid (), không có chỗ cho exit (). Đây là lý do
tại sao nó trả về lỗi phân đoạn khi chúng ta thoát khỏi trình bao gốc.

33
 CHƯƠNG IV: KẾT LUẬN
Mục tiêu học tập của lab này là để ta có được trải nghiệm trực tiếp về một biến thể
thú vị của tấn công tràn bộ đệm; cuộc tấn công này có thể bỏ qua một sơ đồ bảo vệ hiện
có hiện được triển khai trong các hệ điều hành Linux chính. Một cách phổ biến để khai
thác lỗ hổng tràn bộ đệm là làm tràn bộ đệm bằng một mã shellcode độc hại, và sau đó
khiến chương trình dễ bị tấn công nhảy đến shellcode được lưu trữ trong ngăn xếp. Để
ngăn chặn các kiểu tấn công này, một số hệ điều hành cho phép quản trị viên hệ thống tạo
các ngăn xếp không thể thực thi được; do đó, việc nhảy đến shellcode sẽ khiến chương
trình bị lỗi.

34
 TÀI LIỆU THAM KHẢO

[1] firmianay, "return-to-libc-attack-lab.md," [Online]. Available:

https://github.com/firmianay/Life-long-Learner/blob/master/SEED-labs/return-to-libc-
attack-lab.md.
[2] li-xin-yi, "Return-to-libc-Attack," [Online]. Available: https://github.com/li-
xin-yi/seedlab/tree/master/Return-to-libc-Attack.
[3] W. Du, "Return-to-libc Attack Lab," [Online]. Available:
https://seedsecuritylabs.org/Labs_16.04/Software/Return_to_Libc/.

35