system call의 동작 내부구조에 대해서 알아보자.. 일단 기본적인 시스템 콜 동작은 다음과 같다. user mode에서 software interrupt 발생 kernel mode로 넘어가서 system call 실행 실행 완료 후 다시 user
Sandbox?취약점 자체를 보호한다기 보단, 공격받을 수 있는 표면적 자체를 줄이는 기법Allow list, Deny list가 존재하여 꼭 필요한 시스템 콜, 파일 접근등을 허용한다.SECCOMP?SECure COMPuting mode의 약자.Sandbox 매커니즘
앞서 SECCOMP가 무엇이고, 어떤 식으로 동작하는지에 대해서 간단히 알아보았다.그러면 이 SECCOMP가 실제로 어떻게 적용되어 있고, 이를 우회하는 방법에 대해서 알아보자.seccomp-tools를 사용해서 확인한다. 다음은 그 예시이다 :struct sock_f
구조체 결국 은 의 typedef였다. 변수는 open된 상태를 저장하는 플래그이다. 앞 2바이트는 매직넘버 0xfbad로 고정되고, 뒤의 2바이트가 플래그의 의미로써 사용된다. 플래그의 값들은 다음과 같다. 변수를 보면 리스트 형태로 다른 구조체들과도 연결됨을 알
fopen 함수의 소스코드를 보자.\_IO_new_fopen내부적으로 \_\_fopen_internal을 호출한다.\_\_fopen_internal사실상 여기부터 제대로 된 함수가 시작된다.우선, struct locked_FILE 구조체를 할당하는데,
앞서서 FILE 구조체, fopen함수에 대해서 알아보았다.이번에는 이어서, 실제로 파일을 읽고 쓰는 함수인 fread, fwrite 중 fread에 대해서 알아보도록 하자.딱 한 번만 매크로를 쭉 따라가서 어느 함수가 호출되는지 확인해보자.굉장히 길 것 같은 느낌..
이번에는 fwrite함수를 알아보자.\_IO_sputn인줄 알았지만 fread의 경우와 같이 엄청난 매크로를 거쳐서 \_IO_new_file_xsputn을 호출하게 된다.\_IO_new_file_xsputnfwrite의 경우는 fread와 다르게 버퍼가 가득 차면 fl
뭔가 fclose니까 할당 해제, 초기화와 관련된 것들만 다 해주고 끝날 것 같다.자세히 알아보자.당연히 그냥 불러올 리가 없다. 매크로에 의해 \_IO_new_fclose를 호출하게 된다.\_IO_IS_FILEBUF가 설정되어 있다면 \_IO_un_link를 하게 된
앞서 지나갔던 내용인"실제로 수많은 매크로를 통해 vtable에서 함수가 호출되는 과정은 어떻게 될까?"에 대해서 알아보도록 하겠다.앞서 fread함수 분석 글에서 확인하려다가 실패(?) 한 매크로들이다.하나하나 천천히 따라가 보자.그림으로 나타내면 다음과 같다.확실히
함수 코드는 다음과 같다. 만약 vtable 값이 section을 벗어나지 않는다면 함수는 종료되고, 벗어난다면 함수가 실행된다. 함수까지 분석하기에는 너무 간 것 같아서 하지 않고 넘어간다. 대신, section 안에 존재하는 공격가능한 함수를 찾은 후,
fgets 함수이다. 이름에서부터 알 수 있듯이, 파일에서 데이터를 get 하는 함수이다. 소스코드는 다음과 같다. 함수도 복잡하지 않다. 바로 함수를 호출하는 것을 알 수 있다. 바로 살펴보자. 만약 len <= 0 이라면 를 호출하는 것을 알 수 있다. 앞의
exploit을 진행할 때 간혹 잘못된 것이 없는데도 segmentation fault가 발생하는 경우가 있다.이 때에는 stack alignment를 의심해 봐야 한다.함수 실행 전에 rsp가 16의 배수로 존재해야 한다.함수를 실행시킬 때에는 일반적으로 call 명
리눅스에서는 malloc을 통해서 메모리 할당을 할 때에 내부적으로 ptmalloc이라는 함수가 실행된다. 앞으로 편의를 위해 malloc으로 지칭할 것이다.목표1\. 메모리 낭비 방지2\. 빠른 메모리 재사용3\. 메모리 단편화 방지말 그대로 덩어리라는 뜻.mallo
prototype & 기본 변수들 prototype size : chunk의 크기 mp_ 구조체 mp_ malloc과 관련된 여러 상수값들이 저장되어 있다. tcache tcacheentry & tcacheperthread_struct tcacheentry
배경지식 여러 thread를 통해 multiprogramming이 가능하다. 이 때, 각 thread는 서로 다른 실행 흐름을 가져야 하므로 각자가 하나의 stack을 가지게 된다. 물론 전역변수 영역, heap 영역은 공유를 한다. 이 때, thread별로 내부적으로
풀면서 몇 가지 배운 점을 나열하도록 하겠다.p/x $fs_base를 한 결과와 vmmap을 한 결과를 비교해 보면,libc가 매핑된 주소 바로 아래에 fs_base가 위치해 있음을 알 수 있다.즉, libc 바로 아래에 TCB, static TLS가 위치해 있는 것이
리눅스에서는 signal이 발생했을 경우, 해당 signal에 대한 handler 함수가 존재한다면 해당 함수로 context가 바뀌고, 그 handler 함수가 종료되고 나면 다시 원래 context로 돌아오게 된다.user mode에서 kernel mode로의 전환