델파이와 시큐어 코딩

C로는 시큐어 코딩 관련한 이야기들이 수도 없이 쌓여있지만, 델파이로는 많이 없다.
데브기어에 올라온 문의는 무시당한 것으로 보인다.

델파이는 과연 보안 관련한 문제가 없는가? 하면 그렇지 않다. 사실 당연한 게 자바 시큐어 코딩 가이드도 나오는 세상에, 네이티브 언어가 안전하리라고 생각하는 게 너무 순진한 생각 아닌가.

이 슬라이드를 보면 알겠지만 델파이는

  • 명시적 외곽 체크도 없고(배열 등을 [0..X]로 선언한다고 해서 저 범위를 체크해 주지 않는다는 이야기다)
  • 스택 카나리아도 없고(즉 스택을 이용한 공격에 무방비하다는 이야기다)
  • SEH 방어도 없다

슬라이드에서 보이듯 델파이는 2015년 현재 보안 면에서 C와 비슷한 수준임에도 불구하고 보안 장치는 더 적다. 그럼에도 불구하고 Overflow Checking과 Range Checking을 둘 다 켤 수는 없는 게, C의 유사 기능만큼 완전하지도 않은 기능들이 속도에 영향을 주는 수준은 엄청나기 때문이다. 나래온 툴 개발 도중 한 번 켜봤다가 프로그램이 엄청나게 느려지는 바람에 다시 껐던 경험 이후, 해당 기능들은 나도 안 쓰고 있다.

델파이 세계는 레거시 코드가 지배하기 때문에 2011년에도 2004년에 쓰던 엄청나게 위험한 코드가 돌아다닌다. (안전한 코드를 찾는다면 이 쪽이다.) 본가인 C에서도 사장된지 이미 오래되었으나, 델파이는 String쪽만 신경쓰기 때문에 _s 옵션이 붙은 안전한 함수 따위는 존재하지 않는다. 요즘에는 어떻게 되었는지를 검색해봤더니 strpcpy는 deprecated 처리되었으나, 그 이유는 네임스페이스가 옮겨갔기 때문이지 보안 함수 때문이 아니었다. (혹시 델파이라서 범위 체크를 해줄거라고 생각했다면 꿈 깨시라. 여기에 나오듯 새로운 네임스페이스에 들어간 함수에도 범위 체크같은 건 없다.)

델파이에서 제공해주지 않는 부분은 어쩔 수 없다고 치고, 우리가 할 수 있는 기본적인 조치들을 확인해보자.

  • NX, ASLR 적용
    프로젝트 파일에 {$SETPEOPTFLAGS $140}만 써주면 매우 간단하게 적용이 가능하다. 무서운 세상에 보안에 적잖은 도움을 주는 기능들이니 망설이지 말고 적용하시라. 더군다나 적용이 엄청나게 간단하지 않은가?
  • strp…류 사용 금지
    델파이의 주력 String은 String 형이지 PChar류 형이 아니다. 최대한 String을 쓴 후 정말 마지막에만 PChar로 바꿔서 넘기시라. 바운드를 지정할 수 있는 StrLP…류를 쓰면 되지 않겠냐? 하겠지만 C & C++ 시큐어 코딩에서 지적하는 바와 같이 이런 함수들에도 문제가 있다. 해당 바운드가 넘어서 끝났는지 아니면 해당 바운드 전에 정상적으로 종료가 되었는지를 알 수 없다는 점이다. 이런 문제는 스트링 잘림으로 인한 다른 보안 취약점을 만들어낼 수 있다.
  • 64비트 컴파일
    SEH가 64비트 플랫폼에서는 스택이 아닌 PDATA로 옮겨가서 64비트 컴파일을 하게 되면 SEH 방어가 필요없어진다. 델파이 기본 함수들도 64비트 버전부터 SSE 등 새로운 명령어 셋을 적용하니, 경우에 따라 소소한 성능 향상이라는 부가적인 이점도 누릴 수 있다.

이외에도 많은 부분들이 존재하지만 다른 부분들은 따로 글을 쓸 예정이다.

Leave a Reply

Your email address will not be published. Required fields are marked *