CSAPP 3.10 Combining Control and Data in Machine-Level Programs

📝 상세 정리

#

• 데이터와 머신레벨 코드를 지금까지 따로 살펴보았다
  • 이제부터는 합쳐서 확인해보자
  • 이건 포인터 단위로 공부할 것이다.
  • 버퍼 오버플로우도 연구해보자
  • 스택 저장량이 실행마다 다를 수 있는 경우? 를 확인해보자
• 3.10.1 Understanding Pointers
  • 모든 포인터는 associated type이 있다.
    • 어떤 object를 가리키는지 나타내는 것
  • 객체가 타입 T를 갖는 경우, T의 포인터는 타입 *T를 갖는다.
    • 타입 *T의 포인터는 **T이다.
    • 그냥 * 라고 쓰면 일반 포인터를 반환한다.
    • 이 포인터 유형은 기계코드의 일부는 아니지만, 오류를 방지하기 위해 C가 제공하는 추상화임
  • 모든 포인터의 값은 일부 객체의 주소를 가리킨다
    • NULL(0)일때 빼고 (아무데도 가리키지 않음)
  • 포인터는 &연산으로 생성된다
    • 기계코드에서는 주로 leaq로 나타내지더라
  • 포인터는 *연산으로 역참조된다.
    • 지정된 주소로 저장하거나 지정된 주소로부터 검색한다.
  • 배열과 포인터는 밀접한 관련이 있다.
    • 배열의 이름은 마치 포인터 변수인 것처럼 참조된다.
  • 포인터를 캐스팅할 때, 그 유형은 바뀌지만 그값은 바뀌지 않는다.
    • 하지만 스케일링을 바꿀 순 있다
    • EX) p가 char * 유형의 포인터인 경우
      • (int *) p+7은 p+28을 계산하고, (int *) (p+7)은 p+7을 계산한다.
  • 포인터는 함수를 가리킬 수도 있다.

    •   int fun(int x, int *p);
        int (*fp)(int, int *); fp = fun;
        int y = 1;
        int result = fp(3, &y);

  • 함수 포인터의 값은 함수의 기계코드 표현에서 첫번째 명령어의 주소이다.
• 3.10.2 Life in the Real World: Using the GDB Debugger
  • gdb는 GNU 디버거
  • ㅋㅋ bomb lab 풀면서 이미 써봤지롱
• 3.10.3 Out-of-Bounds Memory References and Buffer Overflow
  • C는 배열 참조에 대한 임의의 경계 검사를 수행하지 않는다
    • 저장된 레지스터값
    • 반환 주소와 같은 상태 정보
    • 로컬 변수
    • 이 모든것들이 스택에 저장된다
  • 근데 이건 심각한 프로그램 오류를 초래할 수도 있다!!
    • Out of bound 배열 요소에 작성하는것으로!
    • 그리고 이상태로 레지스터를 다시 가져오거나 ret 명령어를 하려고 하면 터질 수 있다.
  • 이런걸 Buffer Overflow라고 한다.
    • 문자열을 유지하기 위해 스택 상에 일부 문자 배열에이 할당되지만, 그 크기가 넘어간 경우

  • char *gets(char *s){
        int c;
        char *dest = s;
        while((c = getchar()) != '\n' && c != EOF) *dest++ = c;
        if(c == EOF && dest == s) return NULL;
        *dest++ = '\0';
        return s;
    }
    
    void echo(){
        char buf[8];
        gets(buf);
        puts(buf);
    }

    • 이런 코드가 있다고 하자! 그런데 이 코드는 입력이 크기인 8을 넘는지 안넘는지 알 수 있는 방법이 없다….
    • 어셈블리로도 봐볼까?

  •     void echo()

  1 echo: 2 subq $24, %rsp Allocate 24 bytes on stack 3 movq %rsp, %rdi Compute buf as %rsp 4 call gets Call gets 5 movq %rsp, %rdi Compute buf as %rsp 6 call puts Call puts 7 addq $24, %rsp Deallocate stack space 8 ret Return ``` - 스택 포인터에서 24를 빼서 할당하고, 맨위에 저장하고.. - rsp를 rdi에 적어놔서 gets / puts 둘다에도 쓸 수 있게 하고 - buf가 그러면 8바이트를 쓰니까, 뒤에 16바이트는 안쓴다. - 사용자가 7개 문자 입력 (종료문자열까지 8개) 까지는 문제가 없겠지만… 이를 넘어가면? - 0-7: buf에 잘 들어감 - 9-23: 비어있는 스택공간 - 24-31: Return address - 32+: caller에 저장된 값들
  • 버퍼 오버플로우는 버그가 터지는것도 문제지만..
    • 원하지 않는 행동을 마음대로 할 수 있다면?
    • 이것이 컴퓨터 네트워크를 통해 시스템의 보안을 공격하는 가장 일반적인 방법
    • 이를 Exploit code라고 한다.
  • 뭐 암튼 보안을 잘해야한다는 이야기
• 3.10.4 Thwarting Buffer Overflow Attacks
  • 버퍼 오버플로우가 문제가 되니까 현대 컴파일러와 운영체제는 이를 막는 메커니즘을 구현하기 시작했다
  • Stack Randomization
    • 시스템 내에 익스플로잇 코드를 삽입하기 위해서 공격자는 코드에 대한 포인터뿐만 아니라 코드 모두를 주입해야함.
    • 또한, 해당 문자열이 들어갈 스택/메모리 주소도 알아야된다!!
      • 역사적으로, 이는 예측 가능성이 높았다.
      • 공격자가 공통 웹서버에서 사용하는 스택 주소를 찾았다면?
        • 많은 머신에서 작동하는 공격을 만들 수 있었다.
    • 그러니까, 스택의 위치를 각 프로그램의 실행마다 다르게 하자.
      • 많은 머신이 같은 코드를 실행하더라도, 모두 상이한 스택 주소를 사용할 것이다.
      • alloca함수같은걸 이용해서 프로그램 시작시 스택상에 랜덤한 값을 할당한다
        • 이 값은 충분한 변동을 얻을수 있을정도로 커야하지만, 낭비하지 않을만큼 작아야하는.. 당연한말
    • 간단하게는 이렇게 확인 가능하다

    • int main(){
          long local;
          printf("local at %p\n", &local);
          return 0;
      }		   
      

      • 이렇게 하면 언제나 같은 값을 가지지 않음을 확인할 수 있다.
    • 이는 현재 리눅스 시스템에서 표준 관행이다.
    • 하지만 이는 어느정도의 공격을 막을 수는 있지만
      • 공격자가 정말 힘내면 다른 주소를 가진 공격을 반복적으로 시도해서 브루트포스로 극복 가능하다.
  • Stack Corruption Detection
    • 스택이 손상되었을 때를 감지하면 되지 않을까?
      • echo함수는 local buffer의 경계를 초과할 때 터졌었다
      • C에서는 배열의 경계를 넘어서 쓰기를 방지할 수 있는 좋은 방법이 없다.
      • 대신 프로그램은 그러한 쓰기가 어떠한 해로운 영향을 미치기 전에 뭔가가 발생한적 있는지를 검사할 수 있다.
    • 이는 버퍼 오버런을 검출하기 위해 생성된 코드에 스택 보호자로 알려진 메커니즘을 통합한다 (?)
      • 임의의 로컬 버퍼와 나머지 스택들 사이에 특별한 canary 값을 지정하는 것
        • 이는 guard값이라고도 하며, 프로그램이 실행될 때마다 무작위라서 공격자가 그것이 무엇인지 쉽게 결정할 수 없다.
    • 레지스터를 복원하고 돌아가기 전에, 프로그램은 이 canary가 변경되었는지 안됐는지 확인한다.
      • 아하, 예전에 bomb lab에서 봤던 %fs:40이 이거였구나!!!
  • Limiting Executable Code Regions
    • 공격자가 실행 가능한 코드를 시스템에 삽입하는 능력을 제거하는 것
      • 그중 한가지 방법은 실행 가능한 코드를 메모리 영역에 저장하는것을 제한하는 것
        • 예를 들어, 컴파일러에 의해 생성된 코드가 있는 부분만 실행 가능하게 하고, 나머지 부분은 읽기 및 쓰기만 허용하도록 제한할 수 있겠다.
        • 가상 메모리공간은 페이지당 2048 / 4096바이트임. (9장에서 배울 것)
        • 하드웨어는 프로그램 / 운영체제 등한테 액세스 형태를 지정하는 메모리 보호를 지원함
        • 많은 시스템들은 읽기 / 쓰기 / 실행에 대한 제어를 허용한다.
          • 역사적으로 x86은 읽기 및 실행을 1비트 플래그로 병합하여, 읽기가 가능하면 실행도 가능했다.
            • 스택쪽도 읽어야하기때문에 스택의 바이트도 실행이 가능했다
          • 하지만 이제 64비트 프로세서에서는 AMD도 인텔도 이를 분리하기 시작햇다.
  • 이 세가지 기술들은 프로그래머의 노력도, 수행 오버헤드도 적다.
  • 개별적으로 취약성 수준을 낮추고, 조합해서 더 좋기도 하다.
  • 하지만 불행히도 컴퓨터를 공격하는 방법들은 여전히 존재하고, worm과 바이러스들은 계속 공격해나간다.
• 3.10.5 Supporting Variable-Size Stack Frames
  • 지금까지는 컴파일러가 스택에 얼만큼을 할당해야하는지 미리 결정할 수 있었다.
    • 하지만 일부 기능은 요구하는 스택 메모리의 양이 달라질 수 있다!
      • 예를들어, alooca 등의 임의 크기의 바이트를 스택에 할당하는 거라던지,
      • 가변 크기의 로컬 어레이를 선언하던지
  • 따라서, 나중에 함수로 돌아갈때 스택 포인터의 위치가 어디였는지를 기억하기 위해, 이를 프레임 포인터마냥 %rbp에 저장해두자!!
    • 그러면 %rsp가 얼마나 크더라도 함수 return시 어디로 돌아가야하는지는 확실하다.
    • 이건 기계코드에 leave라고 있다.

❔질문 사항

#

• 왜 8바이트가 아닌 24바이트를 땡겼지?
  • -> 16바이트 단위로 rsp를 맞추기 위해
• Stack Randomization, Stack Canary 모두 컴파일 시간에 결정된거 아닌가? 랜덤값이?
  • 같은 컴파일된 바이너리파일을 실행하면 결국 일어나는일은 언제나 같은건가?
    • -> ㄴ.ㄴ fs:40같은데 들어이있는 값은 맨날 다르다
  • 그래도 RNG같은 코드가 박혀있는거 아닌가?
    • -> 맞긴 한데, 간단한 rand()급이 아니고 마우스 움직임 / 하드웨어 인터럽트등 다양한 불규칙적 신호들을 모아서 무작위화한다.
    • 스택에서 printf같은걸로도 못읽게 첫번째 바이트를 0x00(NULL)로 설정해서 문자열 함수 등도 방어한다!

🔗 참고 자료

#

• CSAPP