충돌 (컴퓨팅)

충돌[1], 크래시(crash), 또는 시스템 크래시는 컴퓨터 프로그램(응용 소프트웨어 또는 운영 체제)이 적절하게 기능하는 것을 멈췄을 때이다. 종종 이것은 이러한 오류를 맞닥뜨린 후에, 영향을 받는 프로그램을 종료하게 된다. 책임을 갖는 프로그램은 크래시 리포팅 서비스가 크래시와 잠재적으로 관련된 자세한 사항을 보고할 때까지 프리징된다. 만약 프로그램이 운영 체제의 중요한 부분이라면 컴퓨터 전체가 크래시될 것이고 종종 커널 패닉 또는 심각한 시스템 오류를 야기한다.

충돌을 유발하는 심각한 에러를 겪고 블루스크린을 보여주는 공중 전화.

많은 충돌들은 부정확하게 실행되는 단일 또는 다중 기계 명령어의 결과이다. 전형적인 원인들은 프로그램 카운터가 부정확한 주소로 설정되거나 버퍼 오버플로가 버그 때문에 영향을 받는 프로그램 코드의 한 부분을 겹쳐쓰는 것이다. 각 경우에 CPU가 데이터나 무작위 메모리 값들에 접근하려고 시도하는 것이 보통이다. 모든 데이터 값들이 선택될 수 있지만 항상 요청에 유효한 값은 아니므로 이것은 틀린 명령어 예외를 야기한다. 때로는 이러한 데이터나 무작위 값들이 유효한 명령어가 될 수 있다. 원본 프로그램 문제는 충돌을 야기하는 것으로 여겨지지만, 실제 결점은 부정확한 명령어이다. 이러한 충돌들을 디버깅하는 과정은 이벤트들의 체인을 시작하는 코드와 함께 충돌의 실제 원인에 연결하는 것이다. 이것은 종종 명백함과는 거리가 멀다; 원래 버그는 보통 프로세서에게 보여지는 완벽하게 유효한 코드이다.

애플리케이션 충돌

편집
 
세그멘테이션 오류로 인해 크래시 된 윈도우 XP에서 프로그램을 돌리는 화면을 보여주는 프랑크푸르트 공항

응용 소프트웨어는 일반적으로 운영 체제에 허락받지 않은 연산을 수행할 때 충돌된다. 운영 체제는 그 때 예외 또는 시그널을 그 애플리케이션에 보낸다. 유닉스 애플리케이션들은 전통적으로 덤핑 코어에 의한 시그널에 반응한다. 대부분의 윈도우와 유닉스 GUI 애플리케이션들은 대화 상자를 보여주는 것으로 대응한다. 만약 디버거가 설치되었다면 디버거를 어태치할 것인가를 묻는 옵션도 함께 보여준다. 이 행동을 "크래싱"이라고 한다. 몇몇 애플리케이션들은 에러에서 회복하고 충돌 대신 실행을 계속하려고 시도한다.

애플리케이션 충돌을 유발하는 일반적인 에러는 다음과 같다:

  • 읽거나 쓰기 용으로 할당되지 않은 메모리에 대한, 애플리케이션에 의한(세그멘테이션 오류) 또는 x86에 의한(일반 보호 오류) 읽거나 쓰려는 시도
  • 권한이 부여된 또는 유효하지 않은 명령어들을 실행하려는 시도
  • 접근 권한을 갖지 않은 하드웨어 디바이스에서 I/O 연산을 수행하려는 시도
  • 유효하지 않은 인자를 시스템 호출 시에 보내기
  • 애플리케이션이 접근 권한을 갖지 않은 다른 시스템 자원에 접근하려는 시도
  • 안좋은 인자와 함께 기계어를 실행하려는 시도: 0으로 나누기 등

웹 서버 충돌

편집

웹사이트 뒤에서 소프트웨어를 실행하는 웹 서버도 완전히 접근 불가능하게만들면서 또는 정상적인 내용 대신 오직 오류 메시지만 제공하는 상태로 충돌될 수 있다.

운영 체제 충돌

편집

운영 체제 충돌은 처리될 수 없는 하드웨어 예외가 발생할 때 주로 발생한다. 운영 체제 충돌은 또한 내부 정상 테스트(sanity-checking) 로직이 운영 체제가 내부 자기 일관성을 잃은 것을 탐지했을 때 발생할 수 있다.

충돌의 보안 영향

편집

충돌을 유발하는 많은 소프트웨어 버그들은 또한 임의 코드 실행권한 확대에 대한 취약점 공격이 가능하다.[2][3] 예를 들면 스택 버퍼 오버플로는 서브루틴의 반환 주소를 유효하지 않은 값으로 겹쳐쓸 수 있으며, 이것은 서브루틴이 리턴할 때 세그멘테이션 오류를 유발한다. 그러나 만약 익스플로잇이 반환 주소를 유효한 주소로 겹쳐쓴다면 그 주소의 코드는 실행될 것이다.

같이 보기

편집

각주

편집
  1. “충돌 : 지식백과”. 한국정보통신기술협회. 
  2. “Analyze Crashes to Find Security Vulnerabilities in Your Apps”. Msdn.microsoft.com. 2007년 4월 26일. 2014년 6월 26일에 확인함. 
  3. “Jesse Ruderman » Memory safety bugs in C++ code”. Squarefree.com. 2006년 11월 1일. 2014년 6월 26일에 확인함. 

외부 링크

편집