Oracle är i varmt vatten den här veckan över ett blogginlägg skrivet av sin säkerhetschef, Mary Davidson. Inlägget, även om det täcker en rad ämnen, handlar oftast om att rapportera möjliga säkerhetsproblem till Oracle. Specifikt varför ska du inte.
"Nyligen har jag sett en stor ish uptick hos kunder omvänd teknik vår kod för att försöka hitta säkerhetsproblem i den. Det är därför jag har skrivit många brev till kunder som börjar med "hej, hur är det, aloha" men sluta med "var god följa ditt licensavtal och stoppa omvänd teknik redan vår kod."
Davidson förklarar att det finns ett växande antal säkerhetsmedvetna kunder som är omvändstekniska Oracle-programvaran letar efter säkerhetsproblem (eller anlitar konsulter för att göra det för dem). Davidson anklagar dessa kunder för att bryta mot sina licensavtal, att inte vidta allvarliga säkerhetsåtgärder, försöka göra Oracles jobb för dem och att de i allmänhet är Bad People. Om kunden har hittat en verklig sårbarhet, kommer Oracle att fixa det.
"Jag hatar nästan att svara på den här frågan för att jag vill upprepa att kunderna borde inte och måste inte omvandla vår kod. [...] vi kommer inte att ge en kund som rapporterar ett sådant problem (som de hittade genom omvänd teknik) en speciell (enstaka) patch för problemet. Vi kommer inte heller ge kredit i några rådgivning vi kan utfärda. Du kan verkligen inte förvänta oss att säga "tack för att du bryter licensavtalet." "
Det gick inte bra i säkerhetsgemenskapen, och posten togs snabbt ner - men inte för att gyta en ny hashtag Hashtag Activism: #powerful eller #pointless? Hashtag Activism: #powerful eller #pointless? #BringBackOurGirls, #ICantBreathe och #BlackLivesMatter har sett stor internationell täckning under det gångna året - men är hashtags ett effektivt sätt att aktivera? Läs mer .
"Kontrollera Enigmas EULA först", säger Alan Turing. #oraclefanfic
- Thorsten Sick (@ThorstenSick) 11 augusti 2015
Men om du inte känner till säkerhetsvärlden kanske det inte är uppenbart varför det ursprungliga inlägget är så missvisat. Så idag ska vi prata om var Oracles säkerhetsfilosofi avviker från det vanliga, och varför det är ett problem.
Förklara kontroversen
Så, vad är exakt reverse engineering, och varför är Davidson så oroad över det? I grund och botten, när Oracle släpper ut en mjukvara, "kompilerar" de sin interna källkod till körbara filer och levererar sedan dessa filer till kunderna. Kompilering är en process som översätter läsbar kod (på språk som C ++ 3 webbplatser för att komma igång med Learning C ++ Programmeringsspråk 3 webbplatser att komma igång med att lära sig C ++ Programmeringsspråk Att lära sig att programmera kan vara svårt för många, även med relativt enkla programmeringsspråk . Även om Java är lättare att komma igång med (där vi har många artiklar här på MakeUseOf för Java samt ... Läs mer) i ett tätare binärt språk som matas direkt till en datorprocessor.
Oracles källkod är inte offentlig. Detta är avsett att göra det svårare för andra att stjäla sin immateriella äganderätt. Det innebär emellertid också att det är mycket svårt för kunderna att verifiera att koden är säker. Här kommer "dekompilering" till spel. I grunden översätter de-compilation i andra riktningen, konverterar körbara filer tillbaka till läsbar kod. Detta levererar inte exakt den ursprungliga källkoden, men den levererar kod som fungerar på samma sätt - men det är ofta svårt att läsa, tack vare förlusten av kommentarer och organisationsstruktur.
Detta är "reverse engineering" som Davidson hänvisar till. Oracle är emot det för att de tror att det sätter sin intellektuella egendom i fara. Detta är åtminstone lite dumt, för att använda ett licensavtal för att förbjuda IP-stöld är lite som att använda en sternt ordmad dörrmatta för att förhindra heminvasion. De typer av människor som kommer att försöka klona dina produkter bryr sig inte om licensavtal 4 sätt att läsa och förstå en slutanvändarlicensavtal (EULA) lättare 4 sätt att läsa och förstå en slutanvändarlicensavtal (EULA) Lättare EULA, eller slutanvändarlicensavtal, är ett av ont i det moderna livet. Dessa är oändliga ordiga avtal, vanligtvis skrivna i liten utskrift. Det här är de saker du blinda rullar ner och letar efter det där darnet ... Läs mer, och ofta finns inte i jurisdiktioner där du i alla händelser kan genomdriva dessa avtal.
Människan är dömd ... #oraclefanfic #justoraclethings pic.twitter.com/e6MOZzkkvq
- CyberAnarchist (@ Cyb3rOps) 12 augusti 2015
Policyn påverkar verkligen bara legitima kunder. Situationen liknar den för videospel DRM 6 Platser att köpa DRM-spel [MUO Gaming] 6 Platser att köpa DRM-Free Games [MUO Gaming] Eftersom jag har bestämt mig för att inte köpa spel från Steam, behöver jag hitta andra källor. Många av dem är faktiskt värre än Steam själv. Ubisofts butik är baffling och full av irriterande DRM. Elektronisk konst ... Läs mer, men på något sätt ännu mer ineffektiv.
Varför vill kunderna dekompilera dessa körbara? Det handlar om säkerhet. Med tillgång till källkoden kan du gräva igenom den och letar efter fel och potentiella problem. Ofta görs detta med hjälp av programvara som utför en "statisk kodanalys" - en automatiserad genomläsning av koden, som identifierar kända fel och farlig programvara som tenderar att leda till fel. Medan det finns verktyg som analyserar den körbara filen direkt, dekompilerar det i allmänhet djupare analyser. Denna typ av statisk analys är ett standardverktyg för handeln med säkerhet, och de flesta säkerhetsmedvetna företag använder sådan programvara internt för att producera kod som är mindre benägna att innehålla allvarliga buggar.
Oracles politik för denna typ av analys är helt enkelt "inte". Varför? Jag ska låta Davidson förklara.
"En kund kan inte analysera koden för att se om det finns en kontroll som förhindrar den attack som skannverktyget skriker om (vilket sannolikt är en falsk positiv) [...] Nu ska jag notera att vi inte bara accepterar skanna rapporter som "bevis på att det finns en där, där", delvis beroende på om du pratar statisk eller dynamisk analys, är en skanningsrapport inte ett bevis på en verklig sårbarhet. [...] Åh, och vi kräver att kunder / konsulter förstör resultaten av sådan omvänd teknik och bekräftar att de har gjort det. "
Med andra ord, verktyget som visar upp ett resultat är inget bevis på en riktig bugg - och eftersom Oracle använder dessa verktyg internt, är det ingen mening att kunderna kör dem själv.
Det stora problemet med detta är att dessa statiska kodanalysverktyg inte existerar bara för att få buggar till din uppmärksamhet. De ska också tjäna som mål för kodkvalitet och säkerhet. Om du dumpar Oracles kodbas till ett statiskt standardverktyg för industristandard och det spottar ut hundratals sidor av problem, är det ett riktigt dåligt tecken.
Det korrekta svaret, när ett statiskt kodanalysverktyg spetsar tillbaka ett problem, är inte att titta på problemet och säga "åh nej det orsakar inte ett fel eftersom det är sådant." Det rätta svaret är att gå in och lösa problemet. De saker som flaggats med statiska kodanalysverktyg är vanligtvis dåliga rutiner i allmänhet, och din förmåga att bestämma huruvida ett givet problem faktiskt orsakar ett fel är felbart. Över tusentals problem kommer du att sakna saker. Du är bättre att inte ha sådana saker i din kodbas i första hand.
Här är Oculus CTO John Carmack som sjunger berömmarna av dessa verktyg från sin tid på iD Software. (Läs alltså hela uppsatsen, det är intressanta saker).
"Vi hade en period där ett av projekten av misstag fick det statiska analysalternativet avstängt i några månader, och när jag märkte och aktiverade det, fanns det högar nya fel som hade införts under tiden. [...] Det var demonstrationer att de normala utvecklingsoperationerna kontinuerligt producerade dessa klasser av fel och att [statisk kodanalys] effektivt skyddar oss från många av dem. "
Kort sagt är det troligt att många av Oracles kunder inte nödvändigtvis försökte rapportera specifika fel - de frågade varför Oracles kodningspraxis var så dåliga att deras kodbas var riddled med tusentals tusen frågor så grundläggande att de kunde plockas ut av automatiserad programvara.
Jag är fortfarande ledsen att Sun är borta. Och vem var det geni som sålde dem till Oracle? Det är som att låta Darth Vader barna dina barn.
- Brad Neuberg (@bradneuberg) 15 augusti 2015
Säkerhet vid klistermärken
Så vad ska säkerhetsrelaterade kunder göra, istället för att använda statiska analysverktyg? Tack och lov var Davidsons blogginlägg mycket detaljerad om det ämnet. Bortsett från att man förespråkar allmänna grundläggande säkerhetspraxis, lägger hon konkreta förslag till de som är bekymrade över säkerheten för den programvara de använder.
"Det här är många saker en kund kan göra, gosh, faktiskt pratar med leverantörer om deras försäkringsprogram eller kontroller certifieringar för produkter för vilka det finns god housekeeping sälar för (eller" bra kod "sälar) som gemensamma kriterier certifieringar eller FIPS-140 certifieringar. De flesta leverantörer - åtminstone de flesta av de stora som jag vet - har ganska robusta försäkringsprogram nu (vi vet det här eftersom vi alla jämför noter vid konferenser). "
Detta är ett skrämmande svar från en organisation så stor som Oracle. Datorsäkerhet är ett snabbt utvecklande fält. Nya sårbarheter finns hela tiden, och formalisering av säkerhetskrav till en certifiering som uppdateras några år är absurd. Säkerhet är inte en klistermärke. Om du litar på att en del avgörande programvara är säker på grundval av en tätning på förpackningen, är du oansvarigt dum.
Heck, statiska analysverktyg blir uppdaterade mycket oftare än de här certifieringarna gör - i vissa fall dagligen - och att eliminera alla problem de dyker upp är inte tillräckligt för att ha mycket förtroende för säkerheten för din kod, eftersom de flesta sårbarheter också är komplex att detekteras av dessa typer av automatiserade verktyg.
Det enda sättet att ha ett förtroende för din egen säkerhet är att avslöja din kod till världen och be hackare att försöka bryta den. Så här fungerar de flesta stora mjukvaruföretag: Om du hittar ett problem med deras kod, kommer de inte överväldigande att snarka på dig för att bryta mot användningsavtalet. De betalar dig pengar. De vill att folk försöker sitt bästa att bryta sin programvara hela tiden. Det är det enda sättet de kan få förtroende, deras kod är alls säker.
Dessa program kallas "bug bounty" -program, och de är det bästa att hända med säkerhet på företagsnivå under lång tid. De är också, tillfälligt, något som Davidson har ganska starka åsikter om.
"Bug bounties är det nya pojkbandet (trevligt alliterande, nej?) Många företag skriker, besvimlar och kastar underkläder hos säkerhetsforskare [...] för att hitta problem i deras kod och insistera på att detta är vägen, gå in i det: om du gör inte buggar, din kod är inte säker.
Nåväl, vi hittar 87% av säkerhetsproblemen själva, säkerhetsforskare hittar cirka 3% och resten hittas av kunder. [...] Jag slår inte bort buggarier, bara märker det på en strikt ekonomisk grund, varför skulle jag kasta mycket pengar på 3% av problemet. "
Till att börja med, baserat på resultaten från dessa statiska kodanalyser, kan det visa sig att vara mycket mer än 3% om du betalat dem. Men jag avviker. Den verkliga punkten är detta: Bug bounties är inte för dig, de är för oss. Kunde du hitta buggar mer effektivt om du spenderade samma pengar på inrikes säkerhetsexperter? Tja, förmodligen inte - men låt oss kasta Oracle ett ben och anta att de kunde. Men de kunde också ta pengarna, banka det, och sedan göra absolut ingenting. Om den resulterande säkerheten är delpar, kommer kunderna bara att ta reda på det år från och med nu när deras socialförsäkringsnummer dyker upp på djupa webben. Hur man hittar aktiva lökplatser och varför du kanske vill hitta hur man hittar aktiva lökställen & Varför du kanske vill Lökställen, så namngivna eftersom de slutar med ".onion", är värd som Tor dolda tjänster - ett helt anonymt sätt att värd webbplatser. Läs mer .
"Det finns ingen sårbarhet. EULA säger det." #oraclefanfic pic.twitter.com/cUfafDCWbv
- Schuyler St. Leger (@DocProfSky) 11 augusti 2015
Bug bounties finns hälften eftersom de är ett verkligt effektivt sätt att identifiera buggar, och hälften eftersom de är en form av säkerhet du inte kan förfalska. En bug-bounty berättar troget världen att eventuella buggar kvar i koden är dyrare att hitta än den angivna bountyen.
Bug bounties finns inte för din bekvämlighet, Oracle, de finns för att vi inte litar på dig.
Inte heller borde vi! Massor av stora företag tillåter säkerheten att falla vid vägen, eftersom de många megabreachesna målen bekräftar upp till 40 miljoner amerikanska kunder Kreditkort potentiellt hackade mål bekräftar upp till 40 miljoner amerikanska kunder Kreditkort Potentiellt hackat mål har bara bekräftat att ett hack kunde ha äventyrat Kreditkortsinformationen för upp till 40 miljoner kunder som har handlat i sina amerikanska butiker mellan 27 november och 15 december 2013. Läs mer visa alltför tydligt. Du är den näst största programvaruleverantören i världen. Det är absurt att fråga oss att bara ta ditt ord att dina produkter är säkra.
Vad Davidson får rätt
I rättvisa till Davidson finns det delar av detta som är rimliga i sammanhanget. Sannolikt startar många av sina kunder ambitiösa revisioner av Oracles kod utan att ta tid att eliminera mer vardagliga säkerhetsproblem från sina system.
"Advanced Persistent Threats" - skickliga hackerorganisationer som försöker få tillgång till specifika organisationer för att stjäla data - är verkligen läskiga men av siffrorna är de mycket mindre farliga än de miljoner opportunistiska amatörhackarna med automatiserade verktyg. Att göra dessa typer av statiska analyser av kommersiell programvara när du inte har antagit grundläggande säkerhetsåtgärder är mycket som att installera ett panikrum när du inte har ett lås på ytterdörren.
Likaså är det förmodligen verkligen frustrerande och gagnlöst att presenteras med samma automatiserade analys om och om och om igen.
Men som helhet avslöjar artikeln några allvarligt föråldrade idéer om systemsäkerhet och förhållandet mellan utvecklare och kunder. Jag uppskattar att Davidsons jobb är frustrerande, men användare som går ut ur deras sätt att verifiera säkerheten för den programvara de använder är inte problemet. Här är presidenten för säkerhetsmedvetenhet, Ira Winkler tar på det:
"Oracle är ett mycket stort och rikt företag, med produkter som är brett distribuerade och används för kritiska applikationer. Period. De har ett ansvar för att göra programvaran så stark som möjligt [...] Det kan finnas många falska positier och därmed sammanhängande kostnader, men det är en faktor [som säljer] mycket mjukvara som har många användare. Det är en kostnad för att göra affärer. Jag är säker på att alla mjukvaruföretag har samma falska positiva rapporter. Jag hör inte Microsoft et al. klaga.”
Om Oracle inte vill behålla tusentals problem som finns med statiska säkerhetsverktyg, kanske de borde fixa de tusentals problemen. Om de är irriterad av att människor vänder sig i samma icke-buggar om och om igen, kanske de borde ha ett ordentligt felprogram som har mekanismer för att hantera upprepade inlägg av icke-problem. Oracles kunder klamrar för en högre säkerhetsstandard, och det är inte det rätta svaret.
Även om Oracle har tagit sig ner och allmänt misshandlat posten, så är det skrivet över huvud taget en djupt missvisad säkerhetskultur inom Oracle. Oracles säkerhetsstrategi prioriterar att skydda sin egen immateriella äganderätt över sina kunders säkerhet och sinnesfrid - och om du överlåter Oracle-mjukvaran med kritisk information, bör det skämma bort bejeezus ur dig.
Vad tror du? Är du oroad över Oracles säkerhetsfilosofi? Tror du att Davidson behandlas för hård? Låt oss veta i kommentarerna!