Security – Hell in a handbasket

The last 2 weeks have really been a bad time for security news and one has to hope things will change for the better; if not, the headline says it all!

BlueKeep

Microsoft released a security patch 2 weeks ago related to Windows Remote Desktop Protocol (RDP) which is used to remote access Windows systems. I’ve long said RDP was inherently insecure and the chickens are coming home to roost now – RDP was found to be vulnerable to a recently disclosed critical, wormable, remote code execution vulnerability.

Dubbed BlueKeep and tracked as CVE-2019-0708, the vulnerability affects Windows 2003, XP, Windows 7, Windows Server 2008 and 2008 R2 editions and could spread automatically on unprotected systems. The vulnerability could allow an unauthenticated, remote attacker to execute arbitrary code and take control of a targeted computer just by sending specially crafted requests to the device’s Remote Desktop Service (RDS) via the RDP—without requiring any interaction from a user.

So to summarise:

  1. no authentication required
  2. remotely triggered
  3. full control over target devices
  4. no interaction required

The issue is so critical that Microsoft took the unusual step of pushing out patches for older unsupported versions of Windows including XP, Server 2003 and Vista. Time to patch?

MDS

As mentioned in a special blog entry a few days ago, new Intel side channel attacks have come to light, 4 of them collectively known as MDS or more colloquially, ZombieLoad. Yip, time for a stiff whiskey.

The 4 attacks are:

  • CVE-2018-12126 – Microarchitectural Store Buffer Data Sampling (MSBDS) [codenamed Fallout]?
  • CVE-2018-12127 – Microarchitectural Load Port Data Sampling (MLPDS)
  • CVE-2018-12130 – Microarchitectural Fill Buffer Data Sampling (MFBDS) [codenamed Zombieload, or RIDL]?
  • CVE-2018-11091 – Microarchitectural Data Sampling Uncacheable Memory (MDSUM)

Remediation includes both firmware (or microcode) and OS patches. Performance impact is expected to be around 10-15% for these patches. When you take this into consideration, along with performance impacts of previous remediations relating to Spectre/Meltdown, we’re starting to get Celeron performance in Xeon chips. Nice – $200 performance for $2000+ prices. Pay more, get less : )

On the bright side, you’re not affected if running AMD CPUs. And seeing the performance improvements in AMD’s latest Ryzen and EPYC chips, along with Intel’s chip shortage, that’s looking like a very good platform bet for the future.

Flipboard

In a case of “yet another online service breached” – let’s call it YAOSB, Flipboard advised that they were the unlucky (smile) recipient of 2 attacks last and this year, during which “an unauthorized party infiltrated some of its databases more than once and “potentially obtained copies” of the user information they contained.”

Besides usernames, email addresses and passwords, the miscreants also got hold of tokens used to connect Flipboard to other social media services such as Facebook.

Do NOT connect 1 social media service to another. Don’t do it. Ever. Even if they ask. With a pretty please.

So all in all, tough times for service providers all round. Patch, patch, patch. Change passwords. You know the drill.

Vuln mitigation and INtel MDS – the spectre looms

Spectre and Meltdown a have been with us for just over a year now and even with all the predictions of dire consequences, we have yet to see any in-the-wild code snippets or attacks beyond theoretical POCs. So the question to ask is whether we should be losing a lot of hardware performance (most of the associated mitigations have performance impacts) for the sake of potentially theoretical security issues.

I recently had a chat to a client about in what order vulns should be mitigated in their organization and what strategy to use in optimizing patch deployment. Admittedly the most popular, and common option is to approach this from the view of criticality. It’s rated critical so we should fix it? Well, not necessarily: there are many variables which impact the potential order of fix for your specific site or organisation. Factors like nature of systems, impact trend of the vuln, age and type of vuln, type of application, patching intervals, is it remote exploitable, reach and platform types can factor in more than just the CVSS score.

This class of CPU architectural issues is a specific case in point. Yes theoretically it’s possible to perform the exploits but have there been any practical implementations yet? No? So do we really need to patch? When there’s large costs associated with critical data loss and compromise, the choice is a difficult one and cuts a fine line.

And this class of exploit is not slowing down. A new Intel-focussed vuln called MDS (that apparently does not affect ARM or AMD platforms) comprising 4 related techniques was released in mid-May, the 3rd such announcement this year already.

Side channel attacks seem to be a dime a dozen these days, but again, this vuln (or class of vulns) is listed as being complex to exploit and possibly as theoretical as all the others have been. Apple’s immediate response was to switch off SMT (commonly know as hyperthreading) which results in an approximate 40% performance hit. As was Google’s response for Chrome OS. I can just see Homer saying “Duh?”.

Disabling HT/SMT by the way, does not completely mitigate MDS …

Once again, mitigations include hardware, firmware microcode and software/OS components, all of which need to be aligned to get full protection. Notwithstanding patching strategies and other blockers in rolling out co-ordinated fixes like this, what will the practical reach be for these patches? Servers will languish with delays and desktops (and other IOT devices) may never even get the firmware fixes.

So it’s all a bit wishy washy at the moment. Time for some risk analysis.