Interpretazione dei rating CVE: Buffer Overflow vs. Denial of Service vs. Remote Code Executing (RCE)

1

Se un CVE elenca una vulnerabilità di overflow del buffer, ma non un'esecuzione di codice in modalità remota, dovrei interpretarlo come:

  1. Questa vulnerabilità non è stata confermata per esporre RCE, o
  2. Questa vulnerabilità è stata confermata per non esporre RCE, o
  3. Qualcuno (chi?) pensa che probabilmente non esponga RCE.

O qualcos'altro? Questa informazione è generalmente affidabile?

Modifica : la conferma di una vulnerabilità RCE dopo la scoperta iniziale può essere molto difficile e richiedere molto tempo. Immagino che i ricercatori a volte riportino errori di segmentazione senza prima confermare la piena portata dell'esposizione, il che mi ha portato a questa domanda.

    
posta jtpereyda 07.12.2016 - 22:14
fonte

1 risposta

1

Dovresti interpretarlo come tale, un input non fidato è in grado di scrivere nella sezione in memoria che non dovrebbe scrivere perché l'applicazione non riesce a controllarne le dimensioni.

Penso che tu sia nella mentalità di categorizzare sempre RCE come estensione dell'overflow del buffer quando potrebbero essere completamente diversi problemi. Prendete ad esempio RCE a causa di inclusione di file remoti o difetti nelle applicazioni Web che utilizzano eval nei linguaggi di scripting o input non attendibili per eseguire un comando OS. Questi sono RCE ma non necessariamente BOF.

Credo che quello che sto dicendo è che un overflow del buffer può essere trattato come una categoria che descrive cos'è una vulnerabilità e come accade. Potrebbe potenzialmente essere esteso a RCE o DoS, ma l'overflow è perfettamente perfetto per capirlo.

Quando vedi una vulnerabilità di overflow, puoi sempre controllare il codice di exploit associato pubblicamente e leggere ulteriori informazioni su di esso per vedere se c'è DoS o RCE. La maggior parte (se non tutti) i BOF sono già al minimo. Inoltre, è possibile leggere che un overflow porta a RCE, ma non è possibile trovare alcun exploit pubblico. Questo è comune, specialmente nel software che è proprietario. Ciò non significa che non sia confermato, è solo che i ricercatori non sono mai stati rilasciati al pubblico e potrebbero far parte di strumenti di sicurezza proprietari.

    
risposta data 05.01.2017 - 03:53
fonte