메모리 안전 언어 채택, 어떻게 유도해야 할까

소프트웨어 코드의 보안을 강화하기 위해 메모리 안전 언어를 사용하려는 움직임이 활발하다. 마이크로소프트, 구글, 메타 등이 C 및 C++ 대신 러스트 같은 메모리 안전 언어로 중심을 이동하고 있다. 여기에 비영리단체인 컨슈머리포트가 기존 프로그래밍 언어에서 메모리 안전 언어로 전환을 권고하며 구체적 방안을 연구해 발표했다.

25일 미국 지디넷에 따르면, 컨슈머리포트는 최근 '메모리 안전의 미래'란 제목의 보고서를 발간했다.

작년 10월 메모리 안전 언어 채택의 장려 방법을 논의하기 위해 컨슈머리포트에서 개최한 온라인 회의의 내용을 정리한 보고서다. 이 행사는 메모리 안전과 관련된 리소스를 공유하고, 보안 생태계의 기회와 장벽을 논의하는 한편, 시장 전반에 걸쳐 제품에 존재하는 메모리 접근 취약성에 대한 잠재적 해법을 모색하는 자리였다.

컨슈머리포트의 이 보고서에 미국 사이버보안 및 인프라 보안국(CISA), 인터넷보안연구그룹, 구글, 미국 국가사이버국 등의 대표를 비롯해 정보보안 분야 저명인사들이 의견을 냈다.

보고서는 "브라우저와 커널의 C 및 C++ 코드 베이스에서 발견되는 취약점 중 약 60~70%는 메모리 안전 문제 때문이며, 그중 다수는 메모리 안전 언어를 사용해 해결할 수 있다"며 "조직에서 이런 종류의 버그를 감지하고 수정, 완화하는데 상당한 노력과 자원을 투입하더라도 메모리 불안전성은 심각도 높은 보안 취약성과 안전성 문제의 대부분을 계속 나타내므로 처음부터 버그를 방지하려는 노력을 강화해야 한다"고 밝혔다.

컨슈머리포트는 "정부, 업계 개발자 등이 메모리 안전 언어를 사용하고, 메모리 안전 언어로 전환을 위해 가장 중요한 라이브러리와 패키지를 식별해야 한다"고 강조했다.

또 "사용자 행동이나 소비자 선택을 통해 해결할 수 없는 업계 전반의 위협을 해결해야 하며, 메모리 안전문제가 그런 문제 중 하나"라고 설명했다.

보고서는 대학 내에서 메모리 안전 언어를 채택할 수 있는 환경을 구축하고, 메모리 안전 언어에 대한 불신을 해소하며, 다른 언어로 작성된 코드 베이스에 메모리 안전 언어를 도입하기 위한 인센티브를 제공하는 등의 문제를 담고 있다.

최근 2년 사이 여러 소프트웨어 프로젝트가 C나 C++ 대신 러스트를 채택해 메모리 안전성을 높이고 있다. 메타를 비롯해, 구글의 안드로이드 오픈소스 프로젝트(AOSP), C++ 기반 크로미엄 프로젝트, 리눅스 커널 등이 러스트를 도입하고 있다.

2019년 마이크로소프트는 지난 12년 간 수정한 보안 버그의 70%를 메모리 안전 문제로 분류했다. 윈도가 대부분 C와 C++로 작성됐기 때문에 높은 수치를 보였다. 작년 미국 국가안보국(NSA)은 프로그래밍 언어를 C 및 C++에서 C#, 자바, 루비, 러스트, 스위프트 등 메모리 안전 언어로 전환할 것을 권고했다.

소스코드의 메모리 관리 문제는 프로그램 실행 오류와 성능 저하, 충돌 등의 문제도 야기할 수 있다.

C계열 언어의 메모리 안전 문제에 대한 관심은 C++의 안전성에 대한 계획을 고안하도록 압박했다. C++의 창시자인 비야네 스트롭스트룹과 그의 동료들은 C++ 표준위원회워킹그룹21(WG21)을 통해 C++ 안전성 확보 계획을 세워 진행중이다.

C와 C++은 빠른 성능 때문에 여전한 인기를 누리고 있다. 임베디드 시스템 다수가 C++로 작성되고 있다.

보고서는 먼저 메모리 안전 언어 채택을 저해하는 두가지 장애물로 '교육'과 '불신 또는 혐오'라고 지적했다.

교육의 경우 컴퓨터 과학 전공과정 교수가 성적평가에서 메모리 안전 문제를 강조하거나, 메모리 안전 언어 관련 교육과정을 추가할 수 있다. 그러나 기존 교육과정에 메모리 안전 문제를 추가할 여유가 적고, 컴퓨터 과학 커리큘럼도 이미 많이 있어 새 과정을 추가하기 쉽지 않다.

학생들이 러스트 같은 메모리 안전 언어를 어렵게 느끼는 경향도 있다. 배우기 어렵고, 하드웨어와 함께 사용하기 어려울 것이란 인식이다.

교수와 학생 모두 졸업 후 취업 문제 때문에 언어 선택을 고민한다. 미래에 취업할 회사에서 메모리 안전 언어 전문가를 원하지 않는다면 굳이 교육과정을 운영할 필요가 없어진다.

보고서는 "이 패턴을 바꾸려면 산업 자체가 바뀌어야 한다"며 "어떤 회사가 메모리 안전 언어 사용자를 고용하고 있고, C 및 C++ 사용자를 고용하는지 더 많은 데이터를 공유해야 한다"고 밝혔다. 특정 기업의 소프트웨어자재명세서(SBOM)을 검사해 이같은 데이터를 얻을 수 있다고 제안했다.

메모리 안전 언어에 대한 불신과 혐오도 퍼져 있다. 실무 엔지니어의 저항도 있고, 경영진이 새로운 언어를 불신하기도 한다. 이메디드나 IoT 장치의 플랫폼 호환성 문제로 C와 C++ 사용을 유지하기도 한다. 무엇보다 기존 투자에 대한 매몰비용이 언어 전환에 저항하는 중요한 이유다.

보고서는 기존 소프트웨어의 코드를 처음부터 메모리 안전 언어로 재작성하기보다 점진적으로 새 언어의 비중을 늘려가는 방법을 사용해야 한다는 합의 사항을 전했다. 샌드박스 같은 구성요소 격리방식이나, 웹어셈블리 컴파일, 메모리 안전 언어로 재작성 등의 합리성과 시점에 대한 의견이 갈린다고도 밝혔다.

구성요소 격리 방식은 샌드박스 내부에서 메모리 안전 버그를 악용할 수 있다. 웹어셈블리 컴파일은 런타임 성능 비용을 높이고,  툴체임의 복잡성을 추가할 수 있다. 메모리 안전 언어로 재작성은 구현에 높은 초기 비용을 투입해야 하고, 일시적인 논리적 버그 증가를 보일 수 있다.

리눅스의 경우 기존의 커널 코드를 러스트로 재작성하지 않고, 일부 드라이버에서 러스트를 활성화하는 방식을 사용한다. 크로미엄은 사업적으로 타당한 부분부터 러스트를 활성화하는 한편, C++ 코드용 메모리 안전 기능도 구축하고 있다. AOSP는 새로 작성되는 코드에서 러스트 비중을 늘리는 방식이다.

보고서는 "기업이 버그의 원인을 투명하게 공개하고, 보안 취약성에 대한 자세한 정보를 제공해야 한다"며 "이를 통해 업계 전문가와 연구원이 취약성 중 메모리 안전 문제의 비율을 확인할 수 있다"고 밝혔다.

하지만 취약점 공개는 결함의 원인을 특정 언어와 연결하는 데 충분한 정보를 제공하지 않는다. 예를 들어 애플의 보안 공지는 C와 C++로 인한 메모리 취약성과 논리 버그를 구별할 수 있는 충분한 세부 정보를 제공하지 않는다.

보고서는 메모리 안전 문제를 완전히 해결하는데 필요한 사회적, 상업적 인센티브의 부족을 인정하고 있다. 보고서는 "메모리 안전 언어 채택에 대한 장벽과 시간, 비용 등의 문제를 극복하려면 효과적인 지지가 필요하다"고 지적했다.

일반적으로 회사의 엔지니어는 내부 자원의 부족을 겪고, 보안 버그 처리에 외부 인력을 고용할 선택권을 제한받기 쉽다. 보안 버그 문제 해결 작업을 위한 지원이 필요하다.

정부 조달의 경우 메모리 안전 언어 사용에 대한 로드맵을 세워야 한다고 제안했다. 정부가 메모리 안전 언어를 사용한 제품만 구매하도록 당장 강제할 수 없으므로, 로드맵을 수립해 메모리 안전 언어 사용을 유도하란 것이다.

보고서는 "정부가 새로 개발된 커스텀 구성요소를 메모리 안전 언어로 작성해야 산업을 발전시킬 수 있다고 말하는 게 가능하다"며 "이를 위해 해당 시스템에 대한 중앙의 조정과 신뢰가 필요하므로 회사가 점진적으로 제품에서 메모리 불안전 코드를 제거하는 계획을 제출하도록 할 수 있다"고 제안했다.

메모리 안전 언어 사용을 촉진하기 위한 또 다른 아이디어로, 개발자가 소프트웨어 일부에서 사용하는 메모리 안전 완화 방안을 나열하도록 하는 것이다. 안전 언어로 작성된 코드의 비율, 감사, 퍼징, 샌드박싱, 최소 권한 등을 명시하는 식이다. 또한 조직이 레거시 코드를 안전 언어로 전환하도록 규제와 금전적 인센티브를 제공할 것도 권했다.