Al ping, perché dobbiamo fare la copia dell'array invece di passare l'array sorgente che il client ci ha inviato?

Question

Al ping, perché dobbiamo fare la copia dell'array invece di passare l'array sorgente che il client ci ha inviato?

#1 da (5 voti)

5

Quindi sono stato googlato su questa cosa a cuore aperto di OpenSSL e in qualche modo vedo che è causato dall'estensione del battito cardiaco che richiede al client di eseguire il ping del server per mostrare la sua vitalità e tutto viene a questa funzione memcpy in C che si intende per copiare dalla matrice di origine alla matrice di destinazione con la dimensione specificata dall'utente.

Se la dimensione era una bugia (il che significa che la fonte contiene un byte minore rispetto alla dimensione) allora memcpy catturerà la memoria arbitraria intorno e assegnata alla destinazione e in questo caso rimanderà al client ...

Riferimento: Anatomia dell'Heartbleed di OpenSSL: solo quattro byte attivano l'horror bug

payload is controlled by the attacker, and it's quite large at 64KB. If the actual HeartbeatMessage sent by the attacker only has a payload of, say, one byte, and its payload_length is a lie, then the above memcpy() will read beyond the end of the received HeartbeatMessage and start reading from the victim process's memory...

Se la mia comprensione di cui sopra è corretta, allora ho una domanda qui forse ingenua, perché dobbiamo fare array (char array qui) copiando qui? Non possiamo semplicemente passare il char array sorgente che il client ci ha inviato?

vale a dire. Se mi mandi

function(char[] array)

Quindi dovrei semplicemente rimandare quella stessa matrice

send(array)

c array memory ssl

posta vcharlie 21.04.2014 - 10:32

fonte

1 risposta

Leggi altre domande sui tag c array memory ssl

Che tipo di eccezione per chiedere argomenti fuori intervallo? Shoud I restituisce direttamente un messaggio di stringa o piuttosto una chiave i18n quando si tratta di API JSON?

score 5 · Answer 1

È a causa del modo in cui lo stack di rete funziona nel sistema operativo e nelle librerie standard. Un pacchetto ethernet è un flusso continuo di bit che escono dal tuo computer. Puoi avere tra i pacchetti , ma non entro . Per una connessione a 1 Gbps, significa che ogni miliardesimo di secondo devi essere pronto per trasmettere il bit successivo.

Per consentire al software che non è in tempo reale di soddisfare quei requisiti di temporizzazione rigorosi, lo stack di rete crea un buffer. Il tuo software server non in tempo reale riempie il buffer e il driver e l'hardware lo invia in tempo reale.

Poiché sono necessari intestazioni e altri campi diversi attorno alla risposta (ad esempio, gli indirizzi di origine e destinazione sono invertiti) e tale informazione deve essere contigua con il carico utile echo nel buffer di trasmissione, che richiede una copia del carico utile nel tampone.

Sì, è possibile evitare la copia ridisegnando lo stack di rete per utilizzare un diverso tipo di struttura dati per il buffer di trasmissione, come un elenco di puntatori agli array. Tuttavia, questo avrebbe il proprio insieme di complessità, problemi di sicurezza e inefficienze.

Personalmente, sono sorpreso che le app sensibili alla sicurezza consentano ancora l'uso di una% grezza dimemcpy. Devono comunque eseguire i controlli, quindi perché non creare un tipo di buffer sicuro e risolvere il problema una sola volta, invece di dover continuamente tenere d'occhio questi overflow tramite la revisione del codice?