Trawling

PostgreSQL, 낮은 권한 계정의 서버 임의 코드 실행 취약점 수정

PostgreSQL은 네트워크로 접속해 데이터베이스 객체를 만들 수 있는 낮은 권한 계정이 서버 운영체제 권한으로 코드를 실행할 수 있는 CVE-2026-6460을 11월 12일 수정했습니다. 수정판은 18.7, 17.12, 16.16, 15.20, 14.25이며, 보호를 완전히 적용하려면 C 언어 확장 모듈을 다시 빌드해야 합니다.

PostgreSQL 프로젝트는 2026년 11월 12일 보안 업데이트에서 CVE-2026-6460을 수정했습니다. 이 취약점은 네트워크로 접속해 데이터베이스 객체를 만들 수 있는 낮은 권한 계정이 PostgreSQL 서버를 실행하는 운영체제 사용자 권한으로 임의 코드를 실행하게 할 수 있습니다. 공식 CVSS 3.0 점수는 8.8입니다. 취약점 조사자 Mehmet Ince(@mdisec)는 11월 9일 공개한 글에서 복합 자료형의 필드 형식을 바꾸는 동안 준비된 쿼리에 든 값이 이전 형식의 바이트를 유지하는 현상을 익스플로잇의 출발점으로 설명했습니다.

PostgreSQL은 SQL문을 먼저 준비하고 나중에 실행하는 prepared statement를 지원합니다. 복합 자료형은 여러 필드와 각 필드의 자료형을 한데 묶은 사용자 정의 형식입니다. PostgreSQL 내부의 값은 Datum이라는 공통 표현으로 전달되고, 이를 해석할 때는 값과 별도로 관리되는 자료형 설명을 참조합니다. 값의 바이트와 설명이 어긋나면 같은 메모리 내용을 다른 자료형의 규칙으로 읽을 수 있습니다.

Ince의 재현 사례에서 복합 자료형의 필드는 처음에 UUID였습니다. 쿼리를 준비한 뒤 필드 형식을 bytea로 바꾸고 실행하자, 쿼리 안의 16바이트 값은 UUID였을 때의 바이트를 그대로 유지했습니다. 복합 자료형을 결과로 내보내는 record_out()은 현재 필드 설명을 보고 임의의 바이너리 데이터를 저장하는 bytea의 출력 함수 byteaout()을 선택했습니다. 이 함수는 16바이트를 가변 길이 바이너리 값의 헤더와 확장 객체 포인터로 해석했습니다. UUID 데이터의 일부는 확장 객체를 가리키는 표식으로, 뒤따르는 바이트는 NULL 포인터로 읽혔고, 이를 따라가려던 PostgreSQL 프로세스가 충돌했습니다.

Ince는 충돌에 그치지 않고 메모리 주소를 노출하는 방법도 찾았습니다. 배열 원소를 꺼내는 unnest()는 배열 내부에 문자열 자료형으로 기록된 원소를 포인터로 반환하지만, SQL 쪽에서는 그 결과를 정수형으로 해석하도록 자료형을 어긋나게 만들었습니다. 그 결과 포인터 값을 숫자로 드러내 메모리 주소를 얻었습니다. Ince는 이 누출로 주소 공간 배치 난수화가 감추는 주소를 알아낸 뒤, 가짜 메모리 객체와 메서드 표를 구성해 PostgreSQL이 내부 함수 포인터를 따라 호출할 대상을 바꾸는 익스플로잇을 만들었다고 설명했습니다. 이 방식으로 코드는 데이터베이스 서버 프로세스의 운영체제 권한으로 실행됩니다.

공식 공지는 주된 공격 경로로 ALTER ... SET DATA TYPE을 들고, 다른 DDL 작업 조합도 공격 경로가 될 수 있다고 설명합니다. Ince는 자신의 재현 사례에서 가장 낮은 권한의 로그인 역할로 취약점을 실행했다고 썼습니다.

Ince가 말한 ‘22년 된’ 기반 동작과 익스플로잇에 이용한 메모리 표현은 서로 다른 시기에 PostgreSQL에 들어왔습니다. Ince는 자료형 변경과 관련된 기반 동작을 2004년 5월 5일 저장소에 반영된 변경과 연결했습니다. 익스플로잇이 이용한 expanded object와 내부 메서드 포인터 기능은 2015년 5월 14일 추가됐다고 설명했습니다. 그의 분석에 따르면 두 시기의 기능을 결합해 코드 실행으로 확장한 사례입니다.

수정판은 PostgreSQL 18.7, 17.12, 16.16, 15.20, 14.25입니다. 공식 공지는 각 버전대에서 이보다 낮은 버전을 영향 대상으로 분류했습니다. 수정은 복합 자료형의 값과 이를 해석할 자료형 설명자의 버전을 관리해 서로 맞지 않는 경우를 감지합니다. 릴리스 노트는 보호를 완전히 적용하려면 C 언어 확장 모듈을 다시 빌드해야 하며, 일부 확장은 소스 코드 수정도 필요하다고 설명합니다. 필요한 경우 새 composite_type_mismatch 서버 설정으로 검사를 끌 수 있지만, PostgreSQL 프로젝트는 이 설정을 비활성화하면 보안 위험이 따른다고 밝혔습니다.

참고 자료

오류 제보