ssh-pur66/afterimageRicerca patch-diff per le issue pubblicate di urllib3: release bloccate, harness offline originali, comportamento prima/dopo e controlli benigni.
Creato e mantenuto da Sergio Rodriguez (SSH-PuR66). Gli harness sperimentali e le analisi sono miei; le vulnerabilità pubblicate, il codice di urllib3 e le correzioni upstream mantengono la loro attribuzione originale.
Metodo di ricerca dell'autore · Harness di redirect · Studio sul framing a chunk
Un redirect cambia la destinazione mentre tre header sensibili restano allegati. Un parser di framing accetta input che la release successiva rifiuta. Afterimage trasforma correzioni di protocollo pubblicate in piccoli esperimenti prima/dopo ispezionabili.
Ho costruito gli harness e i casi di controllo attorno a release di urllib3 fissate e non modificate. Ogni risultato registra l'hash del pacchetto, il comportamento catturato, il confine del fixture e l'attribuzione upstream.
| Studio | Release confrontate | Corpus registrato | Ispeziona |
|---|---|---|---|
| Confine degli header di redirect · CVE-2026-44431 | urllib3 2.6.3 / 2.7.0 | 12 casi, inclusi comportamento affetto e controlli benigni | Risultati · Harness |
| Framing a chunk · CVE-2026-97689 | urllib3 2.7.0 / 2.8.0 | 32 casi offline delimitati | Metodo e risultati |
Tipo di ricerca: riproduzione indipendente di problemi pubblicati. Confine misurato: gestione degli argomenti della libreria e comportamento del framing in memoria. La sfruttabilità a livello applicativo e l'esaurimento delle risorse restano al di fuori di questi risultati dei fixture.
CVE-2026-44431 · urllib3 2.6.3 → 2.7.0 · riprodotto il 27 settembre 2026
Una richiesta trasporta tre header sensibili verso un'origine. Un redirect cambia la destinazione. La richiesta successiva li trasporta ancora?
Questa regressione indipendente esegue la reale implementazione del redirect da due release esatte di urllib3. La versione 2.6.3 conserva tutti e tre gli header attraverso l'API di basso livello affetta. La versione 2.7.0 li rimuove. Un header benigno sopravvive, e le richieste ordinarie continuano a funzionare.
| Fixture | urllib3 2.6.3 | urllib3 2.7.0 |
|---|---|---|
| Redirect cross-origin di basso livello | 3 header sensibili conservati | 0 conservati |
| Stesso caso con nomi in minuscolo | 3 conservati | 0 conservati |
| Controllo con API di alto livello | 0 conservati | 0 conservati |
| Risposta 200 diretta | 3 conservati come previsto | 3 conservati come previsto |
| Redirect esplicitamente disabilitato | Una chiamata; 302 restituito | Una chiamata; 302 restituito |
| Set di rimozione personalizzato aggiunge marcatore benigno | Tutti e 4 gli header conservati | Tutti e 4 rimossi |
12/12 aspettative degli scenari superate. Ogni scenario verifica inoltre lo stato della risposta, il numero di chiamate di trasporto, il set iniziale di header, il risultato dell'header benigno e che gli header del chiamante non siano stati mutati. L'esito vulnerabile è un risultato di base atteso, non un controllo di sicurezza superato.
I risultati leggibili da macchina includono gli argomenti catturati, gli hash esatti dei wheel, il runtime, gli hash del codice di test, l'attribuzione e l'ora di riproduzione.
L'advisory upstream, pubblicato il 7 maggio 2026, identifica un problema di esposizione di informazioni nel percorso di redirect di basso livello con proxy di urllib3. Elenca le versioni >=1.23, <2.7.0 come affette. La chiamata ProxyManager.connection_from_url(...).urlopen(..., assert_same_host=False) poteva trasportare header sensibili configurati in una richiesta reindirizzata verso un'altra origine. L'API di alto livello del manager li rimuoveva già.
La correzione upstream applica Retry.remove_headers_on_redirect prima della richiesta ricorsiva di basso livello. Il nostro caso con header in minuscolo segue l'attenzione della regressione upstream alla capitalizzazione dei nomi degli header. Il caso di rimozione personalizzata verifica che la regola rispetti il set configurato, oltre ai soli tre nomi predefiniti.
L'advisory attribuisce a christos-cantina-security il ruolo di reporter, a illia-v quello di coordinatore e a sethmlarson quello di revisore della remediation. Il contributo di Sergio Rodriguez in questo caso è l'harness offline indipendente e l'analisi before/after. Questa è una riproduzione della loro CVE pubblicata.
Usa Python 3.10 o successivo. Non è necessario alcun pip install o ambiente virtuale: ogni versione viene importata direttamente dal suo wheel pure-Python in un nuovo sottoprocesso isolato.
Dalla radice del repository del portfolio:
python -B ./labs/cve-replay/run_replay.py --fetch
python -B ./labs/cve-replay/run_replay.py
Il primo comando scarica i due wheel esatti nella directory .cache/wheels/ ignorata dal lab e verifica i loro hash SHA-256 rispetto al manifest. Il secondo comando utilizza quella cache senza scaricare. Per un checkout del codice sorgente autonomo, eseguire python -B run_replay.py --fetch, poi lo stesso comando senza --fetch. --cache accetta una diversa directory di cache locale.
HTTPConnectionPool._make_request viene sostituito con un trasporto a due risposte: un 302 con una location fissa, poi un 200. Il fixture cattura gli argomenti che raggiungono quel confine. Il parsing di urllib3, la policy di retry, il filtraggio degli header e la gestione ricorsiva dei redirect vengono eseguiti invariati dal wheel selezionato.
Tutte le destinazioni sono nomi riservati fissi .invalid; tutti i valori degli header iniziano con DUMMY. La costruzione dei socket e le funzioni DNS sollevano immediatamente un'eccezione. La sonda di capacità IPv6 all'import della libreria viene negata e registrata separatamente; gli scenari di replay non tentano alcuna operazione di rete. Non c'è alcun server in ascolto né target live.
Questo valida la gestione degli argomenti dei redirect. Non misura il traffico proxy end-to-end. La versione 2.7.0 è la prima correzione per questa specifica CVE; questo confronto storico non è una raccomandazione a sceglierla rispetto a release più recenti supportate.