Aggiunta di un buffer da 65K per proteggere da overflow del buffer?

No. Molto probabilmente, hai il limite di 64k dal bug Heartbleed , hovewer è puramente perché in HTTPS Heartbeats il campo di lunghezza era 16 pezzi lunghi. Ciò non significa che nel tuo caso il tuo software non avrà un overflow del buffer che va molto oltre. Quindi, anche se sì, questo potrebbe aggiungere un po 'di sicurezza, devi sempre presumere che gli overflow del buffer possano influenzare l'intero spazio degli indirizzi, sia dopo il buffer che anche prima.

Il miglior consiglio per evitare i bug di overflow del buffer in C è di non usare C in primo luogo. La filosofia progettuale della lingua era che ogni volta che dovevano scegliere tra efficienza e sicurezza, sceglievano l'efficienza. Il risultato è un linguaggio che può essere usato per scrivere programmi molto veloci e che conservano la memoria, ma purtroppo a scapito della sicurezza. Ciò significa che è rischioso utilizzarlo in qualsiasi contesto in cui la sicurezza sia pertinente, e nel mondo in rete di oggi praticamente ovunque.

Il secondo miglior consiglio è di non usare funzioni che scrivono ai buffer ma non hanno argomenti di lunghezza massima, come il seguente:

• ottiene
• scanf
• sprintf
• strcat
• strcpy

Molti di questi hanno versioni alternative con n nel nome che hanno un parametro aggiuntivo per la lunghezza massima. Usali e assicurati che questo parametro non sia mai superiore alla lunghezza del buffer delle stringhe che passi. Ma tieni presente che puoi ancora creare una vulnerabilità di buffer overflow passando accidentalmente una lunghezza che è inferiore al buffer di destinazione.

Uno degli approcci di sicurezza noti è quello di mettere un "canarino" sullo stack che verrebbe danneggiato (modificato) dall'overflow del buffer, se dovesse verificarsi. Non è necessario che sia così grande, e deve essere inizializzato con alcuni valori che il programma di attacco è improbabile sapere.

Dopo aver eseguito un IO, puoi controllare se il contenuto di questo buffer non è stato toccato dall'overflow del buffer.

Tuttavia questa protezione funziona solo se si è certi che si otterrà il controllo di esecuzione dopo l'overflow. Se il superamento danneggia l'indirizzo di ritorno utilizzato dalla funzione IO, è possibile che non si abbia la possibilità di eseguire il canary check.

Tuttavia, con lo stack in ribasso tipico in cui l'indirizzo di ritorno è l'ultima voce con un indirizzo più piccolo e il buffer supera il limite (quindi lontano dall'indirizzo di ritorno), il canary dovrebbe funzionare:

  (higher address values)
  other stack data
  canary
  buffer that overruns up
  return address from the IO routine
  (lower address values)

Dovresti poter tornare, controllare il canarino e, se è morto, terminare il programma nel modo più veloce possibile.

Alcuni buffer-counter sono 16 bit, il che significa che il 65k dovrebbe proteggere; tuttavia la maggior parte delle volte non è il caso e 65k è un lotto di stack space da sprecare.

In generale, un'idea mal concepita.