Oracle July 2014 CPU (patch bundle)
In addition to the Java vulnerabilities that I covered earlier, there is at least one more vulnerability that warrants attention. CVE-2013-3751, a problem in the XML parser of Oracle Database. Reading the description, I had a bit of a déjà-vu, also because of the CVE number from last year. And digging into past alerts, I found that, yes, this has indeed been patched before:
Looks like the Oracle 12 code was forked before the 11g patch went in, and nobody ported it over, so Oracle 12 remained exposed to the same bug until now. This speaks volumes about Oracle's software development life cycle and security processes... Dear Larry Ellison: how about writing a "Trustworthy Computing" memo for your staff, and then following through on it? I'm sure Bill Gates won't mind much if you simply copy his from 2002 and do a little search-and-replace.
For other untrustworthy computing features brought to you by this month's CPU patch bundle, see https://blogs.oracle.com/security/ and http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html
Oracle Java: 20 new vulnerabilities patched
Welcome to the n-th iteration of "patch now" for Java on Workstations. Oracle today published their quarterly patch bulletin, and Java SE is once again prominently featured. This Critical Patch Update (CPU) contains 20 new security fixes for Oracle Java SE. Most of the vulnerabilities are remotely exploitable without authentication, and CVSS scores of 10 and 9.3 indicate that they can be readily exploited, and lead to full compromise. Which means that keystroke loggers, ebanking trojans, etc, will soon follow.
Oracle/Java is probably by now one of the most successful charities in the world, it continues to do an outstanding job at enabling significant wealth transfer to support poor cyber criminals and their families. Except that the sources of the funds usually have no idea, and didn't agree to donate directly from their bank accounts ...
After the past three years of repeated gaping holes in Java, we hope that by now you have found a way to remove Java from your computers entirely, or to at least no longer run the Java plugin within the web browser. Otherwise, it is back to the hamster wheel, to yet again re-test all your applications that still require Java, to check for the inevitable incompatibilities with this latest release, and then to expedite the roll-out. This is definitely a patch that you don't want to skip or delay.
The full Oracle patch bulletin is available here: http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html#AppendixJAVA .
The other Oracle patches (for database, etc) released in today's patch CPU are still under analysis here at SANS ISC. I'll post about them later, if warranted.
AOC Cloud
In matters of food and wine, the Europeans have this concept of "AOC", based on the originally French "Apellation d'origine contrôlée". It means that, say, Bordeaux wine actually comes from there, and is not re-bottled Malbec from Patagonia. The point I'm trying to make, albeit poorly, is that it is sometimes important to know where things are coming from, which implies traceability to the source.
In matters of IT, we are currently losing this AOC. Only three years ago, we likely knew exactly, down to the server room cabinet and shelf, where our mail server was located. These days, with "cloud" services proliferating rapidly, we might know who *sold* us the service, but we only have a vague idea of its real origin or location.
The question recently came to light again when Codespaces (http://www.codespaces.com/) went down after a hacking attack back in June. As they say on their web page "In summary, most of our data, backups, machine configurations and offsite backups were either partially or completely deleted". I wonder how many (if any) of Codespaces' customers had actually done the due-diligence, while signing up, to determine that all of Codespaces' services were hosted at Amazon EWS, *including* the backups. That's AOC! You might know from where you buy your SVN or GIT hosting, but - unless you negotiate hard, forbid any sub-subcontracting, and ruthlessly enforce your right to audit - you might never learn where your SVN/GIT hoster actually hosts the service. And, not even with your right to audit, will you ever find out where *that* hoster draws their services from. Because you don't have a contract relationship with the hoster (only with the SVN service on top), and if the hoster, at their discretion, decide that they can operate more cheaply by re-selling Virtual Machines from Patagonia instead of running their own .. that's what's going to happen.
If you like this concept, I have a stellar 1961 Bordeaux that I'm willing to part with for a good price. Please don't worry about the penguins and the Spanish language on the label :).
In all seriousness though - it is overdue that "cloud" providers provide a bit less cloud, and a bit more sunlight. It might hurt their bottom line a little, but the kind of "AOC" end-to-end transparency, with traceability to the source, is vital and paramount for the customer to assess and mitigate any resulting risk.
If you have any stories on how you determine the "AOC" of your penguin wine (or not), please share below.
Comments