이 영상에서는 오렌지 하우스 1단계를 보여드리겠습니다
네 이 단계는 생략될 수 있어요 적절한 벌레가 있다면요 하지만
이 기술의 아름다움을 보여 주는 데 도움이 될 거예요
배우게 되겠죠 풀하우스 오브 오렌지 출간됐을 때처럼요
네 1단계에서 시작하니 취약한 바이너리를 알아두면 좋겠죠 '오렌지 디렉터리'로
검색하면 하우스 오브 오렌지 바이너리와 일치하는 pwntools 템플릿이 나옵니다
,
네 체스섹에 따르면 이진법은 렐로 스택 카나리아 NX로 컴파일됐고 위치 독립 상태입니다
글리벡 버전 2와도 연결되어 있어요 23번째 글립크의 초기
버전입니다
네 1단계는 물론 이 바이너리에 어떤 버그가 있느냐에 달렸죠
gdb에 로드해 실행해
우리가 다루는 게 뭔지 알아보죠
네 기술에 집중할 수 있게 libc와 누출이 둘 다 있고 평소와 약간 다른
선택지가 제공됩니다
네 옵션 1은 "작은" 덩어리 둘을 요청할 수 있고 그 옵션을
선택하면 사이즈가 안 나옵니다 ? 바이너리가
이미 선택했어
GDB 분석과 네 , "2차 세계
대전"
보세요 이제 0x20 크기의 덩어리는 특별할 게 없어요 나중에 보면 덩어리의 크기가 중요하지
않다는 걸 알게 될 거예요
네 네 항로에서 너무 벗어나지 않도록요
다음 조치를 생각할 때요 맞습니다 생산 쌍성은 사용자에게 말로크에게 요청하는
크기와 횟수를 통제할 수 있게 합니다
옵션 2 옵션 2는 하나의 '큰' 덩어리를 요청합니다 이 경우 큰도 상대적인 용어죠 gdb를
깨서 프로그램이 무엇을 큰 덩어리로 생각하는지 알아낼 수 있습니다
이번에는 '힙' 명령을 내립니다 , 네 'heap'은 디폴트 힙의 요약을 프린트합니다
다른 힙도 프린트할 수
있습니다 큰 덩어리로 힙의 개요를 보여주는데 좋습니다
'비스'는 적합하지 않습니다
출력을 보면 0x20 덩어리가 할당된 걸 알 수 있습니다 0xfd0 크기의 덩어리가 할당됐어요
이 아키텍처에 관한 한 페이지가 안 되죠
다시 말하지만 이 정도 크기는 특별한 점이
없습니다 말똥가리의 특정 행동을 촉발할 정도로 클 뿐이죠 잠시 후 그 모습을 보여 드리겠습니다
마지막으로 옵션 3은 할당된 첫 번째 작은 부분을 편집할 수 있게 해줍니다
큰 부분 전후에 말이죠
네 쓰레기
데이터를 입력할 거예요 더미를 조사하니 그 데이터가 첫 번째 작은 덩어리의 사용자 데이터에
쓰였더군요
이번에는 '타겟' 옵션이 없다는 걸 알 수 있을 겁니다
명심하세요 네 그걸 목표로 삼을 거예요 그게
우리 목표예요
좋아요 영상을 멈추고 오렌지 하우스를 살펴보고 버그가 있는지 확인해
주세요
네 다 하고 나면 여기로 돌아와서 이 바이너리를 어떻게 활용할지 생각해 보죠 안 돼요
벌레를 찾았다면
잘했어요
아니라면, 이 바이너리에 'edit' 옵션에 힙 오버플로 버그가 있습니다
네 'edit'을 선택해 0x20 크기의 데이터를 너무 많이 보내면 GDB로 들어가 'dq'와 'mp_트릭'으로
힙을 검사하면 데이터가 첫 번째 0x20 덩어리에서 다음 덩어리로 넘쳐나는 걸 볼 수 있죠 ,
보세요
216바이트까지 입력돼 있어요
현실성을 논할 수도 있겠죠 다양한 버그를 통해 같은 결과를 얻을 수도 있지만
이 버그는 우리가 기술을 익히도록 단순화합니다
그럼 이 넘친 물을 어떻게 활용할지 생각해 보죠
네 여기서 사용한 방식은 다른 두 덩어리의 크기 필드를 덮어쓰기 할 수 있게 해줍니다
네 하지만 말록이 어떻게든 치료해 주지 않으면
소용없어요 들판 크기를 바꿨는데 말록이 할 수 있는 건 공짜밖에 없어요
네 네 그럼 이런 의문이 들죠 오렌지 하우스 2단계가 무체계적 빈 공격으로
자유로운 덩어리가 필요하다면 애초에 덩어리를 못 분리하면
무체계적 빈 공격을 어떻게 활용하죠? ?
1단계에서 그 답을 찾을 거예요
우리... 우리 넘치는 물을 이용해서 말로크와의 통화만으로 큰돈을 벌어야 해요
네 다른 덩어리를 덮어씌워도 소용없어요
제일 큰 덩어리를 덮는 수밖에 없어요
네 힘의 집에서는 제일 큰 덩어리를 덧칠해서 큰 가치를 얻었죠 여기선
소용없어요 비슷한 크기의 세 덩어리로 제한돼 있거든요
하지만 작은 가치로 바꾸면 어떻게 될까요?
맞아요 답을 찾으려면 멀록이 너무 큰 주문을 받으면 어떻게 하는지 알아야 해요 경기장 통이나
윗부분에서 받을 수 없는 거죠
우선 요청에 부합할 만큼 충분한 메모리를 얻으려고 할 겁니다
일반 경기장은 사전 매핑 힙 메모리의 승인을 변경해 이걸 해내지만
주 경기장은 다르게 합니다
네 brk를 깨웁니다 시스칼이 핵심에서 더 많은 메모리를 요청합니다 말록은 맨 위쪽에 있는 덩어리 크기의
밭을 이용해 이 더미 끝부분에 이어진 기억의 위치를 파악합니다
맞아요 그렇다면 말록이 맨 위 공간을 확장해서 더 큰 공간에서 할당량을
채우는 거죠 ?
하지만 만약 우리가 작은 값을 가지고 상단 덩어리의 영역을 덮어쓴 후에 이런 일이 발생한다면
어떻게 될까요?
네 큰 요청이 들어오면 말록은 전과 마찬가지로 brk 시스칼을 통해 더 많은 기억을 요청합니다 ???? 하지만
말록은 새로운
기억이 무더기의 끝이 아니라고 생각하는 듯합니다 맞아요 그런 일이 벌어지면 말록은 알갱이가
이 무더기에
대한 연계된 기억을 그릴 수 없다고 추정합니다 어쩌면
공간이 부족해서 새
기억 무더기가 더 커졌고 말록이 거기에 새 무더기를 만들었을지도
모르죠 네 이렇게 하는 거예요 메인 경기장의 포인터를 새
메모리로 설정해서 공간을 아끼고
기존의 맨 윗부분을 자유롭게 하죠
오버플로 버그를 이용해서 윗부분을 줄이고 더 크게 요청하면 말록이 오버플로
경로에 덩어리를 만들어 줄 거예요 그럼 무체중 공격에 쓸 수 있죠
무료 기능을 사용하지 않고요
하우스 오브 오렌지의 1단계예요
이제 계획은 나왔으니 템플릿 스크립트를 복사해 편집기에서 열어보죠
네 네 스몰_말록(0.0x20 크기의 덩어리를 요청합니다
페이지 사이즈에 약간
못 미치는 걸 요청한다
첫 번째 작은 덩어리에 데이터를 적는다
시작 큰 말로크부터 제거해 첫 번째 작은 말로크는
남겨 두고 거기서부터 오버플로가 발생할 테니까 그리고 편집 콜은 오버플로를
촉발하는 데 쓸 거야 , 알았지?
네 편집 첫 번째 작은 덩어리의 사용자 데이터는 이미 다 찼어요
그 이후에 추가하는 건 전부 상단 덩어리의 영역으로 넘칠 거예요
위쪽은 0x90 크기로 맞춰 줄게요
그래야 풀렸을 때 정서가 혼란한 상태에 연결되죠 그런 다음 디버깅 옵션과 함께 스크립트를
실행해 이게 작동했는지 확인합니다
네 네 ? 네
불행히도 오류 메시지가 떠요
네 이건 말로크 프린터가 아니라 실행이 실패한 결과입니다 확인, 결과는
같습니다 프로세스가
멈췄습니다
GDB로 돌아가서 에러의 근원을 알아봅시다.
SSMalloc으로 전환하려면 '프레임' 명령을 사용하세요
이 기능이 말로크를 대신해 커널에서 메모리를 요청하는 역할을 하죠
네 '컨텍스트 코드' 명령은 어슈트 문을 보여줍니다
문제를 일으키는 거죠
특히 이 두 줄과 관련해서요 네 첫 번째는 맨 위의 것에 미리 입력된 플래그가 설정됐는지 확인합니다 맨 위의
것은 항상 미리 입력된 비트가
있어야 하므로 클리어하면
에러입니다
두 번째 줄은 상단의 덩어리가 페이지 경계에서 끝나는지 확인합니다 지금은 그렇지
않죠
편집기로 돌아가 이런 변화를 줘야 합니다
네 맨 위 덩어리를 페이지 경계로 맞추는 값으로 설정해
보죠
공간을 빼서 할 수 있습니다 이미 이 아키텍처에 대한 페이지 크기의 0x20 크기의 공간을
할당했습니다
prev_inuse를 설정하려면 1을 추가해야 합니다
이러한 변화는 어시스트 발언을 만족시킬 겁니다
네 네 도우미 기능이 상단 확장 코드를 작동시키죠
디버깅 옵션과 함께 스크립트를 실행합니다
이번에도 프로그램이 계속 실행됩니다
GDB에 들어가서 '힙' 명령을 호출하면 0x20에서 흘러나오는 흐름에 정렬되지 않은 덩어리가
있다는 걸 알 수 있습니다
말록이 '울타리'를 사용한다는 걸 알 수 있습니다
이건 불법으로 만든 10x10짜리 덩어리로 맨 위 덩어리가 없는 무더기 끝에 놓여
있어요
이 장치의 목적은 네 통합된 대상을 찾을 때 안전하게 두 덩어리를
앞으로 향하게 하는 것입니다
네 1단계를 완료했으니
이제 꼭대기 둑의 bk를 덮어씌우고 혼란스러운 공격을 준비한다 안 돼요
2단계와 3단계를 어떻게 합치죠?
체계 없는 공격과 파일 스트림 착취의 연관성은 뭐죠?
좋아요 그럼 파일 스트림 이용에서 하이재킹이 어떻게 가능한지 배웠습니다
표준 i/o vtr 포인터를 목표로 삼으면 어떨까요?
네 정리를 못 한 채 표적을 공격해서 주 경기장의 정리를 못 한 쓰레기통을 대신하는 겁니다
네 메인 아레나라고 불리는 입회식 회원 기능은 vtable로 취급됩니다
이건 도움이 안 되네요 메인
아레나의 주 구성 요소는 빈 링크 리스트입니다
그 주소를 실행하려다가 일반 보호 실패로 이어질 수 있죠 실행할 수 없는
메모리를 실행하려 했으니까요
네 그 중 일부를 저장소 정렬로 힙 메모리에 포인터를 달아 채운다고 해도 힙은 경기장만큼
실행 가능한 게 아닙니다
다른 방법은 없나요?
_IO_List_all 포인터는? 네 네 _IO_list_all은 이 프로세스가 연 모든
파일 스트림의
목록의 머리 부분입니다 모든 열린 파일 스트림에 대해
글리비씨가 작업을 수행할 때 사용됩니다 일반적으로 정화 프로세스를 사용합니다
네 네 글립벡 출구를 통하거나 메인 기능에서 돌아올
때 실행되죠
네 _IO_list_all 포인터를 무체중 빈 공격으로 타깃으로 삼고
메인 아레나로 포인터를
바꾼다고 치죠 그럼 프로그램을 종료하죠 네 프로그램이 나가면 글리벡이 청소하면서 공개된 파일 스트림의
완충기를 씻어내려 할 거예요
맞습니다 이렇게 합니다 _IO_list_all list에
있는 모든 파일 스트림을 반복합니다
버퍼가 플러싱이 필요한지 판단하고 필요하다면 그렇다면 , 넘쳐나는 물건들과는
아무 상관 없어요 알아두세요
더 흥미로운 상황입니다 왜냐하면 이제 메인 아레나는 파일 스트림으로 취급되고 있고
우리가 제어하는 힙 메모리에서 파일 스트림 필드 중 하나를 가리킬 기회를 주니까요
맞아요 제일 윗부분을 골라 한 통에 넣으면 돼요 범람하는 버그로
크기 조절을 할 수 있으니까요 맞아요
우리가 안 맞는 금액을 요청하면 배정되지 않고 배정될 거예요
하지만 혼란스러운 공격은 여전히 통합니다 앞서 배웠듯이 분류는 부분적으로 연결이
안 되거든요
네 복잡해지고 있어요 편집기로 돌아가서 몇 가지 변화를 줘서 우리가 하려는 걸
시각화해 보죠 ? 네
_IO_list_all 포인터에 무체중
빈 공격을 설정할 대사를 추가할 거예요 네 편집을 이용해서요 도우미 기능을 이용해 다시 한번 윗부분에 넘칩니다
크기를 0x21로 설정하죠
계속 쓸게요 계속
써야죠 fd는 아무 값으로 설정하고
bk는 _IO_list_all 16의 주소로 설정합니다 ???
네 이렇게 함으로써 정리가 안 된 빈에 0x20 크기의 덩어리가 _IO_list_all
포인터 근처를 가리키는 bk가 생긴 겁니다
네 마지막으로 small_malloc에 전화를 추가하여 도우미 기능으로 0x20 크기의 덩어리를
요청합니다
네 이렇게 하면 말록이 윗부분을 배치할
거예요 크기를 0x20으로 설정했으니 _IO_all에 무체중 빈 공격을 할 수 있죠
네 제가 윗부분을 분류하자고 했지만 한 번에 하나씩 하죠 네, 좋아요
이런 줄을 추가했으면 디버깅 옵션과 함께 스크립트를 실행합니다
GDB와 'IO_List'를 입력해서
혼란스러운 빈 공격이 성공했는지 확인해요
출력을 보니 이제 메인 경기장으로 향하고 있습니다
네 자 아직 끝난 건 아니지만
프로그램을 종료하고 글립코가 새 _IO_list_all 포인터를 어떻게
생각하는지 보죠 ? 계속 진행하려면 프로그램
창으로 가서 '그만'을 선택하세요
그리고 나서 GDB 창으로 돌아가겠습니다
네 이 기술을 위한 폰툴 스크립트는 청소 중에 파일 버퍼를 플러싱하는 글리브코 기능의 브레이크
포인트를 설정합니다 그게 지금 우리가
누른 브레이크 포인트죠
네 백트레이스 패널을 보면 이 함수는 _IO_flush_all_lockp
() from_IO_cleanup () 네, 맞아요
계속 진행하면 예상대로 세그폴트예요 네 소스 패널에 표시된 확인은 _IO_flush_all_lockp
() 파일 스트림이 플러싱이 필요한지 판단하는 데 사용됩니다
네 세그폴트의 이유는 중요하지 않아요
이 기능은 메인 아레나를 파일 스트림으로 취급하는 거니까요
중요한 건 수표의 작동 방식이에요
'IO_OVERFLOW'를 포함한 선은 대문자로 'Ooverflow 멤버' 기능을 호출합니다
첫 번째 논쟁, 'fp'는 파일 스트림 오버플로를 나타냅니다
시작할게요 이 줄 앞에 두 번 확인할 거예요
넘치게 하려면 하나씩 통과해야 해요 넘치게 하려면요
네 네 파일 스트림의 'mode' 필드가 0보다 작거나 같으면 첫 번째 확인은 통과합니다 그리고 _IO_write_ptr
필드가 _IO_write_base
필드보다 크면 통과하죠
네 근본적으로 프로그램이 종료되기 전에 이 파일 스트림 버퍼에 작성된 게 있는지
확인하는 겁니다
네 두 번째 체크는 직접 해독하시게 두겠습니다
하지만 for _mode는 0보다 큰 테스트입니다
네 "출력"을 써서 "IO_all_list"를 없애면 _IO_flush_all_lockp() 함수의
관점에서 볼 수 있습니다 메인 아레나와 겹친다고 추정되는 파일 스트림은 negative_mode 필드가
있는데 _IO_write_base와 ptr 필드는 동일합니다 즉 후자로 인한 첫 번째 체크와 전자로 인한 두
번째 체크에서 실패합니다
네 그렇다면 이 경우에는 _IO_flush_all_lockp()
이 파일 스트림의 오버플로를 호출하지 않고 대신 현재 스트림 체인 포인터를 통해 다음 스트림으로 이동합니다
네 이제 보이네요 _chain은
메인 아레나로 돌아와 약간의 GDB-fu로
멤버의 주소를 출력할 수 있습니다 안 돼요!
네 이걸 'dq'와 합치면 26개 4과목을 제외하고 어느 곳이 체인 포인터로
취급되는지 알 수 있어요
네 'dq' 결과가 약간 이상해 보이는 건 이것과 같은 초기 글립코드
때문인데 2... 네 23번, 경기 시작 때 4글자가 하나 줄어요
PDF에 있는 '아레나 레이아웃' 다이어그램을 보시면 어느 건지 알 수 있습니다
네 어쨌든 이 다이어그램을 이용해서 이것이 상단 덩어리라는 것을 알 수 있습니다
즉, 무체중 빈 fd와 bk가 각각인 것이죠
그리고 smallbin bk를 16 바이트씩 세면 됩니다 예를 들어 0x20 0x30 0x40 0x50
0x60
0x60 스몰빈의 bk는 이 파일 스트림의 체인 포인터로 취급됩니다
네 쓰레기 공격 전에 0x21에서 0x61로 크기를 바꾸면
0x60 스몰빈으로 분류될 거예요 그럼 악당 파일
스트림의 중첩자가 되어 중첩될 테니까요
네 그럼 우리가 가짜 파일을 만들어서 재밌는 작품을 만들
수 있어요 복잡해 보이나요?
네 걱정
마세요 오렌지 하우스는 아주 복잡한 착취 기술
중 하나니까 익숙해질 때까지 영상을 되감고 다시 봐도 돼요
다 됐으면 계속하죠 두 번째 오렌지 템플릿 스크립트를 다운로드하세요
제 화면에
띄워 놨습니다 제 강의의 두 번째
타이핑을 많이 안 하려면 이 방법을
써야 해요 이 기술은 안 그래도 어렵거든요 스크립트 네 오버플로 경로에
자유롭고 정돈되지 않은 부분을 생성할 수 없다고
요청합니다 ,
네 네 ? 네
기억하십시오. Pwndbg의 '프티프'나 'dt' 커맨드를 이용하면 각 필드의 오프셋을
알 수 있습니다.
보세요, 네 그리고 bk에 _IO_list_all-16
주소를 덧씌웠어요 무체계 빈 공격의 목표물이죠
,
네 남은 부분은 파일 스트림에 있어요 윗부분을 겹쳐서요 이제 완성할 거예요
네 취약점이 _IO_flush_all_lockp를 트리거하면 () 함수 손상_IO_alllist_all
포인터를 따라 메인 경기장으로 갑니다 플러싱 버퍼 확인에 실패하죠
그리고 다음 파일 스트림으로 이동합니다 xx60 스몰빈 bk를
따라서요
네 맨 위는 무체계빈 공격 때 이 위치로 정렬됐을 테니 IO_flush_all_lockp
(###체인 포인터를 따라 힙으로 가서 가짜 파일 스트림이 있는 곳으로 버퍼를 플러싱 확인한
후 오버플로를 호출할 겁니다 멤버 기능
네 우리가 할 일은 위조 파일 스트림을 버퍼 플러싱 수표를 통과시켜서
vt형 포인터를 제공하면 넘칠 수 있는 우리가 실행하려는 함수가 입구를
채우지
네 버퍼를 플러싱합니다 잠시 멈추고 'write_base'를 수정합니다 'write_ptr'과
'모드' 변수들을 통과시켜야 합니다
아니면 지금이라도 따라와요
네 'write_base' 필드가 'write_ptr' 필드보다
작을 테니 각각 1과 2로 설정하죠
'모드' 필드는 0보다 작거나 같아야 합니다 그러니
0으로 설정하죠
네 네 파일 스트림의 활성화 기능도 요청할
거고요 포인터는 이미 설치했어요
메모리 제어용 포인터만 있으면 돼요
네 이 경우에는 가짜 vtable을 우리 파일 스트림의 사용하지 않는 부분과 겹치게 해서 공간을 조금
남겨 뒀습니다
하지만 이론적으로는 어디에든 둘 수 있죠
'오버플로' 변수가 오버플로를 형성합니다
네 여기서 단일 장치를 사용하기
전에 오버플로가 호출되면 첫 번째 인수는 호출된 파일 스트림의 주소란 걸 기억하세요
그 말은 문자열을 'bin/sh'에 쓰면 파일 스트림의 첫 사분어드에
'_flag' 필드가 있는 곳이죠 그런 다음 넘치게 해요
글리벡 시스템에서 실시간 입력 호출은
시스템이 되고 우린 하나의 장치
없이 껍데기를 얻게 되죠
다 좋은데 문제가 하나 있어요
여러분 무체계적 공격 기억나세요? 부패한 자들을 정리가 아니라 할당하도록 확실히
했잖아요
네 일부 언링크는 부패한 bk를 방심하는 빈 bk 위에 복사하는 부작용을
낳습니다 부패한 부분을 분류하면 말록이 부패한 bk를 따라 방심하는
상자를 계속 수색해서 방심하는 몸이 목적지를 확인하지
못하게 됩니다
그 결과 무시무시한 멀록 프린터기에 신고가 들어와 공정을 중단합니다
어쨌든 디버깅 옵션과 함께 스크립트를 실행해 모든 게 제자리에 있는지 확인하고
문제를 빨리 해결하죠
네 멈춰서 백트레이스 패널을 보면 익숙한 패턴이 보입니다
네 현재 프레임을 보세요
_IO_flush_all_lockp에서 멈췄어요 우리가 트리거하고자 했던 바로 그 함수죠
글리벡 버전 2 이전에는 27 중단 () 기능은 파일 스트림을 플러시한다 손상된
데이터를 감지한 후 데이터 작업을 하는 것보다 합리적인 게 있을까?
_IO_flush_all_lockp이
뭘 할지 알아요 체인을 따라가
보죠
네 역방향 차단_IO_list 아까 본 대로예요 메인 경기장에 파일 스트림이 겹쳤어요
버퍼 플러싱이 안 돼요
이번에는 멤버가 본 아레나로 돌아가지 않고 힙을 가리켰습니다
GDB-fu를 이용해 _chain 포인터를 따라가 위조 파일 스트림을 확인할 수 있습니다
네 _IO_write_base와 _ptr 필드를 각각 1과 2로 설정합니다 0 모드
필드와 오버로 시스템 현실
진입
마지막으로 스트럭처 시작에 있는 _flags 필드는 스트링 'bin/sh'를 포함합니다
좋아요, 계속하죠
프로그램 창으로 바꾸면 불평을 하긴 하겠지만요 중단 직전에 포탄을 낚아챘습니다
보세요 글리벡이 오류 메시지를 인쇄하고 소각 전에 역추적까지 한 걸 보면 말로크에게 세
번 전화한
것치곤 나쁘지 않아요
바로 오렌지 하우스입니다
네 요약하자면 오버플로를 상단에 넣어 작은 페이지 정렬 값으로 줄였습니다 ?????
새로 쪼그라든 윗부분에게 맡기기엔 너무 큰 부탁을 했죠
이게 말록의 상단 확장 코드를 촉발해서 알맹이에서 메모리를
요청하고 메모리가 상단까지 연속되면 상단까지 확장하는 거죠
그런데 우리가 맨 위쪽에 있는 땅덩어리를 건드렸기 때문에 말록의 관점에서
보면 새로 얻은 기억은 맨 위 땅덩어리와 연결되지
않아서 새로운 땅덩어리로 사용되고 원래 있던
땅덩어리를 풀어놓은 겁니다
덕분에 물이 넘칠 때 방향 감각을 잃게 됐죠
네 네 ? 네 _IO_all 포인터에 무체제빈
공격을 설정하고 있어요
네 그리고 이 기회에 기존의 윗부분을 겹쳐서 파일 스트림을 만들고 기존의
크기를 0x60으로 맞췄어요
마지막으로 요청한 건 0x60 크기가 아닌 덩어리였죠 바로 말록입니다 말록은 우리 요청에 부응할 만한
작은 덩어리를 못 찾아서 흐릿한 곳을
뒤지다가 윗부분 덩어리를 발견했습니다 네 하지만 크기가 맞지 않아서 말록이
0x60 스몰빈으로 분류했고 그 과정에서 정서가 혼란스러워졌죠
말록이 계속 수색했다 부패한 bk를 따라갔는데 보이지 않는 덩어리가 정신 건강 검사를
통과하지 못했고 글록은 중단 절차를 밟기 시작했다
글리벡이 중단 신호를 보내기 전에 공개된 파일을 정리했어요
시작은 네 메인 아레나로 가는 것이었습니다 포인터는
혼란스러운 공격의 대상이었고 이제 혼란스러운 주소를 갖고
있습니다
파일 스트림으로 취급되면 메인 아레나에서 오버플로에 호출을 촉발하는 확인에 실패합니다
() 기능 클린업 기능 _IO_flush_all_lockp
() 목록의 다음 파일 스트림으로 이동합니다 _체인 포인터를 통해서요
네 #체인 포인터는 0x60 스몰빈 bk와 겹쳐 말로크에
전화를 걸어서 이 모든 일이 시작된 곳이지 가짜 파일 스트림은 거기서 분류돼
우린 네 그때 우리의 vtable 포인터가 가짜
vtable로
이어졌고 거기서 우린 초과 분량을 교체했죠 기록에 시스템
주소와 () 기능
오버플로 그 오버플로는 기능은 보통 첫 번째 인수로 파일 스트림에 포인터를 갖고 호출됩니다
우리 파일 스트림의 _flag 필드를 문자열 'bin/sh'로 치웠죠
이로 인해 과잉 유출로 이어졌고 시스템에 과잉 유출한 것으로 해석되어 껍질을 떨어뜨렸고
오렌지 하우스 기법의 끝에 도달했습니다
받아들이기 힘들었을 거 알아요
네 말록의 새로운 내장을 배웠죠 정서가 혼란스러운 공격과 파일 스트림 착취에 대해 조금
배웠습니다 ? 네
네 이 기술에 익숙해질 때까지 다음 영상으로 넘어가야 한다는 부담은 갖지 마세요
여러분 마지막 관문이 남았습니다 오렌지 하우스에 대해 잘 이해해야
맞설 수 있을 겁니다
네 이 영상을 보고 PDF를 참조해 기술 요약과 말똥가리 내부를 확인하세요
언제나처럼 강의 리소스에서 주석으로 된 솔루션 스크립트를 제공합니다
좋아요 하지만 이 영상을 끝내기 전에 오렌지 하우스에 관해 몇 가지 중요한 걸 알려드릴게요
1단계는 무시해도 돼요 기존의 흐트러진
메타데이터를 조작할 수 있다면요 네 네
? 네
네 프로덕션 바이너리는 그렇지 않죠 공짜 청크가 있을 가능성이 훨씬 높거든요
1단계와 또 다른 건 우리가 이용한 상단 확장 코드예요 문제의
아레나만 그렇게 작동하죠
네 네 상단 크기로 새로 습득한 기억이 연속적인지 가늠하지
못하기 때문이죠 ? 네
끝으로 마지막으로 가장 중요한 건 주목하세요 처음으로 우리 착취가 생산 조건에서 100% 신뢰할
수 없다는 걸 말입니다
껍데기를 얻을 때도 있고 못
얻을 때도 있어요
그 이유는 네
안 돼! 네 네 ????
네 그 결과 가장 중요한 부분이 결정되죠 부정적으로 해석될지 ASLR의
적용을 받을지 결정하는 부분이에요
GDB를 첨부하고 ASLR을 해제하지 않으면 그 틈을 타서 공격하면
'IO_flush_all_lockp에서
계속' (브레이크포인트에서 세그폴트로 가는 과정을
기다린다 파일 스트림이 메인 아레나를 겹치고 이번엔 버퍼 플러싱을 통과했다 _IO_flush_all_lockp
(O 오버플로를 호출하려 했다 ((기능 세그폴트로 끝났다
네 "fp 변수 출력" 이제 주요 아레나에 겹치는 파일 스트림을 처리하면서 발생한
단층을 확인했고 그 _mode 필드가 양수로 해석됐음을 확인했다 이번엔 두 번째 버퍼
플러싱 확인을 통과했다 통과
통과하는 이유 그 이유는 두 번째 체크를 추적하세요 공격을
마무리하기 전에 여러 통으로 나눠서 이런 행동을 상쇄할 수 있어요 여기서는 그렇게 할 수 있는
순발 제어가 안 됐어요
네 메인 아레나에 겹치는 파일 스트림의 vt 가능한 포인터가 아닌 _체인 포인터를
목표로 한 것도 연구 프로젝트로 남았어요
네 오렌지 하우스의 한계가 마음에 들면 말록의 내부 콘셉트 재조정을
한 번 더 한 후 배운 걸
시험해 볼 마지막 과제를 할 거예요
다음 영상에서 만나요