🇰🇷 한글 설명
pgAdmin 4의 연결이 Kerberos 사용자의 위임 자격증명을 사용하지 않도록 설정된 경우, KRB5CCNAME 환경변수가 제거되어 pgAdmin을 실행하는 운영체제 계정의 기본 자격증명 캐시 또는 클라이언트 keytab이 사용되었습니다. 이로 인해 서버 모드에서 어떤 사용자든 서비스 계정의 Kerberos 주체로 데이터베이스에 접속할 수 있었으며, gssencmode=disable로도 이를 막을 수 없었습니다. 수정 버전(9.19 이상)에서는 해당 경로를 제한하고 GSSAPI/SSPI 인증을 명시적으로 차단합니다.
💡 쉬운 설명
pgAdmin이 서버에서 돌아갈 때 그 프로그램을 실행하는 계정의 Kerberos 로그인 정보가 다른 사용자에게도 쓰일 수 있는 문제입니다. 그 결과 누구든 서비스 계정 권한으로 데이터베이스에 접속할 수 있었습니다.
🇺🇸 원문 (English)
When a pgAdmin 4 connection was not meant to use a Kerberos user's delegated credentials, pgAdmin removed KRB5CCNAME from its environment, so the Kerberos library fell back to the default credential cache, or a client keytab, of the operating-system account running pgAdmin. libpq then answered any server that asked for GSSAPI authentication with that account's ticket, whatever user name the pgAdmin user gave, so in server mode any user could connect as the service account's Kerberos principal; gssencmode=disable did not prevent it. On Windows, SSPI used the service account's logon in the same way. psql was also started with pgAdmin's environment, which could hold another user's credential cache while that user was connecting.
The fix points KRB5CCNAME and KRB5_CLIENT_KTNAME at a file that cannot exist except while a Kerberos-authenticated user connects with Kerberos, and gives every other connection, psql and the utilities require_auth=!gss,!sspi and gssencmode=disable, checked on the final connection string. require_auth needs libpq 16 or later.
This issue affects pgAdmin 4: before 9.19.
📍 영향받는 시스템
pgAdmin 4 9.19 미만 버전 (서버 모드, Linux 및 Windows)
⚔️ 공격 벡터
pgAdmin 서버 모드에 로그인할 수 있는 인증된 사용자가 임의의 사용자명으로 Kerberos 인증을 요청해 서비스 계정의 티켓으로 데이터베이스에 접속
🛡️ 대응 방법
pgAdmin 4를 9.19 이상으로 업그레이드하고, 필요 시 libpq 16 이상을 사용하며 Kerberos 위임 자격증명 사용 설정을 검토합니다.
🔧 검증 코드
출력된 버전이 9.19 미만이면 취약하므로 업그레이드가 필요하고, 9.19 이상이면 수정된 버전입니다.
pgadmin4 --version 2>/dev/null || dpkg -l pgadmin4 2>/dev/null | grep pgadmin4