Il dereferenziamento di un puntatore nullo in C è un rischio per la sicurezza se il programma non è un daemon, ma un piccolo script è stato lanciato come processo separato per ogni richiesta?

Question

Il dereferenziamento di un puntatore nullo in C è un rischio per la sicurezza se il programma non è un daemon, ma un piccolo script è stato lanciato come processo separato per ogni richiesta?

#1 da (2 voti)
#2 da (2 voti)

4

Il seguente codice fa parte di un programma che viene generato ad ogni richiesta dallo script ruby on rails di nginx:

static void time_t_to_dos_time(time_t user_supplied_time_t, int *dos_date, int *dos_time)
{
    struct tm *t = localtime(&user_supplied_time_t);

    *dos_time = t->tm_sec / 2 + t->tm_min * 32 + t->tm_hour * 2048;
    *dos_date = t->tm_mday + (t->tm_mon + 1) * 32 +
        (t->tm_year + 1900 - 1980) * 512;
}

localtime restituisce 0 se il valore è troppo grande per rientrare in struct tm . Quindi, quando il programma tenta di leggere t->tm_sec , tenterà di leggere l'indirizzo di memoria 0.
In tal caso, il programma aumenta immediatamente SIGSEGV e il server restituisce:

HTTP/1.1 502 Bad Gateway
Content-Length: 13
Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'
Strict-Transport-Security: max-age=31536000
Vary: Authorization,Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-XSS-Protection: 1; mode=block
Date: Tue, 28 Jun 2016 12:59:10 GMT

502: Failure

Mi sembra un semplice bug senza problemi di sicurezza poiché il programma è progettato per funzionare solo su quel sito Web.
Questo sarebbe corretto?

c x86 ubuntu rails

posta user2284570 28.06.2016 - 15:02

fonte

2 risposte

2

Non fare alcun controllo se un dato puntatore è NULL potrebbe non essere affatto sfruttabile, ma non credo che nel tuo caso sia importante che il programma venga eseguito come demone oppure no. La domanda cruciale qui è più se i dati che possono portare a un dereferenziamento di un puntatore nullo sono controllati dall'utente o no.

In ogni caso, potresti voler risolvere questo problema. È mai una buona idea lasciare un bug nel codice che può bloccare un programma dopo averlo identificato e una correzione non è costosa. Le circostanze che ora portano alla conclusione "non sfruttabile" potrebbero eventualmente cambiare o il npd potrebbe altrimenti portare a danni per il tuo server. Quindi, se fossi in te, aggiungerei semplicemente un if (t == NULL) per risolvere il problema.

Btw, se un tale errore porta all'esecuzione del codice, non importa se ciò accade nel daemon o in un sottoprocesso. L'unica cosa che conta è l'utente del sistema operativo. L'esecuzione del codice è sempre negativa, anche se è con un utente con sistema operativo limitato.

risposta data 24.01.2017 - 12:19

fonte

Leggi altre domande sui tag c x86 ubuntu rails

Verifica dell'impronta digitale SSH di un server pubblico Come decifrare i messaggi crittografati sotto? [chiuso]

score 2 · Accepted Answer

Dereferire un puntatore nullo può essere un rischio per la sicurezza su alcune architetture e sistemi operativi, e se si tratta di un demone o di un gestore o se la funzione o il metodo stesso accede al file system non è l'unico fattore determinante nella valutazione del rischio. Non è possibile enumerare facilmente tutti gli exploit di operazioni indeterminate dal solo codice sorgente.

Nel codice fornito, il null si trova nell'RHS (lato destro) dell'assegnazione nel corrispondente AST (albero dei simboli astratti) in tutti e sei i casi. Ciò significa che la sicurezza non può essere violata all'interno della funzione a causa di una null t.

C'è un piccolo rischio, ma coinvolge più del citato dereferenziamento. Implica l'uso successivo dello spazio degli indirizzi indicato dagli ultimi due argomenti. Se i risultati non validi inseriti nel target di quei puntatori potrebbero causare una violazione della sicurezza, è importante testare t prima di dereferenziarlo.