Oracle è in acqua calda questa settimana su un post sul blog scritto dal capo della sicurezza, Mary Davidson. Il post, anche se copre una vasta gamma di argomenti, riguarda principalmente la pratica di segnalare possibili vulnerabilità di sicurezza a Oracle. In particolare, perché non dovresti.
"Recentemente, ho visto un ampio aumento dei clienti nel reverse-engineering del nostro codice per tentare di trovare vulnerabilità di sicurezza al suo interno. Questo è il motivo per cui ho scritto molte lettere ai clienti che iniziano con "ciao, howzit, aloha" ma finiscono con "per favore rispetta il tuo accordo di licenza e interrompi il reverse engineering del nostro codice, già".
Davidson spiega che esiste un numero crescente di clienti attenti alla sicurezza che si occupano di software Oracle di reverse engineering alla ricerca di vulnerabilità della sicurezza (o che assumono consulenti per farlo per loro). Davidson accusa questi clienti di violare i loro accordi di licenza, di non prendere banali precauzioni di sicurezza, di cercare di fare il lavoro di Oracle per loro, e di essere in genere cattivi. Se il cliente ha trovato una vera vulnerabilità, mentre Oracle lo risolverà.
"Quasi odio rispondere a questa domanda perché voglio ribadire che i clienti non dovrebbero e non devono decodificare il nostro codice. [...] non forniremo a un cliente la segnalazione di un tale problema (che hanno trovato attraverso il reverse engineering) una patch speciale (una tantum) per il problema. Inoltre, non forniremo credito in nessun avviso che potremmo pubblicare. Non puoi davvero aspettarti che diciamo "grazie per aver rotto il contratto di licenza". "
Questo non è andato bene nella comunità della sicurezza, e il post è stato rapidamente rimosso - anche se non prima di generare un nuovo hashtag Hashtag Activism: #powerful o #pointless? Attivismo hashtag: #powerful o #pointless? #BringBackOurGirls, #ICantBreathe e #BlackLivesMatter hanno visto un'ampia copertura internazionale nell'ultimo anno - ma gli hashtag sono un mezzo efficace di attivismo? Leggi di più .
"Prima controlla l'EULA di Enigma" disse Alan Turing. #oraclefanfic
- Thorsten Sick (@ThorstenSick), 11 agosto 2015
Ma, se non hai familiarità con il mondo della sicurezza, potrebbe non essere ovvio perché il post originale è così fuorviante. Quindi, oggi, parleremo di dove la filosofia di sicurezza di Oracle si allontana dal mainstream e perché è un problema.
Spiegare la polemica
Quindi, cos'è esattamente il reverse engineering, e perché Davidson è così preoccupato? Fondamentalmente, quando Oracle rilascia un pezzo di software, "compila" il proprio codice sorgente interno in file eseguibili e quindi li consegna ai clienti. La compilazione è un processo che traduce il codice leggibile dall'uomo (in linguaggi come i siti Web C ++ 3 per iniziare con l'apprendimento del linguaggio di programmazione C ++ 3 siti Web per iniziare con l'apprendimento della programmazione C ++ L'apprendimento del programma può essere difficile per molti, anche con linguaggi di programmazione relativamente facili Mentre Java è più facile da iniziare (dove abbiamo numerosi articoli qui su MakeUseOf per Java e ... Leggi altro) in un linguaggio binario più denso che può essere inserito direttamente in un processore del computer.
Il codice sorgente di Oracle non è pubblico. Questo ha lo scopo di rendere più difficile per gli altri rubare la loro proprietà intellettuale. Tuttavia, significa anche che è molto difficile per i clienti verificare che il codice sia sicuro. È qui che entra in gioco la "decompilazione". Fondamentalmente, la de-compilazione si traduce nell'altra direzione, convertendo i file eseguibili in un codice leggibile dall'uomo. Questo non fornisce esattamente il codice sorgente originale, ma fornisce codice che funziona allo stesso modo - sebbene sia spesso difficile da leggere, a causa della perdita di commenti e della struttura organizzativa.
Questo è il "reverse-engineering" a cui Davidson si riferisce. Oracle è contrario perché pensa che mette a rischio la loro proprietà intellettuale. Questo è almeno un po 'sciocco, perché usare un accordo di licenza per proibire il furto di IP è un po' come usare uno zerbino severo per prevenire l'invasione domestica. I tipi di persone che tenteranno di clonare i tuoi prodotti non si preoccupano degli accordi di licenza 4 modi per leggere e comprendere un contratto di licenza con l'utente finale (EULA) Più facilmente 4 modi per leggere e comprendere un contratto di licenza con l'utente finale (EULA) Più facilmente EULA, o accordi di licenza per l'utente finale, sono uno dei mali della vita moderna. Questi sono infiniti accordi verbali, di solito scritti in caratteri minuscoli. Queste sono le cose che si scorre ciecamente verso il basso, alla ricerca di quel dannato ... Leggi di più, e spesso non sono in giurisdizioni in cui è possibile far rispettare tali accordi in ogni caso.
L'umanità è condannata ... #oraclefanfic #justoraclethings pic.twitter.com/e6MOZzkkvq
- CyberAnarchist (@ Cyb3rOps), 12 agosto 2015
La politica riguarda solo i clienti legittimi. La situazione è simile a quella del videogioco DRM 6 Luoghi in cui comprare giochi senza DRM [MUO Gaming] 6 luoghi in cui comprare giochi senza DRM [MUO Gaming] Dato che ho deciso di non acquistare giochi da Steam, ho bisogno di trovare altri fonti. Molti di loro sono in realtà peggiori di Steam stesso. Il negozio di Ubisoft è sconcertante e pieno di fastidioso DRM. Electronic Art's ... Read More, ma in qualche modo ancora più inefficace.
Perché i clienti vogliono decompilare questi eseguibili? Si tratta di sicurezza. Avere accesso al codice sorgente consente di scavare attraverso di esso alla ricerca di bug e potenziali problemi. Spesso, questo viene fatto usando un software che esegue una "analisi del codice statico" - una lettura automatica del codice, che identifica bug noti e pratiche software pericolose che tendono a portare a bug. Sebbene esistano strumenti che analizzano direttamente il file eseguibile, la sua decompilazione consente analisi generalmente più profonde. Questo tipo di analisi statica è uno strumento standard per lo scambio di sicurezza e la maggior parte delle aziende attente alla sicurezza utilizza internamente tale software per produrre codice che presenta meno probabilità di contenere bug gravi.
La politica di Oracle su questo tipo di analisi è semplicemente "non farlo". Perché? Lascerò spiegare a Davidson.
"Un cliente non può analizzare il codice per vedere se c'è un controllo che impedisce l'attacco che lo strumento di scansione sta urlando (che è molto probabilmente un falso positivo) [...] Ora, dovrei notare che non accettiamo solo i rapporti di scansione come "la prova che c'è un lì, lì", in parte perché se si sta parlando di analisi statiche o dinamiche, un rapporto di scansione non è la prova di una reale vulnerabilità. [...] Oh, e chiediamo ai clienti / consulenti di distruggere i risultati di tale reverse engineering e di confermare che lo hanno fatto. "
In altre parole, lo strumento che genera un risultato non è la prova di un vero bug e, dal momento che Oracle utilizza internamente questi strumenti, non ha senso che i clienti li eseguano da soli.
Il grosso problema con questo è che questi strumenti di analisi del codice statico non esistono solo per portare bug alla vostra attenzione. Dovrebbero anche servire come bersaglio per la qualità e la sicurezza del codice. Se scarichi il code-database di Oracle in uno strumento di analisi statica standard del settore e sputa centinaia di pagine di problemi, è davvero un brutto segno.
La risposta corretta, quando uno strumento di analisi del codice statico restituisce un problema, non è quello di esaminare il problema e dire "oh, no, questo non causa un errore perché tale e così." La risposta corretta è di entrare e risolvere il problema. Le cose contrassegnate dagli strumenti di analisi del codice statico sono in genere cattive pratiche in generale e la possibilità di determinare se un determinato problema causa effettivamente un errore è fallibile. Per migliaia di problemi, ti mancheranno le cose. È meglio non avere queste cose nella tua base di codice, in primo luogo.
Ecco l'Oculus CTO John Carmack che canta le lodi di questi strumenti dai tempi di iD Software. (Seriamente, leggi l'intero articolo, è roba interessante).
"Abbiamo avuto un periodo in cui uno dei progetti ha accidentalmente disattivato l'opzione di analisi statica per alcuni mesi, e quando l'ho notato e riattivato, ci sono state pile di nuovi errori che erano stati introdotti nel frattempo. [...] Queste erano dimostrazioni che le normali operazioni di sviluppo producevano continuamente queste classi di errori e [l'analisi statica del codice] ci stava effettivamente proteggendo da molti di loro. "
In breve, è probabile che molti clienti di Oracle non cercassero necessariamente di segnalare bug specifici: stavano chiedendo perché le pratiche di codifica di Oracle erano così povere che la loro base di codice era piena di migliaia e migliaia di problemi così basilari da poter essere individuati da un software automatizzato.
Sono ancora triste che Sun se ne sia andato. E chi era il genio che li ha venduti a Oracle? È come lasciare che Darth Vader faccia da babysitter ai tuoi figli.
- Brad Neuberg (@bradneuberg), 15 agosto 2015
Sicurezza con adesivi
Quindi, che cosa dovrebbero fare i clienti interessati alla sicurezza, invece di usare gli strumenti di analisi statica? Per fortuna, il post sul blog di Davidson era estremamente dettagliato su quell'argomento. Oltre a sostenere le pratiche generali di sicurezza di base, fornisce suggerimenti concreti a coloro che sono preoccupati per la sicurezza del software che usano.
"[T] qui ci sono un sacco di cose che un cliente può fare, ciao, in realtà parlare con i fornitori dei loro programmi di assicurazione o controllo delle certificazioni per prodotti per i quali ci sono buoni sigilli di casa (o sigilli di" codice buono "come Common Criteria) certificazioni o certificazioni FIPS-140. La maggior parte dei venditori - almeno la maggior parte di quelli di grandi dimensioni che conosco - hanno programmi di assicurazione abbastanza robusti ora (lo sappiamo perché confrontiamo tutti gli appunti alle conferenze). "
Questa è una risposta terrificante da un'organizzazione grande come Oracle. La sicurezza informatica è un campo in rapida evoluzione. Nuove vulnerabilità si trovano continuamente e la formalizzazione dei requisiti di sicurezza in una certificazione che viene aggiornata ogni pochi anni è assurda. La sicurezza non è un adesivo. Se credi che un pezzo di software cruciale sia sicuro sulla base di un sigillo sulla confezione, sei irresponsabilmente stupido.
Diamine, gli strumenti di analisi statica vengono aggiornati molto più frequentemente di quanto facciano queste certificazioni - in alcuni casi, ogni giorno - ed eliminando tutti i problemi che si presentano ancora non è abbastanza per avere molta fiducia nella sicurezza del codice, perché anche la maggior parte delle vulnerabilità complesso da rilevare con questo tipo di strumenti automatici.
L'unico modo per avere fiducia nella tua sicurezza è esporre il tuo codice al mondo e chiedere agli hacker di cercare di infrangerlo. Questo è il modo in cui operano le principali società di software: se trovi un problema con il loro codice, non ti insidieranno accondiscendente per aver violato il tuo accordo di utilizzo. Ti pagheranno soldi. Vogliono che le persone facciano del loro meglio per rompere il loro software tutto il tempo. È l'unico modo in cui possono avere la certezza che il loro codice sia assolutamente sicuro.
Questi programmi sono chiamati programmi "bug bounty" e sono la cosa migliore che accada alla sicurezza a livello aziendale da molto tempo. Sono anche, casualmente, qualcosa su cui Davidson ha opinioni piuttosto forti.
"Bug bounties sono la nuova boy band (piacevolmente allitterativa, no?) Molte aziende stanno urlando, svenendo e lanciando biancheria intima ai ricercatori [...] della sicurezza per trovare problemi nel loro codice e insistendo sul fatto che This Is The Way, Walk In It: if non stai facendo bug buges, il tuo codice non è sicuro.
Ah, beh, troviamo l'87% delle vulnerabilità di sicurezza noi stessi, i ricercatori di sicurezza scoprono circa il 3% e il resto viene rilevato dai clienti. [...] Non sto dissingando bug taglie, solo notando che su una base strettamente economica, perché dovrei buttare un sacco di soldi al 3% del problema. "
Per i principianti, in base ai risultati di tali analisi del codice statico, potrebbe essere molto più del 3% se li hai pagati. Ma sto divagando. Il vero punto è questo: bug bounties non fanno per te, sono per noi. Riesci a trovare gli errori in modo più efficiente se spendi gli stessi soldi per gli esperti di sicurezza interni? Beh, probabilmente no - ma gettiamo un ossatura a Oracle e pensiamo che potrebbero. Tuttavia, potrebbero anche prendere i soldi, incassarli e quindi non fare assolutamente nulla. Se la sicurezza risultante è sub-par, i clienti lo scopriranno solo da anni, quando i loro numeri di previdenza sociale finiranno misteriosamente nel Web profondo. Come trovare i siti di cipolle attive e perché potresti desiderare come trovare i siti di cipolle attive e Perché desideri i siti di Cipolla, così chiamati perché terminano con ".onion", sono ospitati come servizi nascosti Tor - un modo completamente anonimo di ospitare siti web. Leggi di più .
"Non c'è vulnerabilità, lo afferma l'EULA." #oraclefanfic pic.twitter.com/cUfafDCWbv
- Schuyler St. Leger (@DocProfSky), 11 agosto 2015
I bounty esistono per metà perché sono un modo veramente efficace di identificare i bug e metà perché sono una forma di sicurezza che non si può falsificare. Un bug bounty dice in modo credibile al mondo che qualsiasi errore lasciato nel codice è più costoso da trovare rispetto alla taglia dichiarata.
I doni dei bug non esistono per tua comodità, Oracle, esistono perché non ci fidiamo di te.
Né dovremmo! Un sacco di grandi aziende consentono alla sicurezza di cadere nel dimenticatoio, poiché i numerosi megabreaches Target confermano fino a 40 milioni di clienti USA Le carte di credito potenzialmente hackerate target confermano fino a 40 milioni di clienti USA Carte di credito potenzialmente hackerate Target ha appena confermato che un hack potrebbe aver compromesso le informazioni sulla carta di credito per un massimo di 40 milioni di clienti che hanno fatto acquisti nei propri negozi negli Stati Uniti tra il 27 novembre e il 15 dicembre 2013. Leggi di più mostra tutto in modo chiaro. Sei il secondo produttore di software al mondo. È assurdo chiederci di dire che i tuoi prodotti sono al sicuro.
Ciò che Davidson ottiene giusto
In tutta onestà a Davidson, ci sono elementi di questo che sono ragionevoli nel contesto. Probabilmente, molti dei loro clienti si imbarcano in verifiche ambiziose sul codice Oracle, senza perdere tempo a eliminare i più banali problemi di sicurezza dai loro sistemi.
"Advanced Persistent Threats" - le organizzazioni di hacker esperti che cercano di ottenere accesso a organizzazioni specifiche per rubare dati - sono certamente spaventosi, ma in base ai numeri sono molto meno pericolosi dei milioni di hacker opportunisti dilettanti con strumenti automatici. Fare questo tipo di analisi statiche del software commerciale quando non si adottano misure di sicurezza di base è molto simile all'installazione di una stanza antipanico quando non si dispone ancora di un lucchetto sulla porta d'ingresso.
Allo stesso modo, probabilmente è frustrante e inutile presentare la stessa analisi automatica ancora e ancora e ancora.
Tuttavia, nel suo insieme, l'articolo rivela alcune idee seriamente obsolete sulla sicurezza del sistema e sulla relazione tra sviluppatori e clienti. Apprezzo il fatto che il lavoro di Davidson sia frustrante, ma gli utenti che si fanno in quattro per verificare la sicurezza del software che usano non sono il problema. Ecco il presidente di Security Awareness, Ira Winkler ha preso su di esso:
"Oracle è un'azienda molto grande e ricca, con prodotti ampiamente distribuiti e utilizzati per applicazioni critiche. Periodo. Hanno la responsabilità di rendere il loro software il più forte possibile [...] Potrebbero esserci molti falsi positivi e costi associati, ma questo è un fattore [della loro vendita] di un sacco di software che ha molti utenti. È un costo di fare affari. Sono sicuro che tutte le società di software hanno le stesse segnalazioni false positive. Non sento Microsoft et al. lamentarsi."
Se Oracle non vuole continuare a ricevere migliaia di problemi trovati dagli strumenti di sicurezza statici, forse dovrebbero risolvere quei mille problemi. Se sono infastiditi dalle persone che girano ripetutamente negli stessi non-bug, forse dovrebbero avere un vero programma di bug bug che ha meccanismi per trattare ripetizioni di non-problemi. I clienti di Oracle chiedono a gran voce uno standard di sicurezza più elevato e la loro vergogna non è la risposta giusta.
Anche se Oracle ha rimosso e in generale disconosciuto il post, che è stato scritto rivela una cultura della sicurezza profondamente sbagliata all'interno di Oracle. L'approccio di Oracle alla sicurezza dà priorità alla protezione della propria proprietà intellettuale per la sicurezza e la tranquillità dei propri clienti - e se affidate a Oracle il software con informazioni critiche, ciò dovrebbe spaventare il bejeezus da voi.
Cosa ne pensi? Sei preoccupato per la filosofia di sicurezza di Oracle? Pensi che Davidson sia trattato troppo duramente? Fateci sapere nei commenti!