“관리형” 경계는 벽이 아니었다
Supabase, Neon, Amazon Aurora와 같은 관리형 PostgreSQL 제공업체는 고객에게 강력한 관리자 역할을 제공하지만 진정한 superuser 권한은 제한합니다. 이들은 사용자가 기본 호스트나 다른 고객에게 영향을 주지 않고 데이터베이스를 제어할 수 있는 안전한 멀티 테넌트 환경을 제공하는 것을 목표로 합니다.
제공업체는 사용자 지정 확장 프로그램이나 후크를 배포하여 이를 달성합니다. 이러한 계층은 가장 높은 고객 대면 역할에서도 파일 시스템과 관련된 잠재적으로 위험한 작업을 가로채고 차단합니다. 예를 들어, 제공업체는 서버 디스크에 대용량 객체를 쓰도록 설계된 기본 PostgreSQL 함수인 lo_export를 차단할 수 있습니다.
그러나 이러한 사용자 지정 제한 계층은 잘못된 보안 의식을 심어줄 수 있습니다. 가드레일이 명령의 기본 기능이 아닌 이름만 확인한다면, 사용자는 차단을 우회할 수 있습니다. 동일한 내부 C 함수 별칭을 모니터링되지 않는 새 이름으로 다시 등록하면 차단 목록을 우회하여 제한된 기능을 호출할 수 있게 됩니다. 이러한 근본적인 간과가 심각한 취약점의 기반이 되었습니다.
필터를 통과한 새로운 이름
보고된 우회 사례는 이름 기반 필터링의 결정적인 사각지대를 악용했습니다. PostgreSQL의 lo_export 함수는 데이터베이스 대용량 객체를 서버 파일에 직접 씁니다. 관리형 제공업체는 이러한 위험을 인식하고 일반적으로 lo_export를 이름으로 차단하여 강력한 고객 역할이라도 실행하지 못하도록 방지합니다.
한 보안 연구원은 이 가드레일을 우회하는 방법을 시연했습니다. 그들은 PostgreSQL의 LANGUAGE internal 메커니즘을 사용하여 기본 내부 루틴에 대한 액세스를 재현했습니다. 이를 통해 차단된 lo_export와 동일한 백엔드 C 구현을 가리키는 모니터링되지 않는 이름의 새로운 함수를 정의할 수 있었습니다.
이 기술은 위험한 기능을 다른 라벨 아래에서 효과적으로 복제하여 제공업체의 보안 확장 프로그램을 우회했습니다. 이 별칭 함수를 사용할 수 있게 되자 연구원은 데이터베이스 서버의 디스크에 임의의 파일을 쓸 수 있었습니다.
이 취약점은 이름 기반 필터링에만 의존하는 보안 모델의 근본적인 약점을 강조합니다. 대체 이름이 동일한 기본 구현을 가리킬 수 있으므로, 라벨만 확인하는 것은 기능을 제어하는 것과 동일하지 않습니다. 제공업체의 확장 프로그램은 "lo_export"라는 단어는 차단했지만 서버에 파일을 쓰는 행위는 차단하지 않아 치명적인 설계 결함이 노출되었습니다.
SQL 권한에서 호스트 수준 코드로
차단되지 않은 별칭으로 작동하는 복제된 lo_export 함수는 PostgreSQL 호스트에 임의의 파일을 쓸 수 있는 능력이라는 결정적인 기본 요소를 제공했습니다. 공격자는 이를 악용하여 서버 디스크에 컴파일된 공유 라이브러리(.so 파일)를 배치했습니다.
악성 라이브러리가 배치되면 다음 단계는 이를 PostgreSQL C 언어 함수로 등록하는 것입니다. 이는 CREATE FUNCTION ... LANGUAGE C를 통해 수행되며, PostgreSQL에 공유 라이브러리의 특정 함수를 데이터베이스의 SQL 환경으로 직접 로드하고 노출하도록 지시합니다.
공격자가 간단한 SQL 쿼리를 통해 새로 등록된 C 언어 함수를 호출하면 데이터베이스는 해당 임의 코드를 실행했습니다. 중요한 점은 이 코드가 데이터베이스 호스트에서 PostgreSQL 프로세스 자체의 운영 체제 권한으로 실행되었다는 것입니다. 이는 루트(root) 액세스 권한은 아니며, 인스턴스가 일반적으로 격리되어 있기 때문에 다른 고객의 데이터에 대한 액세스 권한을 자동으로 부여하지도 않습니다.
그러나 호스트 실행은 중요한 거점을 제공합니다. 이는 서버에 대한 지속성(persistence)을 확보하고, 포괄적인 시스템 열거를 가능하게 하며, 서비스 제공업체의 인프라 내에서 측면 이동(lateral movement) 시도를 용이하게 할 수 있습니다. 심각성은 각 관리형 서비스의 구체적인 격리 메커니즘과 네트워크 구성에 따라 크게 달라집니다. 자세한 기술적 분석은 Breaking the PostgreSQL Superuser Guardrails: Attacking Security-Hardening Extensions을 참조하십시오.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
제공업체는 판매하는 경계를 보호해야 합니다
Supabase는 신속하게 대응하여 4가지 치명적인 문제에 대한 패치를 보고했습니다. 다른 제공업체들은 더 느리거나 불분명한 공개 대응을 보인 반면, PostgreSQL 코어 팀은 PostgreSQL의 보안 모델이 superuser가 내부 기능을 제어한다고 가정한다는 점을 강조하며 서비스 제공업체에 책임을 분명히 했습니다.
더 깊은 통찰력을 원하는 독자는 Mehmet Ince의 기초 연구인 “Breaking the PostgreSQL Superuser Guardrails”를 참조해야 합니다. supautils 프로젝트 또한 중요한 참고 자료를 제공하며, 역할 및 지원되지 않는 작업에 대한 Supabase의 상세 문서도 이러한 교훈을 반영하고 있습니다.
이번 사건은 제공업체들에게 냉혹한 교훈을 줍니다. 위험한 작업을 이름으로 차단하는 것만으로는 충분하지 않습니다. 강력한 보안을 위해서는 다음이 필요합니다. - 내부 및 C 언어 바인딩에 대한 엄격한 제어 - 세심한 카탈로그 권한 관리 - 더 강력한 OS 수준의 격리
단순히 더 긴 차단 목록이 아니라 이러한 조치들이 그들이 판매하는 관리형 경계를 보호하는 데 필수적입니다. 클라우드 PostgreSQL의 무결성은 제공업체가 약속한 경계를 얼마나 잘 강제하느냐에 달려 있습니다.
자주 묻는 질문
관리형 PostgreSQL 취약점은 무엇이었나요?
한 연구원이 제공업체의 필터가 차단하지 않는 이름으로 위험한 PostgreSQL 내부 함수를 등록하여 제공업체의 제한을 우회했습니다.
이 결함으로 다른 고객의 데이터베이스 내용이 노출되었나요?
자동으로 노출되지는 않았습니다. 입증된 권한 상승은 데이터베이스 호스트에서 PostgreSQL 운영 체제 사용자로서의 코드 실행을 제공했으며, 이는 다른 테넌트의 데이터에 즉시 액세스하는 것이 아니라 거점을 확보하는 것이었습니다.
이것이 PostgreSQL 코어 취약점이었나요?
PostgreSQL 보안 팀은 이를 제공업체 측의 문제로 규정했습니다. 관리형 서비스는 스스로 부과하는 권한 제한을 안전하게 강제해야 합니다.
관리형 PostgreSQL 제공업체는 무엇을 변경해야 하나요?
위험한 내부 및 C 언어 함수 바인딩을 제한하고, 카탈로그 권한을 강화하며, 운영 체제 수준에서 데이터베이스 프로세스를 격리해야 합니다.