Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Verifier fetches collateral and verifies quotes the policy will always reject

Aperta
  • Qualcosa non va?
#87 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
security

Direzione di ricerca

Inizia in crates/attestation/src/lib.rs da verify_attestation e verify_attestation_sync, quindi leggi MeasurementPolicy e MeasurementRecord in crates/attestation/src/measurements.rs. Traccia come vengono confrontati i tipi di attestation e quando viene eseguito il controllo della policy. Il lavoro è completato quando i tipi non supportati vengono rifiutati prima della verifica DCAP o del recupero del collateral in entrambi i percorsi, senza modificare il comportamento di verifica accettato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Found this while I was reviewing #70 because the no-cache mode is what makes the fetch happen on every message.
It's in the verify path, not the construction API which is why I'm creating this separate issue however.
Have not reviewed it myself, so if Claude hallucinated this feel free to close.

Claude Analysis

The policy check runs after verification, so a peer can make the verifier do
the full DCAP work — including an outbound collateral fetch — for an
attestation type the policy never accepts.

What happens

verify_attestation matches on the attestation type carried by the incoming
message. has_remote_attestation() is consulted only in the
AttestationType::None arm (crates/attestation/src/lib.rs:475). The
AzureTdx and DcapTdx | GcpTdx arms verify unconditionally, and the policy
check happens afterwards at crates/attestation/src/lib.rs:527:

let measurements = match attestation_type {
    AttestationType::None => {
        if self.has_remote_attestation() { ... }   // only checked here
    }
    AttestationType::DcapTdx | AttestationType::GcpTdx => {
        let (measurements, quote) = dcap::verify_dcap_attestation(...).await?;
        ...
    }
};

// Do a measurement / attestation type policy check
self.measurement_policy.check_measurement_with_gcp_cache(...)?;

So both of these do the full work before rejecting:

  • A verifier built with expect_none() that receives a DCAP quote.
  • A policy accepting only AzureTdx that receives a DcapTdx quote.

verify_attestation_sync has the same shape (lib.rs:551 and lib.rs:608).

Impact

Per connection, for a quote the policy can never accept, an unauthenticated
peer gets the verifier to run full DCAP signature verification and — on a
cache miss — an outbound HTTPS fetch to the PCCS endpoint or Intel PCS. The
rejection still happens, so this is wasted work rather than a soundness
problem. It matters most with no in-process cache, where every such message
is a fresh fetch.

Suggested fix

MeasurementRecord already carries the type
(crates/attestation/src/measurements.rs:323), so the policy can answer this
directly:

impl MeasurementPolicy {
    /// Whether any accepted record covers this attestation type
    pub fn accepts_attestation_type(&self, attestation_type: AttestationType) -> bool {
        self.accepted_measurements.iter().any(|r| r.attestation_type == attestation_type)
    }
}

Then reject at the top of both verify functions, before the match:

if !self.measurement_policy.accepts_attestation_type(attestation_type) {
    return Err(AttestationError::AttestationTypeNotAccepted);
}

That also subsumes the existing has_remote_attestation() check in the
None arm, which could then go away.

Lingua principale
Rust
Stelle
6
Fork
3
Merge medio
4g 5h
PR unite (30g)
7

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di flashbots/attested-tls

Tutte le issue di flashbots/attested-tls

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.