praticamente il titolo, come sapere se la vulnerabilità Heartbleed (per OpenSSL) interessa altre librerie come SSLStream o BouncyCastle di .NET.
(Ci scusiamo per l'ignoranza, ma non abbiamo trovato informazioni su come sfruttare, per vedere se è correlato a bufferoverrun e altre cose che non dovrebbero accadere in Java / .NET).
Il cosiddetto exploit "heartbleed" è un overrun del buffer. Un read overrun, per essere specifici: il sistema attaccato è indotto a leggere e rinviare byte da un buffer che è molto più corto della lunghezza di lettura, quindi legge qualunque byte risiede nella RAM oltre il buffer. Poiché i byte vengono inviati al peer, questo dà una finestra per dare un'occhiata alla RAM del sistema di destinazione.
È improbabile che qualsiasi altra implementazione di SSL condivida lo stesso bug esatto. È plausibile che altre librerie SSL abbiano overrun di buffer di qualche tipo (nessuno sa davvero come scrivere codice senza bug), ma non esattamente quello. Oppure, detto altrimenti, se un'altra implementazione SSL ha lo stesso bug relativo al battito cardiaco, allora probabilmente è uno spin-off di OpenSSL.
Inoltre, per le implementazioni scritte in un linguaggio in cui gli accessi agli array vengono controllati sistematicamente per limiti (in genere Java o C # o Python o Scheme o OCaml o semplicemente qualsiasi linguaggio che non sia terribilmente di basso livello come C), le conseguenze di un sovraccarico del buffer sono diverse, e di solito preferibili: invece di leggere i byte extra e rinviarli, il codice offende trap, innescando un'eccezione che implica la chiusura del thread o del processo o della connessione. Il bug è ancora lì, non l'exploit di vasta portata; la perdita di dati segreti si è trasformata in un potenziale denial-of-service di base, che spesso si limita a chiudere la connessione interessata, quindi non negare molto il servizio dopo tutto.
Leggi altre domande sui tag heartbleed