More Java Vulnerabilities

Oracle recently announced an update which patches twenty separate vulnerabilities all of which individually can provide remote access to an affected system without authentication. I’ll re-iterate that just in case you figured it was a mistake on my part: each of the individual twenty CVEs mentioned in their patch summary pose a direct remotely exploitable risk to a machine running their Java VM.

Those of you who have been reading my blog for a while will know how I feel about Java – more specifically the official implementation, and I realize that I am, to an extent, preaching to the converted. I realize that those who are still running the Oracle JVM are doing so for a very good reason and that there are custom application suites which have been developed specifically for certain niche industries where it is simply infeasible to even consider migrating to any sort of alternative solution.

That said there are literally millions of home and small business machines with the Oracle JVM on-board for no good reason other than that the OEM decided it was a good idea (along with all of the other bloat that vendors typically include for reasons no intelligent engineer can understand). The world wide web has pretty much abandoned the Java experiment, and it is safe to say that most users in the aforementioned group are needlessly increasing the risk profile and exposure of their PC.

I’d like those of you who are stuck with the Oracle JVM to just take a few minutes to consider whether there is anything your organization can do (over and beyond the obvious – staying up to date on patches) to reduce the risk to your enterprise. Can an alternate Java virtual machine be substituted? Can you apply the principle of least privilege to at least minimize the amount of damage a compromised Java VM could actually do to your infrastructure?

… and finally, most importantly, the most important question of them all: how can your enterprise extricate itself from requiring this behemoth of bad engineering?

Local Privilege Escalation in gksu under VirtualBox (CVE-2014-2943)

Earlier this week metasploit contributor Brandon Perry discovered a privilege escalation vulnerability in gksu running on the popular virtualization platform VirtualBox. It is important to note that Perry states the vulnerability is entirely the fault of gksu and that VBox does essentially what it is supposed to do. The linked article explains it all more thoroughly. It has now had CVE-2014-2943 assigned.

Another BMC Vulnerability

The good folks over at CARI SIRT have discovered a vulnerability in the BMC controller shipped with many Supermicro servers. The vulnerability essentially allows an attacker to connect to port 49152 and issue a GET request for a file called PSBlock, the plaintext passwd file for the service. Now, obviously given that most people know better than to leave IPMI or other management features publically accessible and most servers at the very least ship with the management controller bound to the secondary NIC (I believe Supermicro doesn’t have this sensible default set in the BIOS), so I would assume that most competent system administrators have quarantined the BMC feature within their management network.

That said, I have on several occasions opined about the danger of both IPMI on servers and Intel’s AMT on desktops – a danger that is not helped by the fact that many people aren’t even aware that their board has the feature in the first place. Of course, disabling any and all remote management features and requiring positive action (i.e. enabling IPMI, AMT and WoL manually on a BIOS setup page) to enable them would be the sensible thing for all vendors to implement given that there are large numbers of networks that don’t even use or even want the features and the risks they pose. There is patched BMC controller firmware image available from Supermicro’s website, but the CARI article indicates that as of writing there were potentially over 31k vulnerable devices publically scannable by Shodan.

Truecrypt Update

I figured it would be pertinent to update everyone on the Truecrypt situation. Ultimately, very little has changed and we don’t know all that much. Matthew Green had an exchange with Steven Barnhart on Twitter essentially stating that the development team simply got tired of updating the software and that this action was unrelated to the audit.

My belief that this shutdown was at the request of a government agency persists despite information flowing through to the contrary, and there are a few anecdotal indications that seem to indicate that the page posted to the website was a canary, remembering that directly stating that development has been discontinued due to the receipt of a NSL would violate the order’s secrecy provision and the likely result would be the party responsible would face a secret court. So, one can understand why double talk and innuendo are required when so much is at stake.

Posters on Bruce Schneier’s blog have pointed out the strange wording of the statement, “using Truecrypt is not secure as it may contain unfixed security issues”; perhaps they were specifically ordered not to fix a certain vulnerability in the code and instead wound up the project. Perhaps the statement on their website (emphasis mine) is a warning of such interference.

The other curious thing is that requests to resources on truecrypt.org return a 410 (Credit: Andy). The 410, according to the hypertext RFC is used “if the server knows …. that an old resource is permanently unavailable … This status code is commonly used when the server does not wish to reveal exactly why the request has been refused”

Of course we are all just speculating. If the developers of the project truly wished to wind up their operations and everything was otherwise okay they would not have acted in this manner. Advising users of Windows to migrate to Bitlocker is anathema to the majority of TC’s userbase. A simple note on the website that the project has been discontinued due to a lack of funds/time/support/devs/etc. would have been far better and leave less questions surrounding the true circumstances of their abrupt exit from the market. Indeed, despite the fact that old and unmaintained software can have unpatched vulnerabilities, most would leave their full project page and download area active, albeit with the above caveat attached. A statement to the effect that they are abandoning the source code into the public domain or relicensing the code code with a FOSS-friendly license would have also been the responsible thing to do – allowing others to fork and build on the work that you started. Indeed, even if they did all of the above a fork may not be the best idea given the source code may be encumbered with non-free components (those unaware of the E4M controversy that occurred early in the life of TC should view the History section of the project’s Wikipedia page for a brief primer).

The smartest thing – moving forward – would be for a new project to begin. This project would aim to create a functional replacement for Truecrypt whilst not necessarily using TC code nor providing backward compatibility will provide a modern full disk encryption suite primarily for Windows systems.

The project should:

  1. support GPT/UEFI
  2. have an on-disk format compatible with LUKS or dm-crypt
  3. use a crypto accelerator if the motherboard has one fitted
  4. have a simple user interface and comprehensive help where options are unclear

Essentially all of the above (with the exception of points 1 and 3) were implemented in FreeOTFE almost ten years ago. The latter has also become abandonware but its source code – along with the Linux kernel source for LUKS and its associated modules – would be useful for someone attempting a (near) clean room re-implementation.

For the moment – the average Windows user has three choices. They can continue to use the deprecated v7.1a of Truecrypt despite the ominous warning, they can migrate over to a commercial solution like Bitlocker or PGPdisk or they can switch to a platform that has decent and open source FDE such as Linux or FreeBSD. The use of file based encryption tools is also a possibility but one fraught with danger on Windows, which is liable to leave unencrypted copies of your data everywhere (e.g. thumbnail caches, browser cache for viewed hypertext files, filenames at the very least stored in recent document lists, etc.).

As I said earlier, when the Snowden disclosures were brand new and still leaking out in a piecemeal fashion from the Guardian et. al. – the NSA have started something big, and the cumulative results of what amounted to them shaking the crypto-tree hard enough for some apples to fall out will be felt for a long time and result in definite changes to the way we conduct business and confidential transactions online. I believe that we are perhaps witnessing the opening salvos of a war between the government agencies and privacy advocates and the hackers who make privacy software happen. The EFF probably needs our support and funding, so if anyone has a spare few dollars and wants to donate to a good cause, the EFF is certainly a worthy foundation.

TrueCrypt Website Compromised?

Aside

Earlier today we found the official TC website had been modified and now featured a warning to disuse the product. I initially suspected website compromise but found that the “new” TC packages offered are signed by a legitimate looking key. To further confound the issue a representative from Sourceforge reported earlier that no unusual activity had been noticed. This may be a plain and simple compromise but it may also be the TC developer’s way of informing the public that they are unable to guarantee their privacy, perhaps as a result of a NSL. I am trying to contact individuals who should know more about what is going on, and will update this post later today as the fog dissipates on this issue.

Readers of this blog will know that I have never particularly liked the secrecy behind TC’s development. It remains to be seen what happens next, especially with the interim results of the TC audit due to be released next week.

Link

Wang Jing, a PhD student at a Singaporean university has discovered a vulnerability in OpenID and OAuth. While not earth shattering, with sites like Facebook relying on it to authenticate their users the impact of such a vulnerability could be non trivial.