Tag: security

Broken Windows Updates

a close up of a broken glass window
Photo by Ivan Vranić on Unsplash

Every month Microsoft releases security updates on the second Tuesday of the month in order to remove security problems in the installations of the Windows Operating System.

January 9th was no exception, but this time there was a problem. One of the updates (KB5034441) failed with the error number 0x80070643, and kept failing on several machines. I paused updates and when updates resumed a week later the patch was gone.

Fast forward to last week, February 13th, and the problematic update is back, and still failing.

According to the MS support article this patch is for something in the Windows Recovery system, related to a problem with the BitLocker file system encryption, and it updates a special partition on the disk (on the systems I have checked it is 500 MB) and the patch claims it needs 250 MB free (there is no information about how much is available in the Windows Computer Management disk info).

Following the failures on many systems, Microsoft posted another article with instruction of how to manually resize the partition so that the patch would apply.

I have several problems with those instructions:

  • The instruction are very advanced, requiring the user to resize an existing disk partition with data to free up space. This is an operation I only undertake when installing a system, before I actually store data on the system. The worst that can happen is that the data in the partition are lost.
  • Further, once the partition has been reduced, the user have to run a highly specialized command as administrator in the terminal window to resize/recreate the recovery partition.

Neither of these are actions are something I (a fairly advanced user) would like to undertake on my own production systems, much less in combination, and I suspect that a normal user would refuse to even consider it.

Actually, I further suspect that most normal users wouldn’t even be aware that the update was failing. There is no indication or notification in Windows that a patch failed to apply, and a normal user will just find their PC rebooted the morning after it applied patches, and conclude that the PC is fully up to date and secure. I only know the patch is failing because the last two months I wanted to control when and how my PC rebooted to apply the patches so that it didn’t disrupt what I was working on.

What this means that, assuming this is a patch for a severe issue (and as it have something to do with bypassing the BitLocker disk encryption, it is severe), most users for which this patch is failing are probably blissfully unaware that they have an unpatched security problem on their machine.

Where is the Press?

What I have noticed about this issue is that AFAICT few of the online news services I monitor seems to have reported on the problem. I have noticed at least one Twitter thread, some MS forums threads, but no news media articles.

The Register (which bills itself as “Biting the hand that feeds IT”), did post an article in January, but have not yet followed up after the February repeat. Others, like ArsTechnica and The Verge seems to not have noticed.

What needs to be done?

What Microsoft needs to do about this patch is that it must fixed so that it is able to safely complete its operation without disturbing the user, or requiring the user to manually change their system.

I also think that the patch should be made to complete successfully without changing partition sizes. To paraphrase what Bill Gates reputedly said: “500 MB should be enough for any recovery partition.”

Not out of the woods yet: There are more POODLEs

As I wrote in my previous article about this, in October a group of Google security researchers had discovered a problem, called POODLE, in SSL v3 that in combination with another issue, browsers’ automatic fallback to older TLS and SSL versions, allowed an attacker to quickly break the encryption of sensitive content, like cookies.

The main mitigating methods for this problem are disabling SSL v3 support, both server side (now down to 66.2%, but slowing down) and in the client, and to limit the automatic fallback, either by not falling back to SSL v3 (which is now implemented by several browsers), or by a new method called TLS_FALLBACK_SCSV (introduced by Google Chrome and others). Continue reading “Not out of the woods yet: There are more POODLEs”

Attack of the POODLEs

Three weeks ago a group of researchers from Google announced an attack against the SSL v3 protocol (the ancestor of the TLS 1.x protocol) called POODLE (a stylish abbreviation of “Padding Oracle On Downgraded Legacy Encryption”). This attack is similar to the BEAST attack that was revealed a few years ago, and one of the researchers that found the POODLE attack was part of the team that found BEAST.

POODLE is able to quickly discover the content of a HTTPS request, such as a session cookie, but only if the connection is using the SSL v3 protocol, a version of SSL/TLS that became obsolete with the introduction of TLS 1.0 in 1999. As almost all (>99%) secure web servers now support at least TLS 1.0 (which is not vulnerable to the attack, provided the server is correctly implemented), it might sound like this attack is not very useful. Unfortunately, that is not so. Continue reading “Attack of the POODLEs”

The Heartbleed vulnerability (or why you should change your Vivaldi.net password)

A few days ago a group of researchers revealed that they had discovered a serious vulnerability in OpenSSL 1.0.1, an implementation of the Transport Layer Security protocol (TLS, or SSL) which they called “Heartbleed“.

This vulnerability is very serious and will take its place among other serious TLS-related vulnerabilities of the past few years, such as the Renego problem, BEAST, CRIME and others, and is probably even more severe than any of them, particularly since this problem does not require working with a complex setup through the user’s browser, and the scope of the attack affect all users, not specific users. Some, like Bruce Schneier, are using the word “catastrophic” and this label may actually be warranted in this case.

Heartbleed’s severity is due to the fact that an attacker, exploiting a problem in OpenSSL’s implementation of a TLS protocol feature called the Heartbeat extension, developed as a lightweight way to check if a secure server is still alive, can get 64 KB of raw memory from the vulnerable server. This memory can contain passwords, or other sensitive user data, but worst of all: it can contain the private encryption keys used to secure all transactions with the server, meaning that an attacker can pretend to be the site and perform a Man In the Middle attack against the site and its users. The problem have been present in OpenSSL for two years, and there is no way to know if it have previously been discovered and used by others.

Consequences

There have been a lot of writing in various news sites about this issue, and while some have moderated their stories after a while, many still have some exaggerations as well as some very bad advice mixed with good advice.

First of all, this issue does not affect 65-70% of all websites, 17% is probably more accurate. It is accurate that about 65-70% of web sites use OpenSSL, but most are still using older versions that are not vulnerable to this issue. Netcraft estimates the number of affected servers at 17%. This sounds reasonable, as my own scans indicates that 23% of TLS servers that I have scanned
support TLS 1.2, not all of which are using OpenSSL, which was also added in the vulnerable versions of OpenSSL.

As the vulnerability also may have exposed user’s passwords, a number of articles recommends changing passwords, in part prompted by statements from computer security experts and government agencies, some of them saying something like “Change all your passwords RIGHT NOW!!!”. Unfortunately, if you do so without doing a couple of checks first, that could be almost the worst thing you can do. Why? This is why: if the website has not been updated and secured before you change the password, then you might just be handing the attackers your new password on a silver platter. Before changing your password, make sure, by asking them, that the site have secured its servers. Otherwise, you may have changed one unsecure password for another one, and will have to repeat the process when the site have been secured.

Also, please note that some websites may send emails about this issue, and that scammers are sure to follow up with phishing email  using Hearthbleed password updates as the bait. Never click on links in such emails! Use your normal URL for accessing the site, verify that the site has been secured (by asking), then change the password using the standard methods for doing that, in the account preferences.

What about Vivaldi.net?

Like many sites with a modern Linux based server park, Vivaldi.net was using one of the vulnerable versions of OpenSSL, as was our distribution service, CloudFlare.

To fix the problem on our servers, we did not just have to upgrade the servers to use the patched version, we also had to create new private encryption keys for our servers and obtain new SSL/TLS certificates for them, and revoke the old certificates. Our servers are now secure against this problem.

We, and all other web sites affected by the problem, have to go that far, since the vulnerability may have exposed our private keys, which means they cannot be trusted anymore.

However, be aware there may be a couple of side effects for clients due to the changed certificates. When we changed the certificates we also upgraded them to being signed by the more secure SHA-256 method. This also means that the certificates are signed by a new intermediate certificate, but the web and email servers are sending this certificate, but it appears that some clients have problems, either with the certificates or by not understanding SHA-256. In such cases an upgrade of the client may be necessary.

Unfortunately, the process of recovering from this vulnerability is not over yet. Now it is your turn.

We do not know, and probably will never know, whether or not somebody attacked our servers using this vulnerability before we were able to patch the servers and replace the certificates. If they did, then the passwords of all our users may have been compromised, and this means that you should change your password for Vivaldi.net as soon as possible.

Vivaldi.net now showing EV-green in browsers

Friday evening (20 December) those who keep an eye on the browser UI would have observed a small but significant change take effect at Vivaldi.net: The browser turned on the Extended Validation “Green Bar” for us, indicating that the identity of our website was now better assured than it has been, though the encryption is just as good as before.

Previously, while we were developing the site and during the first days of it being live, we used a Domain Validated SSL/TLS certificate for our sites that indicated that we had control over the domain, but not who we are. This is a useful level of web site identity verification for smaller sites that only need to present information securely and without any major collection of personal information. 

For users of a web site that collects or manages personal and payment information, it is not just important to know that the people managing the web site are in control of the domain. It is even more important to know, or be able find out, who they are, legally speaking, in case there is a problem.

This need for verifiable identity information was why a group of Certificate Authorities, such as Verisign and Entrust, and Browsers, such as Microsoft, Mozilla and Opera (including yours truly), gathered to found the CA/Browser Forum so that we could define what eventually became the Extended Validation (EV) Guidelines for CAs, and the associated “Green Bar” in browsers.

When Jon decided to start the Vivaldi.net social web site project, one of my suggestions was to have an encrypted site. Given recent revelations (e.g., NSA) it is now, or should be, unthinkable to have a social web site that is unencrypted. While many sites have been using a hybrid approach where the login, account management, and sometimes authoring, is encrypted, there are just too many ways to sniff information that way, so the whole site needs to be encrypted. Another of my suggestions was to use EV certificates on the sites, to provide better identity information and assurances to our users.

While I would have wished to have unveiled Vivaldi.net on Wednesday with an EV certificate, the process of obtaining one was intentionally designed to include a lot of paperwork that has to be completed before the certificate can be issued, and that paperwork was not completed by our CA, GlobalSign, until early evening Friday.

So, go ahead and enjoy Vivaldi.net, assured that it is Jon’s company, Vivaldi Technologies AS, that is operating it.