2010-10-03 2 views
6

나는이 이론을 들었다. 주소 공간 위치 무작위 화는 라이브러리를 가져 와서 가상 주소 공간의 임의의 위치에서로드하므로 해커가 프로그램에서 구멍을 발견 한 경우 return-to-libc 공격을 실행하기 위해 미리 알려진 주소를 갖지 않습니다 예를 들어 그러나 몇 초 동안 생각한 후에는 방어적인 수단으로는 아무런 의미가 없습니다.ASLR은 어떻게 효과적 일 수 있습니까?

가상의 TargetLib (libc 또는 해커가 찾고있는 다른 모든 것)가 결정적인 것 대신 임의의 주소에로드되었다고 가정 해 보겠습니다. 이제 해커는 TargetLib과 그 내부의 루틴이 어디에 있는지 미리 알지 못하지만, 애플리케이션 코드도 마찬가지입니다. TargetLib 내부에서 루틴을 찾으려면 바이너리 어딘가에 조회 테이블이 있어야하며 결정적인 위치에 있어야합니다. (또는 다른 곳이 가리키는 임의의 위치에서 원하는만큼의 방향을 추가 할 수 있지만 결국 알려진 위치에서 시작해야합니다.)

즉, 공격 코드를 TargetLib의 알려진 위치에서 해커는 응용 프로그램의 조회 테이블에서 TargetLib에 대한 공격 코드를 가리키고 포인터를 대상 루틴에 참조하고 공격이 방해받지 않고 진행됩니다.

ASLR이 작동하지 않는 방식에 대해 알고 있습니까? 기술 된 바와 같이, 나는 그것이 보안 문제의 이미지를 제공하지만 실제적인 내용은 제공하지 않고 속도 위반보다 더 많은 것을 보지 못하기 때문입니다. 내가 놓친 게 있니?

답변

2

나는 이것이 공유 라이브러리의 기본 주소를 변경하기 때문에 효과적이라고 생각합니다. 공유 라이브러리에서 가져온 함수는로드 될 때 실행 이미지에 패치되므로 프로그램 자체의 코드 전체에 흩어져있는 데이터와 코드를 가리키는 특정 주소 만있는 테이블 자체는 없습니다.

단순한 버퍼 오버런 (스택의 반환 주소를 설정할 수 있음)이 오버런에 올바른 위치를 결정하기위한 코드가 포함되어 있어야하고 그 다음에 jmp가되어야하는 곳으로 만들기 때문에 효과적인 공격을 할 수 있습니다 . 아마도 이것은 단지 더 어렵게 만듭니다.

사실상 Windows의 모든 DLL은 실행되지 않을 가능성이 높고 이동 될 기본 주소 용으로 컴파일되지만 코어 Windows는 기본 주소가 최적화되어 재배치가 필요하지 않습니다.

+1

ASM 레벨에서 Windows EXE를 디버깅 한 적이 있습니까? 거기에 진짜 수입 표가 있습니다. 로더는 코드 (코드가 일부 외부 루틴을 호출 할 수있는 모든 장소)를 패치하지 않습니다. 기본적으로 컴파일러에서 CALL을 생성하는 긴 순서의 JMP 명령어 인 가져 오기 테이블을 패치합니다. –

+0

그 공유 메모리뿐만 아니라 ... – rook

+0

@Mason Wheeler - 오랫동안 아니지만, 알아두면 좋습니다. 그렇게하면 특정 주소를 쉽게 결정할 수 있지만 그물 효과는 동일하지 않습니까? 그것은 알려지지 않은 것으로 알려지기 때문에 단순히 공격을 더 어렵게 만듭니다. –

1

정확하게 질문 할 수 있을지 모르겠지만 ASLR이 효과적 일 때와 그렇지 않은 경우를 설명해 드리겠습니다.

app.exe와 TargetLib.dll이 있다고 가정 해 보겠습니다. app.exe가 TargetLib.dll을 (를) 사용하고 있습니다. 설명을 간단하게하기 위해 가상 주소 공간에는이 두 모듈 만 있다고 가정 해 봅시다.

둘 다 ALSR을 사용하는 경우 app.exe의 기본 주소를 알 수 없습니다. 그것은로드되었을 때 일부 함수 호출 주소를 해결할 수 있지만 공격자는 함수의 위치도 해석 된 변수의 위치도 알지 못합니다. TargetLib.dll이로드 될 때도 마찬가지입니다. app.exe에 찾아보기 테이블이 있어도 공격자는 테이블의 위치를 ​​알 수 없습니다.

공격자가 특정 주소의 내용을 알 수 없으므로 공격자는 고정 주소 정보를 사용하지 않고 응용 프로그램을 공격해야합니다. 일반적으로 스택 오버플로, 힙 오버플로, 사용 후 무료 등의 일반적인 공격 방법을 사용하는 것이 일반적으로 어렵습니다.

반면에 app.exe가 ASLR을 사용할 수없는 경우 공격자가 훨씬 쉽게 응용 프로그램을 악용 할 수 있습니다. 앱의 특정 주소에 흥미로운 API에 대한 함수 호출이있을 수 있기 때문입니다.exe 및 공격자가 주소를 대상 주소로 사용하여 점프 할 수 있습니다. (응용 프로그램 공격은 보통 임의의 주소로 점프하기 시작합니다.)

보충 자료 : 이미 알고 계시 겠지만 한 가지 명확한 내용을 원합니다. 공격자가 메모리 손상과 같은 취약점으로 애플리케이션을 악용 할 때 그는 보통 fixed address jump instruction을 사용해야합니다. 그들은 relative address jump 명령을 이용할 수 없습니다. 이것이 ALSR이 이러한 공격에 실제로 효과적인 이유입니다.

+0

좋습니다. 내가 얻지 못한 마지막 지점입니다. 침입자는 왜 '고정 주소 점프'(하나의 ASM 연산 코드)를 사용할 수 있지만 '상대 주소 점프'(다른 ASM 연산 코드)를 사용할 수없는 이유는 무엇입니까? 그곳에 내가 알지 못하는 어떤 마법적인 차이점이 있습니까? –

+1

글쎄, 당신이 먼저 어떻게 그런 악용이 작동하는지 이해해 설명하십시오. 한 가지 좋은 예는 전형적인 버퍼 오버 플로우와 반송 주소 덮어 쓰기입니다. 나는 여기서 세부 사항을 설명하지는 않지만 요점은 공격자가하는 것은 고정 된 값으로'리턴 주소 '를 겹쳐 쓰는 것이다. 실행 흐름이 취약한 기능을 종료하면 덮어 쓰기 된 주소로 점프합니다. 이 점프는 항상 '상대 점프'가 아니라 '고정 주소 점프'입니다. 악용 될 수있는 '상대 점프'를 사용할 수있는 몇 가지 취약점이있을 수 있지만 드문 경우입니다. –

+1

즉, 공격자가 할 수있는 것은 '명령'이 아닌 '데이터'만 손상시키는 것입니다. 앱을 이용하기 위해 '고정 주소 점프'명령에 사용되는 '데이터'가 손상됩니다. 공격자가하는 일은 쉘 코드 (실행하려는 코드)를 추출하고 쉘 코드로 점프하는 것입니다. 쉘 코드에서는 상대 점프를 사용할 수 있지만 ASLR 환경에서는 쉘 코드 자체로 점프하는 것이 어려운 문제입니다. –

관련 문제