본 글은 PostgreSQL의 오래된 타입 혼동 기법을 원격 코드 실행(RCE) 및 권한 상승 공격으로 발전시키는 심각한 취약점을 분석합니다. 데이터베이스 내부에서 인증과 인가를 처리하는 방식의 구조적 결함이 지적되며, 이는 고성능 최적화 과정에서 발생한 설계상의 위험성을 보여줍니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기내가 잘못 이해한 게 아니라면 전부 SQL을 통한 공격으로 보이는데, 이미 인증된 원격 접근 권한이 필요한 것 아닌가? 보안 취약점은 맞지만 원격 코드 실행이라고 부르면 실제보다 더 위험하게 들림.
데이터베이스 계정으로 접근한 뒤 서버 전체 권한을 얻는 권한 상승에 더 가까워 보이며, 주로 다중 테넌트 데이터베이스에 해당하는 문제로 보임.
인증과 인가를 SQL 내부에서 처리할 수도 있음. 예를 들어 CREATE ROLE initial LOGIN NOINHERIT NOCREATEDB NOCREATEROLE NOSUPERUSER;로 역할을 만든 뒤, SQL로 자격 증명을 검증하고 데이터베이스에서 권한을 확인한 다음 SET LOCAL ROLE someuser;로 마무리하는 식임.
흔한 방식은 아니지만, 애플리케이션 계층의 일을 최소화하고 데이터베이스로 처리를 몰아주는 단순함을 선호하는 사람도 있음. 개발자들에게 수년간 N+1 쿼리 문제를 강조한 끝에 도달하는 논리적 귀결이기도 함.
공개 Postgres 인스턴스를 운영하는 곳도 있음. https://postpass.geofabrik.de/에서는 일반 HTTP API로 노출된 Postgres 인스턴스에서 OpenStreetMap 데이터를 조회할 수 있음.
인증 전에 실행할 수 없어도 RCE는 맞음.
글이 길고 두서없으며 사람이 쓴 부분과 AI가 쓴 부분이 섞인 듯하지만, 공격 방식은 흥미로움. 테이블에 대한 준비된 문장(prepared statement) 을 만들고 테이블을 변경한 뒤 실행하는 방식인데, 이때 갱신되어야 할 준비된 문장이 갱신되지 않은 상태로 실행됨.
RCE보다는 권한 상승 공격이라고 부르는 편이 맞다고 봄.
정해진 실행 환경인 RDBMS 밖에서 코드가 실행되므로 임의 코드 실행(ACE) 이라고 부르겠음. 기존에 인증된 RDBMS 접근 권한이 필요하므로 원격 공격은 아니라고 봄.
실제로 악용 가능한 취약점인가? 그렇다면 매우 심각하며, 패치되지 않은 상태로 공개된 것이라면 전 세계 수백만 기업에 영향을 줄 수 있음.
가능함. 단, 주 데이터베이스에 로그인한 상태여야 함.
수백만 기업이 PG 포트를 인터넷에 노출하고 allow 0/0으로 열어둔 경우에만 해당하는 것 아닌가? 실제 수치를 보자면 https://www.shodan.io/search?query=postgresql에는 51만 6천 개가 나옴. 적은 수는 아니지만 수백만과는 거리가 멀고, 결과를 훑어보면 모두 기업이라고 보기도 어려움.
합리적으로 운영하는 곳이라면 데이터베이스를 사용하는 애플리케이션에서만 접근할 수 있게 해둘 것임.
이건 단순한 코드 악취를 넘어 심한 악취가 나는 설계로 느껴짐. 글에 따르면 Postgres 내부의 Datum은 포인터일 수도, 아닐 수도 있는데, 이것부터 다소 위험함.
Datum에는 작은 정수형 타입 ID가 따로 붙어 있음. 여러 Datum이 하나의 ID를 공유하는 등 효율을 위한 설계일 수는 있지만, ID와 값의 연결이 올바르게 유지되는 근거가 명확해야 함. 잘못된 AST가 internal 관련 타입 혼동을 일으킨다는 대목을 보면 그 보장이 탄탄해 보이지 않음.
그런데 그 타입 ID를 데이터베이스의 시스템 테이블에서 조회한다니 말문이 막힘. 값이 포인터인지 알려주는 정보가 애플리케이션 메모리에조차 없으므로, 안전한 언어로는 표현할 수 없는 종류의 설계임.
AI가 잘못될 수 있는 모든 코드 경로를 열거해 특정 릴리스에서 문제가 없음을 확인하거나, Lean 프로그램으로 검증할 수는 있을지 모름. 그래도 구조 자체가 잘못되어 있으며, 모든 세부 구현이 거대한 함정을 피해야만 안전해지는 설계라고 봄.
소프트웨어 아키텍처상의 추상화임.
고성능 저수준 최적화의 세계에 온 것을 환영함. 타입 ID를 모든 곳에 저장하면 작은 필드는 크기가 두 배, 불리언처럼 아주 작은 필드는 네 배가 됨. 저장된 데이터 대부분은 테이블의 열 정보를 이미 알고 있으므로 그럴 필요도 없음. 더 작은 표현은 읽기와 쓰기를 빠르게 하고, 메모리에 더 많은 데이터를 담을 수 있게 해줌.
한 달 정도 사이에 LAMP 스택의 모든 계층에서 RCE가 나온 셈인가? 여기서 M이 Postgres는 아니지만, MySQL/MariaDB도 곧 뒤따를 것 같음.
이 댓글을 보고서야 Apache의 RCE를 알게 됨.
L, A, M, P지만 모두에 공통으로 들어가는 글자는 C임. 이제 그 대가를 치를 때가 된 셈임.