| 램깍는노인 |
그동안 계속 이문제를 가지고 여기저기 찾아보고 고민해가면서 이유가 뭘까 생각을 해보았는데 대충 실마리를 찾았습니다. 나중에라도 저와 같은 문제로 고민하고 잠못드는 분들이 있으실까봐 저도 아직 완전히 이해하지는 못했지만 그 실마리를 남겨볼까하고 이 글을 씁니다. 실마리는 프로세스 였습니다. 프로세스는 보조기억장치에 저장된 프로그램이 주기억장치인 메모리로 복사되어 생성되는 인스턴스와 같은 의미이고 이 프로세스가 (text-data-bss-heap-stack)으로 이루어진 메모리 영역을 할당받습니다. 컴퓨터를 키게 되면 태초의 프로세스 init이 실행되고 이 프로세스로부터 fork()함수를 통해 init프로세스가 가지고 있는 메모리 영역을 복사하여 복사본을 만든후 exec계통의 함수를 통해 새로운 프로그램의 프로세스를 덮어 씌우는 방법으로 각종 프로세스를 생성합니다. 본래의 프로세스를 부모 프로세스라 하고 새로 복사되어 생성된 프로세스를 자식 프로세스라 합니다. (자식 프로세스또한 어떤 프로세스의 부모 프로세스가 될 수 있습니다.) 이러한 방법으로 모든 프로세스가 생성되는데 이때 fork함수로 생성되는 자식프로세스가 부모 프로세스로부터 복사해서 그대로 가져오는것이 몇개 있습니다. 그것은 스택, 열린 파일기술자, 환경변수을 포함한 몇개가 있습니다. exploit_notesearch.c프로그램을 보면 system()명령으로 공격 버퍼를 notesearch 프로그램에 흘려보내는데 여기서 system()함수는 내부에 fork()함수로 새로운 프로세스를 생성하고 자식프로세스에 execl()함수로 프로세스를 덮어씌운다음 본래 부모 프로세스를 자식 프로세스가 종료될때까지 기다리게 합니다. 즉, notesearch 프로그램의 프로세스는 exploit_notesearch프로그램의 자식 프로세스이므로 exploit_notesearch의 스택도 그대로 가져옵니다. 따라서 변수 i또한 notesearch의 스택 어딘가에 잡혀있고 그 이후로 notesearch에서 선언하는 searchstring은 exploit_notesearch의 i보다 더 낮은 stack의 주소에 자리잡게 됩니다. 그래서 이것이 주소를 찾을 때 i를 기준으로 offset만큼 주소를 감소시켜 나가며 공격버퍼의 NOP SLED를 찾는 이유입니다. 아직 프로세스나 쓰레드쪽은 배우지 않아서 저도 이부분에 대해서 최근 2주동안 이리저리 찾아보며 습득한 지식이라 부족한 부분이 많이 있습니다. 하지만 누군가 저와 같은 고민을 할 때 실마리가 될 수 있을 것 같아 이렇게 글을 남깁니다. 감사합니다. |
2013/07/22 |
|
1574, 
1/79 
