Oracle, de fabrikant van het bekende of wellicht eerder beruchte Java, staat bekend om controversiële uitspraken van medewerkers en zelfs de CEO. Onder meer in 2001 met toenmalige CEO en medeoprichter van de softwaregigant Larry Ellison. In dat jaar op een conferentie van hackers claimde hij dat zijn code onbreekbaar zou zijn. Nog jaren daarna kwamen er echter steeds meer kwetsbaarheden naar buiten.
Nu gaat het verhaal weer verder, want het hoofd van beveiliging Mary Ann Davidson heeft gezegd dat ontwikkelaars die zoeken naar fouten in de code bij het verkeerde eind zitten. Zo zegt ze dat als een fout ontdekt wordt, dat er dan naar de code gekeken is, terwijl opmerkelijk genoeg in hun Algemene Voorwaarden staat dat de code niet bekeken mag worden. Volgens haar mag het simpelweg niet.
If we determine as part of our analysis that scan results could only have come from reverse engineering (in at least one case, because the report said, cleverly enough, “static analysis of Oracle XXXXXX”), we send a letter to the sinning customer, and a different letter to the sinning consultant-acting-on-customer’s behalf – reminding them of the terms of the Oracle license agreement that preclude reverse engineering, So Please Stop It Already. (In legalese, of course. The Oracle license agreement has a provision such as: "Customer may not reverse engineer, disassemble, decompile, or otherwise attempt to derive the source code of the Programs..." which we quote in our missive to the customer.) Oh, and we require customers/consultants to destroy the results of such reverse engineering and confirm they have done so.
Hierboven een deel van de blogpost, waarin dus gezegd wordt dat de code niet 'reverse engineered' mag worden en als er mogelijke kwetsbaarheden gevonden worden, die data gewoonweg vernietigd moet worden. En als steek naar mensen die dat wel doen werd het volgende geschreven:
“I do not need you to analyze the code since we already do that, it’s our job to do that, we are pretty good at it"
Mary Ann Davidson, hier bij een conferentie.
Hoewel het in haar tekst nogal vijandig gebracht werd, is het geheel naar ons idee wat genuanceerder. Het doel van de tekst was om consumenten te waarschuwen dat zogenaamde beveiligingstools die lekken in de code opsporen niet altijd bij het rechte eind zitten. Het sturen van een rapport dat uit zo'n tool komt is volgens het hoofd beveiliging ook onwenselijk. Beter zou het zijn om te laten zien dat het lek er ook echt is en vervolgens een 'service request' aan te maken bij het bedrijf.
I should state at the outset that in some cases I think the customers doing reverse engineering are not always aware of what is happening because the actual work is being done by a consultant, who runs a tool that reverse engineers the code, gets a big fat printout, drops it on the customer, who then sends it to us. Now, I should note that we don’t just accept scan reports as “proof that there is a there, there,” in part because whether you are talking static or dynamic analysis, a scan report is not proof of an actual vulnerability. Often, they are not much more than a pile of steaming … FUD. (That is what I planned on saying all along: FUD.) This is why we require customers to log a service request for each alleged issue (not just hand us a report) and provide a proof of concept (which some tools can generate).
De rest van het verhaal kan voor zolang het niet door Google verwijderd wordt, hier verder gelezen worden.
