Lakebase Postgres 취약점 공개 사례 연구
작성자: Aaron Kobayashi, Mehmet D. Ince, Anurag Srivastava , Alexey Kondratov
저희의 가장 성공적인 보안 투자 중 일부는 도구나 스캐너가 아니었습니다. 바로 관계였습니다. Databricks가 버그 바운티 프로그램을 운영하는 이유는 플랫폼의 취약점을 가장 빠르게 찾는 방법이 재능 있고 호기심 많은 사람들이 직접 찾아보게 하는 것이기 때문입니다. 또한 그들이 무언가를 발견했을 때, 선의의 보고에 선의의 대응으로 보답하기 위함입니다. 대부분의 보고는 조용히 처리됩니다. 누군가 버그를 발견하면 저희가 이를 수정하고, 모두가 다음 단계로 넘어갑니다.
가끔은 그중 하나가 정말 흥미로운 이야기로 발전하기도 합니다. 이번 이야기가 바로 그렇습니다.
몇 주 전, 외부 연구원인 Mehmet Ince가 Lakebase Postgres 및 Neon을 포함한 관리형 Postgres 플랫폼에서 제공되는 Postgres 확장 프로그램의 메모리 안전성 버그를 제보해 주었습니다. 이 글을 쓸 만한 가치가 있게 만든 것은 단순히 버그 자체만이 아닙니다. 버그를 둘러싸고 일어난 일들 때문입니다. 저희 탐지 시스템이 그의 테스트를 어떻게 포착했는지, 저희가 얼마나 신속하게 고객을 보호할 수 있었는지, 그리고 실제 해결책이 어떻게 원래 있어야 할 곳으로 돌아갔는지에 대한 이야기입니다. 저희뿐만 아니라 동일한 확장 프로그램을 실행하는 모든 사람을 위해 오픈 소스 생태계로 말이죠.
보안 팀을 운영하시거나, 관리형 오픈 소스 인프라를 관리하시거나, 혹은 연구원과 벤더 간의 건강한 상호작용이 양측에서 실제로 어떻게 이루어지는지 궁금하시다면 이 글이 도움이 될 것입니다. Mehmet은 자신의 블로그에 상세한 기술적 취약점 공격 이야기를 작성했습니다. 여기서는 협업에 대해 이야기하고자 합니다.
| Mehmet의 블로그는 다른 플랫폼에서의 고객 간 데이터 노출을 언급하고 있습니다. Databricks는 컴퓨팅 인스턴스 간에 강력한 보안 경계를 제공하는 microVM 아키텍처에서 Lakebase Postgres 및 Neon을 실행합니다. Mehmet의 취약점 공격은 Databricks의 다른 고객에게 어떠한 영향도 미치지 않았습니다. |
|---|
Postgres 확장 프로그램 생태계는 Postgres 인기의 주요 원동력이며, 벤더마다 지원 범위는 다르지만 고객들은 관리형 제공업체가 가장 널리 사용되는 핵심 및 서드파티 옵션을 지원하기를 기대합니다. 그중 하나가 지리 공간 툴킷인 PostGIS입니다. PostGIS 내부에는 address_standardizer라는 작고 눈에 띄지 않는 확장 프로그램이 있어, 123 Main St와 같은 비정형 주소를 정규화된 형식으로 변환해 줍니다.
Mehmet은 address_standardizer에 전형적인 메모리 안전성 결함이 있음을 발견했습니다. 호출자가 완전히 제어하는 값(호출자가 제공할 수 있는 문법 "규칙"의 일부)이 경계 검사 없이 고정 크기의 내부 배열 인덱스로 사용된 것입니다. 범위를 벗어난 값을 입력하면 범위를 벗어난 메모리 액세스가 발생합니다.
관리형 Postgres 서비스에서 중요한 점은 누가 여기에 접근할 수 있는가입니다. address_standardizer는 일반 테넌트가 설치하고 사용할 수 있는 확장 프로그램 세트에 포함되어 있습니다. 따라서 이 버그는 접근하는 데 특별한 권한이 필요한 버그가 아니었습니다. 일반 고객 역할로도 함수를 호출하여 취약한 코드 경로에 도달할 수 있었습니다. 바로 이러한 특성 때문에 조용히 넘어가기 쉬운 버그가 플랫폼 팀이 심각하게 받아들여야 하는 문제로 바뀌게 됩니다.
여기서는 취약점 공격의 세부 정보를 의도적으로 간략하게 다룹니다. Mehmet의 심층 분석에서 이 메커니즘을 제대로 다루고 있으며, 요약본보다 훨씬 더 자세히 설명되어 있습니다.
작성자: Mehmet D. Ince
이 이야기는 취약점 연구로 시작된 것이 아니었습니다. 올봄 내부 회의 중에 저희 팀은 PostgreSQL 인스턴스 몇 개를 관리형 제공업체로 마이그레이션할 수 있는지 물었습니다. 약 50명의 엔지니어가 근무하는 유럽의 위협 인텔리전스 기업인 PRODAFT의 CTO로서, 제 책임 중 하나는 고객에게 가능한 가장 안전한 서비스를 제공하는 것입니다.
저희는 10년 이상 PostgreSQL을 직접 운영해 왔지만, 관리형 Postgres 제공업체가 보안 관점에서 이러한 서비스를 어떻게 제공하는지 제대로 검토해 본 적이 없었습니다. 저는 2000년대 초반부터 취약점 연구를 해왔기 때문에, 새로운 기술을 스택에 추가하는 것만으로 감수해야 하는 위험을 더 잘 이해하기 위해 항상 약간의 시간을 내어 보안 연구를 진행하곤 합니다. 놀랍지도 않게, 저의 "빠른 검토"는 결국 누군가의 수신함에 치명적인 취약점 보고서를 남기는 것으로 끝나곤 합니다. 오래된 습관은 버리기 어려운 법이니까요.
연구를 시작한 지 며칠 지나지 않아, 거의 모든 제공업체가 거의 동일한 Postgres 확장 프로그램을 제공한다는 사실을 깨달았습니다. 널리 배포된 확장 프로그램의 메모리 손상 취약점은 사실상 PostgreSQL 자체의 메모리 손상 취약점과 같습니다. 그래서 저는 거의 모든 곳에서 사용할 수 있는 소형 PostGIS 확장 프로그램인 address_standardizer를 대상으로 선택했습니다.
이곳 런던 시간으로 어느 월요일 저녁 7시쯤, Aaron이 전혀 예상치 못하게 저에게 이메일을 보내 Neon의 프로덕션 경보를 발생시킨 활동이 제 소행인지 물었습니다. 저는 작고 무해한 확장 프로그램의 단순한 버그 하나가 실제로 권한 상승 경로를 노출할 수 있는지 확인하기 위해, 작동 중인 익스플로잇을 Neon PostgreSQL 인스턴스에 포팅하는 작업을 하고 있었습니다. 작동하는 PoC가 있었지만, 저는 그에게 스크린샷만 보냈습니다. 그 스크린샷 한 장만으로도 그는 즉시 조치를 취하기 시작했습니다!
저는 20년 이상 벤더들에게 취약점을 책임감 있게 공개해 왔지만, 오랜 세월이 지난 지금도 적절한 담당자를 찾는 데 많은 시간을 허비하지 않고는 발견한 문제의 영향과 위험성을 설명하기가 여전히 어렵습니다. 연구원들에게 먼저 선제적으로 연락을 취하고 이처럼 신속한 조치를 취해준 Aaron과 Databricks 보안 팀에 아낌없는 박수를 보냅니다!
자세한 내용은 Mehmet의 게시글을 참조하세요.
저희 입장에서는 이번 사례가 공동 공개가 원래 의도대로 작동한 모범적인 사례입니다.
Mehmet이 증거를 공유했고, 당일 말까지 보고서가 적절한 담당자들에게 전달되었으며, 저희 보안 엔지니어들은 Neon이 제공하는 정확한 PostGIS 버전을 대상으로 이를 검증했습니다. 저희는 일반 테넌트 역할로 취약한 코드 경로에 도달할 수 있음을 확인하고 이에 따라 조치를 취했습니다.
초기에 저희는 모든 플랫폼 팀이 결국 직면하게 되는 질문이기에 명확히 밝힐 가치가 있다고 생각하 는 결정을 내렸습니다. 바로 제공하는 오픈 소스 구성 요소의 버그 역시 당사의 문제라는 점입니다. 근본 원인은 업스트림인 PostGIS에 있었지만, 그에 따른 노출은 저희의 몫이었습니다. 저희가 기본적으로 테넌트에게 해당 확장 프로그램을 제공했기 때문에 그 영향에 대한 책임은 저희에게 있었습니다. 저희는 이를 "서드파티" 문제로 치부하지 않았습니다. 대신 보고를 수락하고 대응을 주도했으며, 문제를 제기한 연구원에게 포상했습니다.
또한 고객이 위험에 노출되어 있는 동안 업스트림 릴리스 일정만 마냥 기다릴 수는 없었습니다. 저희의 확장 프로그램 빌드 시스템은 컴파일 및 패키징 전에 업스트림 Postgres 확장 프로그램 위에 임의의 패치 세트를 적용할 수 있도록 의도적으로 설계되었습니다. 이를 통해 수정 사항을 백포팅하거나 자체 빌드에서 위험한 코드 경로를 비활성화할 수 있습니다. 이 패치 세트는 업스트림 소스가 아닌 다운스트림에 존재하기 때문에, 업스트림의 릴리스 시점과 무관하게 독립적으로 조치를 취할 수 있습니다. 덕분에 고객을 보호하기 위해 신속하게 조치를 취하는 동시에, 생태계를 올바르게 수정하기 위한 작업을 병행할 수 있었습니다.
지속 가능한 해결책을 구축하는 데는 몇 번의 반복 작업이 필요했습니다. 첫 번째 패치로는 모든 사례를 다루지 못했기 때문에, 불완전한 버전을 배포하기보다는 일주일의 시간을 더 들여 제대로 해결하고자 했습니다. 강화된 수정 사항이 배포되어 Neon 및 Lakebase 테넌트들을 보호했으며, 고객들은 직접 어떠한 조치도 취할 필요가 없었습니다.
여기서부터 흥미롭고 조금은 운이 좋았던 부분이 시작됩니다.
표준 수정 사항은 PostGIS의 몫이었습니다. 그들의 코드이고, 그들의 릴리스이며, 그들의 결정이기 때문입니다. Databricks는 지리 공간 분야의 핵심적인 토대를 자원봉사자로서 이끌어가고 있는 PostGIS 메인테이너 분들께 감사를 표합니다. Mehmet 역시 같은 생각이었고, 이를 행동으로 옮겼습니다. 그는 받은 포상금을 PostGIS 프로젝트에 기부했으며, 자신의 사비를 더해 전체 관리형 Postgres 업계가 의존하고 있는 자원봉사자들의 노력에 보답했습니다. 저희의 계획은 간단했습니다. 먼저 고객을 보호한 다음, Mehmet과 협력하여 업스트림에서 근본 원인을 해결함으로써 Neon뿐만 아니라 address_standardizer를 실행하는 모든 사람이 혜택을 볼 수 있도록 하는 것이었습니다.
그러다 우연한 일로 상황이 복잡해졌습니다. 비슷한 시기에 근본적인 버그가 업스트림에서 CVE 등록이나 별다른 요란함 없이 사소한 메모리 누수 수정으로 패치된 것입니다.
알고 보니 업스트림 수정 사항이 모든 사례를 해결하지는 못했습니다. Mehmet은 부족한 부분을 정확히 검증하여 나머지 부분을 업스트림에 다시 제출함으로써 전체 커뮤니티의 공백을 메웠습니다. 이 체인에 대해서는 CVE가 할당되지 않았는데, 이는 중요한 메모리 안전 수정 사항이 릴리스 노트에 "사소한" 정리 작업으로 얼마나 쉽게 누락될 수 있는지 보여주는 작은 교훈입니다.
우리가 중요하게 생각하는 시사점은 연구자가 근본 원인에 대해 올바른 조치를 취했고, 업스트림은 완전한 수정 사항을 반영했으며, 이 모든 과정이 진행되는 동안 당사 고객들은 이미 보호받고 있었다는 점입니다.
오픈 소스 구성 요소를 기반으로 구축된 관리형 서비스(관리형 데이터베이스 등 모든 관리형 서비스)를 운영하는 경우, 이 이야기의 불편한 진실은 여러분의 공격 표면에 직접 작성하지 않은 코드와 해당 코드의 작성자가 전혀 고려하지 않았을 수 있는 위협 모델이 포함된다는 점입니다. 작고 대중적이며 오랫동안 업데이트되지 않은 확장 프로그램은 배포하기는 쉽지만 잊어버리기도 쉬운 대표적인 예입니다.
저희에게 효과적이었고 여러분에게도 도움이 될 수 있는 몇 가지 방법은 다음과 같습니다.
보안 연구자이시라면 언제든 의견을 보내주시기 바랍니다. 특히 Mehmet처럼 플랫폼에 미치는 실질적이고 측정 가능한 영향을 보여줄 수 있는 경우라면 더욱 환영합니다. hackerone.com/databricks를 통해 보고해 주세요.
잘 문서화된 선의의 보고를 제공하고 업스트림의 근본 원인에 대해 올바른 조치를 취해 준 Mehmet Ince에게 감사드립니다. 이에 의존하는 지리 공간 분야에서 큰 비중을 차지하는 오픈 소스 작업을 수행해 주신 PostGIS 메인테이너 분들께 감사드립니다. 그리고 보고된 내용을 신속하고 침착하게 배포된 수정 사항으로 전환해 준 Neon 및 Lakebase 엔지니어들에게 감사드립니다.
플랫폼을 더 안전하게 만들기 위해 저희와 협력하는 모든 연구자분들의 노고를 잘 알고 있으며 깊이 감사드립니다. HackerOne에서 뵙겠습니다.
(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)
블로그를 구독하고 최신 게시물을 이메일로 받아보세요.