오픈소스 과반 ‘메모리 손상 언어’로 취약점 위험

[애플경제 김예지 기자] 대부분의 오픈소스 프로젝트엔 메모리에 취약점을 생성하는, 불안전한 코드가 포함되어 있는 것으로 나타나 경각심을 높이고 있다.

최근 미 FBI와 CISA, 그리고 호주 사이버보안센터, 캐나다 사이버보안센터 등 3개국 보안 당국이 공동으로 내놓은 보고서에 의하면 오픈소스 프로젝트의 무려 52%가 메모리에 안전하지 않은 C나 C++와 같은 언어로 작성되었다는 사실이 밝혀졌다.

이로 인해 자칫 코드가 메모리를 손상시켜 ‘버퍼 오버플로’나 ‘UAF(use-after-free)’ 취약점, 메모리 누수 등과 같은 문제를 초래할 수 있을 것이란 우려다. 이는 OpenSSF(오픈소스 안전재단)의 안전위협대응팀에서 정의한 172개의 주요 오픈소스 프로젝트에 대한 분석 결과를 토대로 한 것이다.

이들 프로젝트의 전체 코드 라인 가운데 55%는 메모리에 안전하지 않은 언어로 작성되었고, 대규모 프로젝트일수록 더 많은 코드가 포함되어 있다. 데이터셋 규모면에서 가장 큰 10개 프로젝트의 4분의 1 이상이 메모리가 안전하지 않은 라인을 지니고 있으며, 그 평균치는 62.5%이다. 그 중 4개는 94% 이상이 메모리에 안전하지 않은 코드로 구성되어 있을 정도다.

메모리에 안전하지 않은 언어란?

C 및 C++와 같은 메모리에 안전하지 않은 언어를 사용하려면 개발자가 신중한 메모리 할당이나 할당 해제 등 엄격한 메모리 관리 방법을 수동으로 구현해야 한다. 그렇다보면 당연히 실수도 일어나게 되며, 이로 인해 공격자가 소프트웨어, 시스템, 데이터를 제어할 수 있는 취약점이 발생하게 된다.

반면에 파이썬, 자바, C#, 러스트(Rust) 등의 안전한 메모리 언어는 내장 기능을 통해 자동으로 메모리 관리를 처리하고, 책임을 인터프리터나 컴파일러로 전환한다. 그래서 “메모리 안전 취약점은 가장 널리 퍼진 소프트웨어 취약점 클래스 중 하나이며, 패치, 사고 대응 등의 노력을 하는 과정에서 소프트웨어 제조업체와 소비자 모두에게 상당한 비용을 발생시킨다”고 보고서는 밝혔다.

또한 메모리 안전 언어로 작성된 3가지 프로젝트의 소프트웨어 종속성을 분석한 결과, 각 프로젝트가 불안전한 메모리 언어로 작성된 다른 구성 요소에 의존한다는 사실도 드러났다.다. 심지어는 안전한 메모리 언어로 작성된 프로젝트까지 포함해, 대부분의 중요한 오픈소스 프로젝트에 메모리 안전 취약점이 잠재적으로 포함되어 있다는 것이다.

메모리에 안전하지 않은 코드, 널리 퍼져있어

오픈 소스 보안업체인 ‘Endor Labs’사는 “취약점 종류 전반에 걸쳐 1년 간 공격유형을 살펴보면, 메모리에 안전하지 않은 언어는 매년 가장 일반적으로 악용되는 취약점 중 하나임을 알 수 있을 것”이라고 기술매체 ‘테크리퍼블릭’에 밝혔다.

그럼에도 불구하고, 개발자들은 메모리에 안전하지 않은 코드로 하드웨어와 메모리를 직접 조작할 수 있게 한다. 그 때문에 이는 널리 유포될 실정이다. 이는 운영 체제 커널, 드라이버, 임베디드 애플리케이션의 암호화 및 네트워킹처럼 성능과 리소스 제약이 중요한 요소인 경우에 유용하다.

개발자는 위험을 인식하지 못하거나 방해받지 않기 때문에 메모리가 안전하지 않은 언어를 사용하는 경우가 많다. 또한 안전한 메모리 언어의 메모리 안전 기능을 의도적으로 비활성화할 수도 있다. 그러나 위험을 알고 있고 메모리에 안전하지 않은 코드를 통합하고 싶지 않은 사람들도 의도치 않게 외부 프로젝트에 대한 종속성을 통해 통합하는 경우가 많다. 그 바람에 메모리에 안전하지 않은 언어로 된 종속성이 쉽게 보안 기능을 우회할 수 있다는 설명이다.

메모리에 안전하지 않은 코드 위험 줄이려면…

이에 기업이나 조직은 오픈 소스 개발자가 안전한 언어로 된 코드로 전환하도록 장려하기 위해 인센티브와 각종 리소스를 제공하고, 보안 코딩 관행이 구현되도록 하는 노력도 기울여야 한다는 조언이다.

해당 보고서는 또 “최근에는 프로젝트 자체가 메모리에 안전하지 않은 언어의 성능과 유사하므로 기존 프로젝트를 메모리 안전 언어로 전환해야 한다.”면서 “메모리에 안전한 언어로 새 프로젝트를 작성하고, 메모리 안전 프로그래밍을 시스템에 통합하며, 외부 종속성에서 메모리 안전을 해결하기 위한 명확한 계획을 포함하는 메모리 안전 로드맵을 만들 필요가 있다”고 강조했다.

이와 함께 타사 라이브러리나 구성 요소도 메모리에 안전하며, 완화 조치가 적용되어 있는지 확인하여 외부 종속성을 관리해야 한다는 지적이다. 특히 메모리에 안전한 언어로 개발자를 교육하는 것도 중요하다. 또한 ‘Secure by Design’ 원칙을 준수하는 등 소프트웨어 수명주기 초기부터 소프트웨어 설계의 보안을 우선시할 필요가 있다고 권했다.