PHP bin2hex vulnerabile all'attacco temporale?

Question

PHP bin2hex vulnerabile all'attacco temporale?

#1 da (7 voti)

7

Ho letto in alcuni punti [1] [2] [3] del desiderio di rendere costante il tempo di bin2hex di PHP.

In quali scenari sarebbe bin2hex vulnerabile a un attacco di temporizzazione?

Questo codice sotto è in grado di gestire un token CSRF vulnerabile a un attacco di temporizzazione?

// generate a CSRF token, n is some large number
$token = bin2hex(openssl_random_pseudo_bytes(n));
// ... store $token on in the PHP session and render form with CSRF token
// ... on form submission compare the form's CSRF token to the session token
hash_equals($sessionToken, $formToken);

php csrf timing-attack

posta Rob Olmos 19.06.2015 - 07:19

fonte

1 risposta

Leggi altre domande sui tag php csrf timing-attack

Un nodo di uscita Tor malevolo può eseguire un attacco man-in-the-middle HTTPS per vedere / modificare il traffico HTTPS? Archiviazione di "segreti", keystore, HSM e il resto

score 7 · Answer 1

In quali scenari sarebbe bin2hex vulnerabile a un attacco di temporizzazione?

L'attacco temporale discusso nella mailing list e nel post sul blog è un attacco temporizzato con cache, che è stato notoriamente dimostrato da Daniel J. Bernstein contro l'implementazione di OpenSSL di AES qui (PDF).

Affinché bin2hex() sia vulnerabile a un attacco di temporizzazione, devono essere soddisfatte le seguenti condizioni:

Internamente, può essere indicizzato o ramificato in base al segreto che stiamo cercando di proteggere (ad esempio, la chiave HMAC). L'implementazione di PHP è basata sull'indice PHP basato su quello che potenzialmente potrebbe essere un segreto .
L'attaccante deve essere in grado di alterare lo stato della cache del processore in qualche modo. (ad es. Noleggio di una VM vicina sullo stesso computer bare metal con il provider cloud ed esecuzione di una strategia simile a FLUSH + RELOAD .)
L'attaccante può rapidamente rilasciare molte richieste valide da una posizione di rete privilegiata con un jitter di rete minimo (sorprendentemente banale oggigiorno).
La chiave che vogliamo proteggere viene riutilizzata. (Caso generale: alcuni token CSRF non vengono riutilizzati.)

La fattibilità di un tale attacco è ancora sconosciuta, ma patching questo potenziale canale laterale non è in realtà così difficile. I metodi precedentemente collegati derivavano da implementazione bin2hex di libsodium , fornito da CodesInChaos .

Questo codice è sotto per la gestione di un token CSRF vulnerabile a un attacco di temporizzazione?

Non lo so. Il bin2hex() potrebbe essere una preoccupazione molto minore, ma non quella che posso dimostrare per un exploit pratico. Forse qualcuno in Crypto Stack Exchange può?

Aggiornamento: c'è una versione per questo

Se usi paragonie / constant_time_encoding (che non esisteva quando hai posto questa domanda), non dovresti perdere nessuna informazioni tramite il timing della cache.

<?php
use \ParagonIE\ConstantTime\Hex;

$rawBinary = random_bytes(32);
$data = Hex::encode($rawBinary);
$decoded = Hex::decode($data);

Questa libreria copre tutti gli schemi di codifica RFC 4648:

Hex
Base32
Base32Hex
Base64
Base64UrlSafe
Base64DotSlash
Base64DotSlashOrdered

Gli ultimi due sono compatibili con crypt(3) .