소프트웨어 보안: 소유와 개방 사이의 딜레마
소프트웨어 보안: 소유와 개방 사이의 딜레마
  • 김슬배 / 컴공 조교수
  • 승인 2024.11.27 14:34
  • 댓글 0
이 기사를 공유합니다

▲그림 1. 오픈 소스 소프트웨어인 리눅스 커널의 광범위한 재사용
▲그림 1. 오픈 소스 소프트웨어인 리눅스 커널의 광범위한 재사용

인간은 끊임없이 소유하려는 욕망이 있다고들 한다. 에리히 프롬은 그의 1976년 저서 ‘To Have or to Be?’에서 인간 본성에 내재한 지나친 소유욕을 꼬집으며, “If I am what I have and if what I have is lost, what am I?”라는 질문을 던졌다. 소프트웨어의 세계에서도 유사한 맥락을 엿볼 수 있다. 직접 개발한 소프트웨어의 소스 코드를 공개하기를 꺼리는 개발자나 기업이 많은 것이다. 소스 코드란 소프트웨어의 정확한 동작 로직과 알고리즘을 인간이 이해할 수 있는 프로그래밍 언어로 작성한 것이다. 따라서 소스 코드를 공개한다는 것은 소프트웨어의 핵심 정보를 누구나 볼 수 있게 만든다는 뜻이다.

그럼에도 불구하고 ‘오픈 소스 소프트웨어 문화’는 인간의 소유욕을 거스르며 성장해 현재는 주류로 자리 잡았다. 오픈 소스 소프트웨어란 소스 코드가 공개돼 누구나 자유롭게 재사용할 수 있는 소프트웨어를 의미한다. 1991년 리누스 토발즈가 리눅스 커널을 개발해 오픈 소스로 공개한 이후, 오픈 소스 커뮤니티가 폭발적으로 성장했고, 리눅스 커널은 전 세계에서 가장 널리 재사용되는 코드 기반이 됐다(그림 1). 오픈 소스 소프트웨어의 성공 비결은 소스 코드 공개를 통해 전 세계 개발자들이 리뷰와 개선 과정에 참여하도록 만든 데 있다. 오픈 소스 커뮤니티가 성숙해지면서 소프트웨어 개발 시 필요한 기능을 기존의 오픈 소스 소프트웨어에서 가져와 재사용하는 것이 표준이 됐다. 이에 따라 개발 속도가 크게 향상됐고, 다수의 검증을 거친 고품질 코드를 무료로 사용할 수 있는 장점이 생겼다. ‘Do not reinvent the wheel’의 철학이 현실화한 셈이다.

하지만 사이버 보안 측면에서는 이야기가 다르다. 개발 중 실수로 발생하는 코드상의 결함은 ‘버그’라고 불리며, 그중 공격자(해커)가 악용해 시스템을 장악할 수 있는 결함은 ‘보안 취약점’이라 한다. 아무리 실력이 좋은 개발자라도 실수를 피할 수 없으며, 소프트웨어 규모가 커지고 참여 인원이 많아질수록 취약점 발생 가능성도 자연히 증가한다. 오픈 소스 소프트웨어 역시 취약점에서 벗어날 수 없다. 문제는 이런 상위 오픈 소스 소프트웨어(Upstream)의 보안 취약점이 오픈 소스 생태계를 통해 하위 소프트웨어(Downstream)로 자연스럽게 전파된다는 점이다. 하나의 취약점이 Upstream 소프트웨어뿐 아니라 이를 재사용하는 무수히 많은 Downstream 소프트웨어를 해킹 공격에 노출하는 것이다.

▲그림 2. 취약점이 있는 libpng 코드
▲그림 2. 취약점이 있는 libpng 코드

일례로, libpng는 PNG 형식의 이미지 파일을 처리할 때 매우 빈번하게 사용되는 오픈 소스 소프트웨어다. 그림 2는 2011년에 libpng에서 발견된 취약점으로, libpng를 통해 악성 메타데이터를 포함한 PNG 이미지를 읽을 경우 시스템에서 공격자의 악성 코드가 실행될 수 있는 보안 결함이다. 해당 취약점은 2012년에 패치됐고, 새로운 버전의 libpng가 출시됐다. 그런데 2017년, 필자가 연구 개발한 취약 코드 탐지 기술 VUDDY가 당시의 최신 스마트폰을 검사한 결과, 기본으로 탑재된 웹 브라우저에 위의 취약점이 남아있는 구버전의 libpng 코드가 사용됐다는 사실을 탐지했다. 이미 상위 소프트웨어에서 고쳐진 취약점이지만 5년이 지난 시점의 스마트폰에까지 영향을 미친 것이다. 해당 취약점의 검증을 위해 악성 이미지를 제작해 이를 포함한 웹 사이트를 만들어 테스트한 결과, 취약점은 정상적으로 작동했으며, 웹 브라우저를 먹통으로 만들 수 있었다.

VUDDY의 핵심 기술은 소스 코드로부터 기능의 최소 단위인 함수들을 추출하고, 추출한 함수를 모아 효율적인 탐색이 가능한 자료 구조로 재구성하는 것이다. 이렇게 생성한 소프트웨어들의 ‘Fingerprint’를 상호 비교하면 소프트웨어 간에 동일한 함수가 포함됐는지를 신속하게 탐지할 수 있다. 이를 응용해, 알려진 취약점 정보를 수집해 생성한 취약점 Fingerprint와, 타깃 소프트웨어의 Fingerprint를 비교하면 타깃 소프트웨어에 포함된 취약한 코드를 정확하고 신속하게 찾아낼 수 있다. △안드로이드 펌웨어 △웹 서버 △데이터베이스 시스템 등 널리 쓰이는 시스템을 포함해 25,000개의 오픈 소스 소프트웨어를 테스트 한 결과 VUDDY는 10만 건이 넘는 취약 코드를 탐지해 냈다. 또한, 후속 연구에서는 상위 소프트웨어가 취약점을 패치해도 하위 소프트웨어에 적용되기까지 평균 1년 정도 소요된다는 사실과, 적용에 3년 이상이 걸리는 경우도 다수 있음을 발견했다.

최근에는 위와 같은 문제가 ‘소프트웨어 공급망 공격’이라는 이름으로 쟁점이 되고 있다. 올해 초 발생한 XZ Utils 백도어 사태가 대표적인 예시이다. XZ Utils는 널리 쓰이는 압축 표준을 지원하는 오픈 소스 압축 소프트웨어로, 대부분의 리눅스 기반 운영체제에 포함돼 배포된다. XZ Utils의 개발자 중 한 명은 전술한 공급망을 악용해 XZ Utils에 백도어(외부로부터 시스템에 쉽게 침투할 수 있도록 몰래 삽입한 코드)를 심어 배포했고, 그 결과로 XZ Utils를 포함하는 운영체제들에 백도어가 심어지게 됐다. 이와 같은 공급망 공격으로 인한 사회-경제적 파장이 커지며 미국 정부에서는 최근 SBOM(Software Bill of Materials) 도입에 관한 행정 명령을 내렸다. SBOM은 직역하면 ‘소프트웨어 재료의 목록’으로, 소프트웨어에 포함된 모든 구성 요소를 나열한 명세서이다. 소프트웨어에 포함된 다른 소프트웨어가 정확히 무엇이며, 어떤 버전이고, 어떤 공급망을 통해 들어왔는지 등을 투명하게 밝혀, 악성 소프트웨어나 패치되지 않은 버전의 소프트웨어를 쉽게 찾아내 제거하자는 것이 그 취지이다. 이에 따라 SBOM에 포함된 소프트웨어 버전 정보를 활용하는 취약점 탐지 연구도 많이 이뤄지고 있다.

VUDDY처럼 소스 코드를 이용하거나, SBOM과 같은 정적인 정보를 이용하는 취약점 탐지 방법들은 뛰어난 탐지 능력을 입증했으나, 아직 해결해야 할 문제가 남아있다. 소스 코드만, 혹은 버전 정보만 가지고는 취약성을 완벽하게 판단할 수 없기 때문이다. 코드 중에는 소프트웨어에 포함은 돼 있지만 실행되지 않는 Dead code도 있고, 실행 환경이나 소프트웨어 상태 등에 따라 동작이 달라지는 Context-Sensitive Code도 존재한다. 따라서 실제로 소프트웨어가 실행될 때 취약한 코드가 실행되고 공격자의 악용으로 이어질 수 있는지를 검증하는 동적 테스팅 기법이 필요하다. 또한, 재사용한 상위 소프트웨어 코드의 취약점이 공격에 노출되더라도 임팩트의 범위를 제한해 시스템에는 영향을 미치지 못하게 하는 샌드박싱 기법도 함께 연구해 선제적 방어와 반응형 방어 체계를 모두 구축해야 한다.

오픈 소스 소프트웨어는 인간의 소유 욕망을 넘어 협업과 공유의 가치를 실현한 혁신적 사례이다. 그러나 이런 문화가 지속되기 위해서는 보안이라는 현실적 과제를 반드시 해결해야 한다. 보안 기술과 철학의 조화는 오픈 소스 생태계의 미래를 결정짓는 중요한 과제가 될 것이다.