Tutte le minacce alla sicurezza sono innescate da bug del software?

13

La maggior parte delle minacce alla sicurezza di cui ho sentito parlare sono sorte a causa di un bug nel software (ad esempio, tutti gli input non sono controllati correttamente, i sovraccarichi dello stack, ecc.). Quindi, se escludiamo tutti i social hacking, tutte le minacce alla sicurezza sono dovute a bug? In altre parole, se non ci fossero bug, non ci sarebbero minacce alla sicurezza (di nuovo, escludendo le colpe degli umani come rivelare password e simili)? O i sistemi possono essere sfruttati in modi non causati da bug?

security bug hacking

— Gablin
fonte

4

Chiama la possibilità che io possa indovinare una password debole un bug del software? Semmai, è un problema di progettazione, ma probabilmente è anche più fondamentale di così.

— Joachim Sauer il

4

Definiresti un design scadente come un bug?

— StuperUser

1

Per supportare @StuperUser, nel link " security.stackexchange.com/questions/25585/… " non c'è alcun bug nello script di Dave. Ma è un design stupido.

— Manoj R

1

Se escludiamo tutti i motivi per problemi di sicurezza, tranne i bug, quindi sì.

— andho,

Rilevante: homepage.ntlworld.com./jonathan.deboynepollard/FGA/…

— Trevor Powell

25

Un bug è definito come software che non funziona fino alle specifiche. Ora, se le specifiche sono difettose, non è un bug del software. Se un cliente stupido richiede che tutte le password siano codici a tre cifre senza periodo di tolleranza tra le voci errate, non è il software che deve essere biasimato.

Molti sistemi hanno una "modalità di servizio" che può sovrascrivere la sicurezza e, mentre l'accesso ad essa dovrebbe essere sicuro, i codici spesso passano al pubblico.

I progressi della matematica compromettono i vecchi metodi di crittografia. Qualcosa che era sicurezza praticabile 30 anni fa diventa debole al giorno d'oggi.

Esistono vari metodi di furto di dati che vengono spesso trascurati. Una tastiera wireless ha una portata di circa 2 m, a causa di piccole antenne, e il codice inviato non è crittografato. Leggerlo dall'altra parte della strada con una buona antenna è un metodo ben noto.

A volte i compromessi di sicurezza vengono effettuati con la piena consapevolezza delle conseguenze: i sistemi crittografici richiedono tempo di alimentazione e CPU. Le applicazioni di monitoraggio integrate inviano spesso i loro dati in modo chiaramente leggibile al pubblico perché in primo luogo il valore di compromissione dei dati è trascurabile, quindi non è necessario il costo aggiuntivo dell'implementazione della sicurezza.

Tutta la sicurezza si basa sulla fiducia. Non ci vuole ingegneria sociale perché l'amministratore incaricato diventi canaglia e legga la tua posta.

E alla fine, si può considerare l'applicazione della mazza da baseball su un ginocchio una tecnica sociale?

— SF.
fonte

2

"se le specifiche sono difettose, non è il bug" hm questa frase sembra scivolosa. Direi invece "è un bug nelle specifiche" . Quando sono stato un tester ho inviato e verificato con successo correzioni per alcune dozzine di tali bug. E come sviluppatore ho avuto la possibilità di correggere alcuni di questi "bug delle specifiche" segnalati dai tester rispetto ai documenti API che mi era stato assegnato di mantenere ...

— Gnat,

8

@gnat - Tuttavia, un "bug nelle specifiche" non è un bug del software , è un bug di progettazione . A meno che tu non possa progettare come parte del software ovviamente. Tutto dipende da dove si disegna la linea.

— ChrisF

1

@ChrisF: Grazie per aver espresso a parole quello che volevo dire ma non sapevo come. Risposta modificata per chiarire.

— SF.

Non è sempre chiaro che una specifica funzionalità scritta in una specifica sia un errore.

— Doc Brown,

1

@DocBrown: Sì - a volte è richiesta una riduzione della sicurezza come compromesso tra prestazioni e costi ...

— SF.

12

Ci possono essere situazioni in cui anche i bug dell'hardware causano problemi di sicurezza. Basta considerare un chip RAM difettoso che lancia spontaneamente il bit "isAdmin".

Oppure prendere in considerazione un ipotetico bug hardware in cui la protezione della memoria non funziona come previsto e un processo può sovrascrivere la memoria di un altro processo senza attivare un interrupt.

Per il piacere della lettura: sicurezza del computer compromessa da guasti hardware

— user281377
fonte

Quali sono le probabilità per il chip RAM che lancia esattamente isAdmin?

— m3th0dman,

1

Molto piccolo, ovviamente, ma se succede, è un thread di sicurezza non causato da un bug del software.

— user281377

È del tutto possibile la possibilità che un sistema informatico corrompa i bit di autorizzazione su file casuali. Un file che è scrivibile a livello globale e root SUID può essere banalmente modificato per elevare le autorizzazioni dell'utente.

— SF.

@ user281377 Ti rendi conto che la probabilità solo per selezionare esattamente il bit isAdmin da tutti i bit è 1/34359738368 per una macchina con 4 GB di RAM; questo, ignorando la probabilità di un lancio di chip errato.

— m3th0dman,

@ m3th0dman Probabilmente mi fraintendi. Non sto dicendo che questo è un grosso problema di cui tutti devono preoccuparsi. È più come una prova teorica che un problema hardware può creare un thread di sicurezza. Detto questo, è immaginabile che un utente malintenzionato che scopre i bit difettosi su un server possa trovare modi per bloccare il proprio input fino a quando non viene inserito qualcosa di critico in tali posizioni di memoria.

— user281377

6

Molte minacce alla sicurezza derivano dalle funzionalità del software, non dai bug. Molte funzioni software molto utili risultano avere usi nel bene e nel male, a seconda solo dell'intenzione dell'utente.

— ddyer
fonte

La scorciatoia di un uomo è l'exploit di un'altra porta sul retro.

— Daniel Hollinrake,

5

Prendi in considerazione un attacco denial of service distribuito (DDOS). Questo può essere un rischio per la sicurezza, ma non è causato da un bug del software, ma piuttosto da un utente malintenzionato che supera i limiti per cui è stato progettato il sistema. E ogni sistema ha un limite.

Quindi la risposta alla tua domanda è: no, non tutte le minacce alla sicurezza sono innescate da bug del software.

— Pieter B
fonte

È un rischio per la sicurezza ? Può certamente rompere il tuo sito ma può rompere la sicurezza del tuo sito?

— Carson63000,

1

Dipende da quanto è ampia o ristretta la tua definizione di rischio per la sicurezza.

— Pieter B,

4

Ingegneria sociale.

Ciao, sono XX del dipartimento IT. Il tuo computer sta attualmente diffondendo virus ad altri computer dell'ufficio. Ho bisogno del tuo nome utente e password per poterlo rimuovere.

Quando l'hacker ha nome utente / password può installare in sicurezza trojan ecc.

Il social engineering può essere applicato in diversi modi e usarlo per aggirare la sicurezza è uno di questi.

— jgauffin
fonte

4

Un probabile motivo per cui questo non viene più votato è che chi chiede esplicitamente ha escluso il "social hacking".

— Joachim Sauer,

@JoachimSauer Ottimo punto. Non l'ho visto.

— jgauffin,

3

Che ne dici di qualcosa come Firesheep , l'addon di Firefox che ruba i cookie trasmessi su una rete wireless condivisa?

Potresti sostenere che la vulnerabilità a tali attacchi è un bug, ma puoi anche contestare anche questo. Non c'è molto che un sito Web possa fare per evitare che gli utenti vengano compromessi se non semplicemente eseguendo tutte le comunicazioni su HTTPS: puoi dire che è un bug accettare le comunicazioni HTTP sul tuo sito Web?

— Carson63000
fonte

1

Classificherei la decisione di trasferire importanti informazioni private su un supporto non crittografato un errore di progettazione. Se questo dovesse essere considerato un "bug software" è una discussione separata, secondo me.

— Joachim Sauer il

@JoachimSauer, cosa succede se il tuo sito web rifiuta di trasferire qualsiasi informazione su HTTP ed è in realtà un MITM che sta mappando HTTP su HTTPS? Mentre i browser supportano HTTP e i router gli consentono di passare, c'è una vulnerabilità allo sniffing che può essere evitata solo da client estremamente attenti alla sicurezza. Quindi davvero la domanda diventa: è un bug per i browser Web supportare HTTP?

— Peter Taylor,

@PeterTaylor: per questo problema c'è HTTP Strict Transport Security , che sostanzialmente assicura che il browser sappia che il tuo sito deve essere visitato solo tramite una connessione sicura. Inoltre: il richiedente ha esplicitamente escluso il "social hacking" e, a seconda dell'utente, ignorare una linea non protetta potrebbe essere considerato contenuto in tale aspetto.

— Joachim Sauer,

@JoachimSauer Cosa succede se eseguo semplicemente il proxy di tutto il traffico verso il sito di trasporto rigoroso, ma consento le connessioni HTTP ai client?

— Joshua Drake,

@JoachimSauer: Davvero, sono d'accordo con te. Sono le decisioni poco sagge di progettazione architettonica che causano questa vulnerabilità. Non c'è nulla di erroneamente implementato nel codice, che è ciò che definirei un "bug".

— Carson63000,

1

Sì, nella misura in cui un errore nella sicurezza del software è, qualunque sia la causa prossima , un fallimento del software nel soddisfare i suoi requisiti.

Accetto che questa sia solo una tautologia, ma questa è la misura.

A volte la sicurezza non è semplicemente un requisito (definito). E se viene aggiunto all'elenco dei requisiti dopo la violazione della sicurezza, non lo definirei un "bug".

— Joachim Sauer,

Solo perché un requisito non è stato richiesto all'inizio di un progetto, @JoachimSauer, non significa che non sia stato richiesto. L'industria del software ha speso più tempo della mia vita per affrontare questo fatto.