1. intro다른 팀원이 문제를 푼 상태에서, 커널 문제라 공부 겸 풀어본 문제.쓸데 없는 파일들은 왜이리 많이 주는건지 -_- 2. code 및 분석2.1. code#include #include #include #include SYSCALL_DEFINE2(naup, void __user *, kaddr, const char __user *, str) { char buf[8]; if ((char *)kaddr != modprobe_path) { printk(KERN_INFO "naup syscall: Invalid address!\n"); return -EPERM; } if (copy_from_user(buf, str, 8)) { print..

1. intro거의 다 푼 상태에서 다른 팀원이 먼저 풀었고, 그게 퍼블이었다;; 2. code 및 분석2.1. code생략2.2. 분석단순 rop이긴 한데, 가운데 canary마냥 check되는 부분이 있다. 3. 취약점 확인 및 공격 준비3.1. 취약점bof3.2. 공격 준비그냥 bof가 발생한다.다만 중간 즈음 값이 0인지 확인하는 부분이 있으며, read로 값을 받기 때문에 그냥 우회 가능하다.더불어 no pie이고, 입력값을 출력해줄 때 가운데 0 때문에 leak이 원활하지 않는데,코드 내에 syscall이 존재하기에 그냥 bss에 main 함수 주소와 /bin/sh 문자열을 쓰고,bss를 rsp로 stack pivot한 뒤 syscall 했다. 4. exploitfrom pwn import ..

서론CTF에서 나와서 조금 더 공부해보는 글. modprobe_path우선 modprobe라는 프로그램은 커널에 로드 가능한 모듈을 추가하거나 제거하는데 사용하는 프로그램이다.다만, 여기서 만일 알 수 없는 형식의 파일이 실행되면 modprobe_path 경로의 프로그램이 root 권한으로 실행된다.즉, modprobe_path의 값을 조작할 수 있다면 임의의 프로그램을 실행할 수 있다는 것이다.또한 modprobe_path의 값은 writable 영역에 전역변수로 설정되어 있기에 매우 취약하다. exploit - before patch생각보다 꽤 간단하다.만일 aaw가 가능한 상황이라면 종전의 payload는save state -> prepare_kernel_cred -> commit_cred -> ..

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

서론포너블 빡침의 1순위를 꼽자면 아무래도 로되리안이다.거기서 조금 더 나아가자면 도되리안까지 걸려버리면 사람이 아주 미쳐버린다.최근 한 문제를 풀다가 그런 상황이 발생하였고, 해결 방법을 찾아냈기에 아래와 같이 기록해둔다. 왜 발생하는가.기본적으로 로되리안의 발생 이유는 glibc 버전이다.즉, 버전에 따른 함수나 gadget의 offset이 맞지 않아 발생하는 것이다.도되리안의 경우 여기에 시스템의 환경이 추가된다.즉 stack offset 또한 차이가 나게된다. 해결방법 - patchelflibc 및 ld 파일을 교체해주면 통상적으로 대부분 해결된다.2022.07.28 - [Tips & theory] - 문제에서 제공된 libc 파일 사용. 문제에서 제공된 libc 파일 사용.offset을 찾는 것..

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.