LibreSSL 2.0.5 - Perché non è stato completamente influenzato da secadv_20140806.txt?

3

Da: link

L'annuncio:

We have released LibreSSL 2.0.5, which should be arriving in the
LibreSSL directory of an OpenBSD mirror near you.

This version forward-ports security fixes from OpenSSL 1.0.1i,
including fixes for the following CVEs:

CVE-2014-3506
CVE-2014-3507
CVE-2014-3508 (partially vulnerable)
CVE-2014-3509
CVE-2014-3510
CVE-2014-3511

LibreSSL 2.0.4 was not found vulnerable to the following CVEs:

CVE-2014-5139
CVE-2014-3512
CVE-2014-3505

We welcome feedback and support from the community as we
continue to work on LibreSSL.

Thank you,
 Brent

La nostra domanda è: Perché LibreSSL non è stato interessato dal CVE-2014-5139, CVE-2014-3512, CVE-2014-3505 e solo parzialmente vulnerabile per: CVE-2014-3508 ? Qualcuno può spiegare in breve?

Il link per la sicurezza di OpenSSL: link

    
posta evachristine 16.08.2014 - 11:45
fonte

1 risposta

4
  • CVE-2014-5139 - crash con SRP ciphersuite nel messaggio Server Hello - SRP era stato rimosso da LibreSSL a maggio 2014, quindi non è stata necessaria alcuna correzione.

  • CVE-2014-3512 - SRP buffer overrun - di nuovo non vulnerabile perché SRP non fa più parte di LibreSSL

  • CVE-2014-3505 - Double Free durante l'elaborazione di pacchetti DTLS - questo era stato risolto indipendentemente da LibreSSL a maggio 2014.

  • CVE-2014-3508 - openssl : perdita di informazioni in graziose funzioni di stampa - LibreSSL ha effettivamente fornito un correzione per questo. Non ho informazioni sul motivo per cui l'annuncio di rilascio di LibreSSL 2.0.5 lo abbia contrassegnato come "parzialmente vulnerabile", qualcuno con conoscenza su tale argomento potrebbe confrontare la correzione di LibreSSL con fix OpenSSL per scoprirlo. Aggiornamento: durante la ricerca di una spiegazione più dettagliata al riguardo, mi sono imbattuto in questo thread , dove qualcuno ha praticamente chiesto le stesse domande e uno degli sviluppatori di OpenBSD ha spiegato per CVE-2014-3508:

    For -3508, one of the involved paths had been converted to snprintf() and could no longer leave the buffer unterminated, but we hadn't changed the other. Darn.

Nota: Ho collegato i CVE al Bugzilla di Redhat, perché si collegano sempre al commitdiff effettivo che risolve il problema, il che è bello.

    
risposta data 17.08.2014 - 03:47
fonte

Leggi altre domande sui tag