Skip to content

fix(config): restringir a http(s) o download da cadeia via AIA - #3

Open
marvinrez wants to merge 1 commit into
danielcarletti:mainfrom
marvinrez:fix/aia-scheme-allowlist
Open

fix(config): restringir a http(s) o download da cadeia via AIA#3
marvinrez wants to merge 1 commit into
danielcarletti:mainfrom
marvinrez:fix/aia-scheme-allowlist

Conversation

@marvinrez

Copy link
Copy Markdown

Quando certificate.chain_path nao e informado, o emissor le a extensao Authority Information Access do .pfx e baixa cada URL de CA_ISSUERS com urlopen(). O opener padrao do urllib entende file:// e ftp://, e a URL vem do proprio arquivo de certificado - entrada do usuario, nao do runtime.

Na pratica, um .pfx com AIA apontando para file:///etc/passwd fazia o emissor ler o arquivo local, e um AIA apontando para um host interno fazia a requisicao sair. Nao havia validacao de esquema, validacao de host, nem teto no resp.read(). O comentario "# nosec B310 - trusted CA endpoints from cert" silenciava exatamente o alerta que apontaria isso, sobre uma premissa que nao se sustenta: o certificado e um arquivo que o operador trata como dado.

A busca agora usa um OpenerDirector montado so com HTTPHandler e HTTPSHandler, sem FileHandler e sem FTPHandler - um esquema fora de http(s) falha por ausencia de handler, nao por depender de uma checagem que alguem possa remover depois. Alem disso: o esquema e validado antes da chamada, redirecionamento para fora de http(s) nao e seguido, e a resposta tem teto de 1 MiB.

Cadeias servidas por http(s), que e o caso real das ACs da ICP-Brasil, continuam funcionando sem mudanca.

Cinco testes cobrem file://, ftp://, redirecionamento 302 para file://, resposta acima do teto, e o caminho feliz com um certificado DER servido por HTTP.

Quando certificate.chain_path nao e informado, o emissor le a extensao
Authority Information Access do .pfx e baixa cada URL de CA_ISSUERS com
urlopen(). O opener padrao do urllib entende file:// e ftp://, e a URL vem do
proprio arquivo de certificado - entrada do usuario, nao do runtime.

Na pratica, um .pfx com AIA apontando para file:///etc/passwd fazia o emissor
ler o arquivo local, e um AIA apontando para um host interno fazia a
requisicao sair. Nao havia validacao de esquema, validacao de host, nem teto
no resp.read(). O comentario "# nosec B310 - trusted CA endpoints from cert"
silenciava exatamente o alerta que apontaria isso, sobre uma premissa que nao
se sustenta: o certificado e um arquivo que o operador trata como dado.

A busca agora usa um OpenerDirector montado so com HTTPHandler e HTTPSHandler,
sem FileHandler e sem FTPHandler - um esquema fora de http(s) falha por
ausencia de handler, nao por depender de uma checagem que alguem possa remover
depois. Alem disso: o esquema e validado antes da chamada, redirecionamento
para fora de http(s) nao e seguido, e a resposta tem teto de 1 MiB.

Cadeias servidas por http(s), que e o caso real das ACs da ICP-Brasil,
continuam funcionando sem mudanca.

Cinco testes cobrem file://, ftp://, redirecionamento 302 para file://,
resposta acima do teto, e o caminho feliz com um certificado DER servido por
HTTP.

Co-Authored-By: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants