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.

KB2963983 IE Remote Code Exploit

Microsoft has released a bulletin warning of a bug in pretty much all versions of IE (6-11) which could allow remote code to be executed with the privileges of the running user.

Call me jaded but if you are still using IE, there is no hope for you. Sure – Microsoft has tried (and failed) to fix their product. The best thing they could do is concede defeat and bring us a rebranded OSS browser, perhaps based on WebKit. Huh? They are doing that?? It could just be my imagination.

RCMP Alleges Juvenile Cyber Thief Exploited Heartbleed

Aside

The RCMP alleges that 19 year old security “enthusiast” Stephen Arthuro Solis-Reyes took advantage of the recently disclosed Heartbleed TLS vulnerability to steal 900 social insurance numbers from a government website. The publication The Financial Post made the aforementioned claims in a recent article on their website. I strongly suspect given the large number of individual records collected that another vulnerability – such as a database with a weak or default password or the lack of input sanitation allowing the alleged attacker access to generate his own queries and that the Heartbleed angle has been tacked on erroneously. Others may disagree but I believe the aforementioned attacks are far more likely when all of the information in the public eye is assessed.

Heartbleed SSL Bug Leaves Many Large Corporations Red Faced

The recent disclosure of the so called  heartbleed bug (CVE-2014-0160) left many organizations who should know better red faced as they demonstrate their ineptitude at rapidly patching their machines.

For those who have yet to hear the news, the so called heartbleed bug is a vulnerability in OpenSSL that can potentially cause a leak of key material. This is obviously very bad mojo and the issue is compounded by the fact that OpenSSL is the most popular implementation used for https on the web.

Astute readers of this blog will know I have an issue with OpenSSL, whose author allegedly coded to learn bignum arithmetic. Of course that’s entirely irrelevant and potentially untrue. My real issue with OpenSSL mirrors that of Sun/Oracle’s Java – unnecessary complexity, terse code often with equally indecipherable comments and a huge history of vulnerabilities to boot. I could go on forever but when there are so many other libraries to use as an alternative then I can’t understand why anyone would bother with it. PolarSSL for example is just a mere fraction of the size of OpenSSL and performs admirably. Mozilla’s TLS implementation exists and is reasonable as is GNUTLS.

I could go on, but I have touched on all of this before. If you are unlucky enough to be affected, go ahead and grab the latest tarball of OpenSSL (1.0.1g) which has the issue patched.

The OpenSSL advisory notes that:

“Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley … and Bodo Moeller … for
preparing the fix.” (Redacted email addresses to reduce UCE to those above)

It is excellent that they are correctly attributing those who worked hard to find the bug, and I commend them for their responsible disclosure.