PostgreSQL 18.6 - Alta - Remota - Scrittura di file - pg_basebackup segue un symlink tar assoluto residuo di CVE-2026-6475
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · postgres-basebackup-symlink
Write-up: https://abraxaslabs.tech/research/postgres-basebackup-symlink
Classe: Scrittura di file Portata: Remota
PostgreSQL 18.6 (724edf9) - PostgreSQL Global Development Group
CVE-2026-6475 ha aggiunto path_is_safe_for_extraction per i nomi dei membri tar. I target dei symlink assoluti aggirano ancora quel controllo, così i tablespace funzionano. astreamer_file.c esegue poi symlink() sul target e successivamente fopen(..., "wb") lo segue. Il formato predefinito di pg_basebackup è plain (-F p). create_target_symlink di pg_rewind controlla il percorso e mai il link.
Una sorgente ostile che parla BASE_BACKUP può piantare un symlink assoluto e sovrascrivere qualsiasi file scrivibile dall'UID del backup. Stesso modello di vittima del 6475. Non è una nuova segnalazione dei controlli sui nomi dei membri.
| ID | nessuna CVE al momento |
| Classe | Scrittura di file (residuo del symlink tar assoluto di CVE-2026-6475) |
| Portata | Remota (client UI:R contro PostgreSQL ostile) |
| CWE | CWE-59, CWE-22 |
| CVSS | Alto: 8.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H |
| Prodotto | PostgreSQL |
| Affetto | tag 18.6 REL_18_6 (724edf9bde9d356724ad384a2e196edc3c9f80f7), pg_basebackup / pg_rewind in-tree |
| Auth | la vittima esegue il comando predefinito pg_basebackup -D <dir> contro una sorgente dell'attaccante |
| Licenza | GNU Affero GPL v3.0 |
| Lab | solo 127.0.0.1 |
Chi riesce a far eseguire a un operatore pg_basebackup -D contro il proprio PostgreSQL (lo stesso modello UI:R di CVE-2026-6475) può scrivere al di fuori di -D.
| Privilegio | Metodo / sink | Provato in lab o dedotto |
|---|---|---|
Integrità: scrivere un file fuori da -D | Tar BASE_BACKUP ostile: membro con typeflag '2' e nome relativo sicuro (pg_tblspc/16384) e target di link assoluto, poi un membro regolare con quel nome. extract_link e poi create_file_for_extract fopen(..., "wb") senza O_NOFOLLOW | Provato in lab. Ha scritto POSTGRES-BASEBACKUP-SYMLINK-WITNESS in /work/oracle/. La destinazione contiene il symlink. Il tar di controllo (senza symlink) ha lasciato l'oracle vuoto e ha scritto PG_VERSION solo dentro -D |
Integrità: sovrascrivere shell rc, authorized_keys, una unit systemd utente o crontab | Stesso sink, qualsiasi percorso scrivibile dall'UID del client | Dedotto. Questo lab non tocca quei file |
| Disponibilità: distruggere configurazioni o chiavi del client | Stessa scrittura | Dedotto. Non dimostrato |
| Ricognizione del disco del client | l'estrazione è scrittura, non lettura | Chiuso |
Attraversare .. o nomi dei membri assoluti | path_is_safe_for_extraction | Chiuso. È CVE-2026-6475 |
| SQL non privilegiato lato server / protocollo non autenticato | server predefinito 18.6 | Chiuso. Questo residuo è il client |
| Backup solo tar | pg_basebackup -F t memorizza il tar senza estrarlo | Chiuso |
RCE dentro postgres | non questo sink | Chiuso |
pg_rewind ha lo stesso residuo create_target_symlink / open(). Questo lab guida solo pg_basebackup.
Ho fissato postgres/postgres REL_18_6 dopo l'ondata 18.6 (28 CVE, più il set 18.4/18.2 già presente su questo albero). Ventidue ricerche. Server predefinito, SQL non privilegiato, protocollo non autenticato: nessuno a questo livello. CVE-2026-6475 era il fratello da rileggere.
I nomi dei membri sono controllati. I target dei symlink assoluti no:
if (!is_absolute_path(linktarget) &&
!path_is_safe_for_extraction(member->linktarget))
{
pg_fatal("link target has unsafe path name: \"%s\"",
member->linktarget);
}
extract_link(mystreamer->filename, linktarget);
create_file_for_extract è ancora fopen(filename, "wb"). Il commento in astreamer_file.c:351-356 afferma che la mappatura viene applicata senza verificare che il link sia all'interno di pg_tblspc.
Vicoli ciechi già registrati: considerare 6475 come chiuso e andare avanti; puntare -D a una directory dati attiva; sovrascrivere la rc della shell per pura teatralità. Un server 18.6 onesto emette solo symlink pg_tblspc/<oid> e colloca il contenuto del tablespace in un archivio separato. Una sorgente malevola che parla BASE_BACKUP può inserire il membro regolare successivo nello stesso tar. Questo è ciò che resta.
python3 postgres-basebackup-symlink-Abraxas-Labs.py
o
cd lab
./run.sh
postgres:18.6 come immagine sorgente, con un relatore BASE_BACKUP in esecuzione. Il client è pg_basebackup in-tree dallo stesso tag (pg_basebackup (PostgreSQL) 18.6). Loopback 127.0.0.1:19370. Progetto Compose postgres-basebackup-symlink. Non puntare -D a una directory dati attiva.
SUCCESS postgres-basebackup-symlink control-inside=yes oracle-outside=yes dest-is-symlink=yes image=postgres:18.6 how=pg_basebackup POSTGRES-BASEBACKUP-SYMLINK-WITNESS
Trattare i target dei symlink assoluti come non sicuri a meno che non vengano riscritti da --tablespace-mapping. Aprire i file estratti con O_NOFOLLOW / lstat in modo che un link piantato non possa essere seguito. Applicare path_is_safe_for_extraction per riavvolgere link oltre a path. Rifiutare un membro regolare il cui percorso attraversa un symlink che ha lasciato -D.
724edf9bde9d356724ad384a2e196edc3c9f80f7)src/fe_utils/astreamer_file.c · src/fe_utils/astreamer_tar.csrc/bin/pg_rewind/file_ops.cGNU Affero GPL v3.0. Vedi LICENSE. Solo laboratorio su loopback. Nessuna garanzia.