Il problema è che verrà invocato un gestore di eccezioni per gestire la divisione per zero. In generale, gli aggressori sanno che i gestori di eccezioni non sono ben testati come i normali flussi di codice. Il flusso logico principale potrebbe essere valido e accuratamente testato, ma un gestore di eccezioni può essere attivato da interruzioni che si verificano in qualsiasi punto del codice all'interno del suo ambito.

  int myFunction (int a, int b, SomeState state) {state (UNINITIALIZED); prova {state.something (a / b); stato (NORMALE); } catch () {state.something (b / a); stato (INVERTED); } return retval;}  

Questo orribile pseudocodice illustra un modo in cui il difetto potrebbe essere sfruttato. Diciamo che uno stato non inizializzato è in qualche modo vulnerabile. Se viene chiamata questa routine, lo stato viene prima non inizializzato. Se b è zero, cattura l'eccezione e cerca di eseguire un'altra logica. Ma se sia a che b sono zero, viene lanciato di nuovo, lasciando lo stato non inizializzato.

La divisione per zero in sé non era la vulnerabilità, è il cattivo codice attorno ad essa che è possibile sfruttare.

Per aggiungere un altro artificioso ma basato su un esempio reale:

Molte (molte) lune fa, il mio liceo gestiva Novell Netware e lo aveva configurato in modo che gli studenti non potessero eseguire direttamente un prompt dos ( che era fastidioso se, ad esempio, era necessario formattare un floppy disk). Tuttavia, è stato scoperto che se si immette una password più di X caratteri (cioè si tiene semplicemente premuto un tasto per un po '), si verifica un crash di netware e il sistema torna a ... un prompt dos. Molto probabilmente si trattava di un sovraccarico del buffer, ma il principio è lo stesso: se hai a che fare con un sistema (specialmente uno incorporato) che gestisce almeno alcuni arresti anomali imprevisti facendoti entrare in una modalità di manutenzione, allora c'è un problema di sicurezza .

Come suggeriscono le altre risposte, dipende interamente dall'intero sistema. Questo non è solo il codice, ma anche la piattaforma, il linguaggio e il compilatore.

Ad esempio in c ++, la divisione per zero su numeri interi è un comportamento indefinito. Una delle regole su quel particolare linguaggio è che il compilatore può presumere che un comportamento indefinito non si verificherà mai, ed è autorizzato a fare qualsiasi cosa se lo fa.

Qualsiasi cosa include crash con un messaggio di errore e pulizia, crash senza un messaggio di errore e lasciare tutto in uno stato strano, o il più terrificante tentativo di andare avanti come se nulla fosse successo.

Ora, in pratica, la maggior parte dei buoni compilatori moderni tenta di arrestarsi in modo pulito se viene colpito qualcosa del genere, ma questo dovrebbe rendere chiaro il motivo per cui si presume che sia una vulnerabilità. Se crei il tuo codice con un compilatore diverso o impostazioni diverse e non modifichi nemmeno il codice, ciò che il programma fa potrebbe passare da un arresto anomalo alla cancellazione del database.

Insieme a un server web configurato in modo errato, un ambiente PHP potrebbe rivelare il percorso fisico dello script quando viene causata una divisione per zero (perdita del percorso interno):

  <? php $ denominator = $ _GET ['number']; echo 1 / $ denominator;  

Accedendo a script.php? Number = 0, potremmo vedere:

Avvertimento : divisione per zero in /var/www/html/script.php alla riga 3.

Anche se a volte dico nei miei seminari e lezioni che tutti i problemi di sicurezza nel software sono essenzialmente bug, il contrario non è automaticamente vero.

Tuttavia, non vorrei parlare dell'exploitability come argomento. Solo perché tu ed io non riusciamo a trovare un modo per sfruttare non significa che qualcuno più furbo un giorno non lo farà. Dovremmo fornire una prova formale che non è sfruttabile. Buona fortuna con le dimostrazioni formali negli attuali linguaggi di programmazione.

Quindi, per rispondere alla tua domanda: una divisione per zero potrebbe essere una vulnerabilità o una parte di essa. In genere porterà a un'eccezione e quindi alla chiusura del software. Questa di per sé potrebbe essere un'informazione importante per un utente malintenzionato (ora sa che alcune variabili erano zero).

È improbabile che la divisione per zero da sola sia una vulnerabilità di sicurezza, ma in un contesto più ampio può essere una parte del problema.

Quindi, per chiudere il ciclo, dovresti sempre trattare seriamente tutti i bug. Se non puoi esserne sicuro (ad esempio, la tua divisione utilizza una variabile che non controlli), devi prenderla e gestirla, sicurezza o meno. "sì, è un bug ma non vedo come potrebbe essere sfruttato" non è una mentalità attenta alla sicurezza.

La divisione per zero non è intrinsecamente una vulnerabilità di sicurezza.

Tuttavia, se puoi causare un arresto anomalo del server delle applicazioni e rimanere offline dividendolo per zero, ciò potrebbe costituire una vulnerabilità ad attacchi di tipo Denial of Service.

Penso che alla fine la tua risposta arriverà al singolo sistema in gioco. Come gestisce il sistema il tentativo di dividere per 0? Se è elegante, le tue opzioni di attacco sono limitate o inesistenti. Se fa qualcosa di strano, probabilmente puoi entrare con qualcosa.

Fondamentalmente, nessun attacco standard può venire fuori da questo - di cui sono a conoscenza comunque - ma i computer possono sempre gestire i bug male, e male la gestione dei bug è la fonte di molte vulnerabilità.

Se un programma riceverà solo dati affidabili e se non dovesse soddisfare alcun requisito comportamentale quando gli vengono forniti dati dannosi, potrebbe essere possibile generare un codice leggermente più efficiente di quanto sarebbe richiesto se ci fossero alcuni comportamenti requisiti che doveva soddisfare per tutti i dati.

Poiché alcune attività implicano solo l'elaborazione di dati affidabili, mentre altre comportano l'elaborazione di dati da fonti inaffidabili, lo standard C consente implementazioni destinate solo alle attività precedenti ottimizzazioni che sarebbero inadeguate in quelle destinate a questi ultimi, e in quelle destinate ad essere adatte a questi ultimi compiti per offrire garanzie che impedirebbero inutilmente ottimizzazioni che potrebbero essere utili durante l'elaborazione del primo.

Sfortunatamente, il Lo Standard non fornisce alcun mezzo attraverso il quale le implementazioni possono indicare quali tipi di garanzie comportamentali offriranno oltre a quelle previste dallo Standard. Quando è stato scritto C89, gli autori si aspettavano che "il mercato" potesse fare un lavoro migliore degli autori dello Standard nel determinare quali tipi di implementazioni dovrebbero supportare quali "estensioni popolari" comportandosi almeno in qualche modo prevedibile nei casi in cui lo Standard imponeva no requisiti, e tale atteggiamento non è cambiato anche se non si adatta più al mercato dei compilatori di oggi.

Dato qualcosa del tipo:

  if (x! = 0) launch_nuclear_missiles (); ... e poi, possibilmente in un'altra funzionez = y / x;  

alcune persone vedrebbero un compilatore che sostituisce "if" con una chiamata incondizionata a launch_nuclear_missiles () come superiore a quello che chiama solo launch_nuclear_missiles se x è diverso da zero, ma tale comportamento sarebbe appropriato solo quando si elaborano attività che non coinvolgeranno mai input non affidabili.

Se si sa che i compilatori che si stanno utilizzando sosterranno il tipo di garanzie comportamentali deboli che i compilatori generici erano soliti offrire come una cosa ovvia e che facilitano la scrittura di programmi che potrebbero incontrare deboli vincoli comportamentali anche se somministrati in modo malizioso- input creati, quindi la divisione per zero potrebbe non porre punti deboli nella sicurezza. Con compilatori che ottimizzano in modo aggressivo che non sono progettati per essere adatti per attività che implicano input inaffidabili, tuttavia, sarà necessario aggiungere una logica di controllo della sicurezza sufficiente per negare qualsiasi vantaggio che tali "ottimizzazioni" avrebbero potuto offrire.

ma esiste un metodo di attacco che utilizza bug di divisione per zero per ottenere qualcosa di diverso da DoS, come ad esempio l'escalation dei privilegi?

Ricerca rapida sul database CVE di MITRE rivelerà che per lo più la divisione per zero causa negazione del servizio, ma un caso particolare CVE-2005-0998 consente qualcos'altro:

Descrizione Il modulo Web_Links per PHP-Nuke 7.6 consente agli aggressori remoti di ottenere informazioni sensibili tramite un parametro show non valido, che innesca una divisione per zero errore PHP che perde il percorso completo del server.

Questo di per sé non consente l'escalation dei privilegi o attacchi specifici, ma in generale le informazioni sensibili possono essere utili per creare altri attacchi. In altre parole, di per sé la divisione per zero potrebbe essere solo un trampolino di lancio.

Capisco da dove vieni su questo. Di per sé è difficile vedere come solo un errore aritmetico possa essere utilizzato per causare qualsiasi cosa che richieda l'immissione di dati (come l'esecuzione di codice).

Tuttavia, a seconda della lingua potrebbe causare problemi di controllo del flusso o selettivamente thread di crash, ecc. Questo è il genere di cose che ti permettono di aggravare altri problemi o, se sei davvero (non) fortunato, porta direttamente a innescare un percorso che causa il doppio di qualcosa di sfruttabile. Ricorda che l'inserimento dei dati e il bug non devono necessariamente essere gli stessi.

Questo è un po 'artificioso, ma supponiamo ad esempio di aver spostato un oggetto già in un elenco collegato aggiungendone una copia a la testina, quindi iterando fino a trovarla e rimuovere la copia.Se lo fai in un thread e per qualche motivo (ad esempio qualcuno inserisce un'istruzione di stampa delle statistiche nel ciclo di iterazione che è sbagliato), è possibile che lascerà l'elenco in cattivo stato con 2 copie dello stesso elemento Quando questo viene ripulito: double free ...

Se puoi controllare il contenuto di questo nuovo elemento e puoi fare in modo che la statistica risulti in una divisione per zero e controllo ancora abbastanza dei contenuti, questo potrebbe essere sfruttabile.

Non probabile, ma possibile.

La domanda potrebbe essere formulata meglio come "Perché Denial of Service è considerata una vulnerabilità di sicurezza?" Quando si esegue Linux su un processore x86, se il processore divide un intero per 0 (o il valore minimo intero con segno diviso per -1, grazie a supercat) il programma riceve un segnale SIGFPE. In Windows è un'operazione illegale. Lo standard C / C ++ lo considera un comportamento indefinito, il che significa che non puoi sapere in modo affidabile cosa accadrà solo guardando il codice.

Normalmente questo, come con molte ma non tutte le vulnerabilità Denial of Service, risulterà in un "incidente". Ecco alcune possibilità di ciò che puoi sfruttare quando un programma ha una terminazione anomala:

• Potrebbe consentire a un altro programma di utilizzare le stesse risorse del primo (come un port) e fingere di essere lo stesso programma .
• L'arresto anomalo può aggirare qualsiasi operazione di pulizia utilizzata dal programma che potrebbe essere sfruttata.
• Se il codice di uscita del programma viene utilizzato in un altro programma che non controlla il segnale stato del PID del processo figlio potrebbe pensare che il programma abbia restituito un codice di errore. Ad esempio, sulla mia macchina Linux, i seguenti 2 programmi impostano entrambi $? (la variabile utilizzata negli script della shell per rappresentare il codice di ritorno del comando precedente) su 136 : int main (int argc, char ** argv) {return 1 / (argc - 1); } e int main () {return 136; }
• L'arresto anomalo può causare cose come i core dump che possono contenere memoria protetta come chiavi di sicurezza, password e la ricetta della Coca-Cola.

Inoltre, a causa delle ottimizzazioni, il compilatore può scegliere di presumere che il divisore non possa mai essere 0 e potenzialmente ottimizzare il codice che potresti non aver considerato. Questo si applica solo ai linguaggi compilati come C e C ++ che hanno un comportamento non definito (o il suo equivalente) per la divisione per zero. Non sono riuscito a produrre codice ottimizzato che lo faccia utilizzando gli esempi in altre risposte in clang o gcc, ma non c'è nulla che impedisca loro o ad altri compilatori di farlo in passato o in futuro.

Ecco un esempio di dove potrebbe fare la differenza.

È artificioso al 100%, ma molte classi di exploit sono identificate da esempi teorici "artificiosi", finché non vengono trovati esempi specifici.

È pseudo-codice.

  prova: ottieni l'utilizzo medio della CPU per utente connesso se questa media è troppo alta, dì alla persona che accede che siamo occupati. ottieni le credenziali di accesso verifica le credenziali di accesso se le credenziali non sono valide, dì loro di andare via limita l'accesso per questa sessione all'accesso corretto per questo utente se c'è un'eccezione: non fare nulla consentire all'utente in  

In in questo caso la CPU media per utente connesso potrebbe essere calcolata come "CPU totale / numero di utenti registrati" - se non ci sono utenti registrati, ottieni "dividi per 0" e salta direttamente al "se ci sono è una clausola di eccezione ". Ciò include la limitazione dell'accesso: la nuova sessione potrebbe avere accesso corrispondente all'ultimo utente che ha effettuato l'accesso o accesso illimitato.

Sebbene questo esempio mostri tutto il codice insieme, spesso il tuo codice principale chiamerà qualcosa, che chiama qualcosa altrimenti, ei due aspetti che interagiscono (in questo caso, la divisione per 0 e il fatto che l'eccezione viene ignorata) possono essere eseguiti in parti del codice che sono molto distanti.

Come molte persone hanno detto, la divisione per zero (di per sé) non è un bug di sicurezza, o addirittura un bug. Per quanto ne so, la maggior parte (forse tutti!) I linguaggi di programmazione hanno informazioni chiaramente documentate su ciò che accade quando si verifica la divisione per zero. Penso che praticamente ogni lingua che ha eccezioni, ha un'eccezione per la divisione per zero (ho visto una calcolatrice meccanica rimanere bloccata in un ciclo infinito).

Ci sono alcune risposte molto specifiche qui. Concordo sul fatto che una divisione (non gestita) per numero zero sia principalmente un problema funzionale, ma ciò non significa che non possa essere sfruttato come problema di sicurezza. In effetti, ci sono così tanti bug che possono essere sfruttati, la classificazione tra "funzionale" e "sicurezza" quando applicata ai bug sembra in qualche modo inutile.

Si ignora una categoria di problemi di sicurezza (DOS) senza alcuna discussione su ciò che consideri fuori ambito qui. Lo scenario più ovvio è che l'attivazione dell'errore causerà l'arresto dell'istanza del programma. Ma ci sono effetti più sottili: se provoca la scrittura di grandi quantità di dati nel filesystem (come un core dump), presenta una via per un secondo tipo di DOS, riempiendo il filesystem.

Jefrey menziona la divulgazione per un'applicazione PHP, ma i messaggi di errore, i log e i core dump forniscono ampi motivi di selezione per le persone che cercano di estrarre informazioni a cui non dovrebbero avere accesso da programmi scritti in qualsiasi lingua.

Se il prematuro l'interruzione del programma porta a una sorta di risposta, quindi un utente malintenzionato ha i mezzi per attivare un programma specifico in un momento di sua scelta: ha un certo controllo su ciò che sta facendo il tuo sistema che può facilitare un attacco / escalation di privilegi.

Anche se il sistema di controllo è manuale, esiste ancora uno stato di transizione per il sistema in cui i comportamenti di sicurezza sono meno ben definiti e in cui sono in fuga risorse come passphrase, password e chiavi private.