36

From what I've read, Spectre and Meltdown each require rogue code to be running on a Windows box in order for attacks to take place. The thing is, once a box has rogue code running, it's already compromised.

Given that the Microsoft patches for Spectre and Meltdown reportedly slow down the patched systems, it seems like possibly a good decision to leave Windows systems unpatched at the OS level.

Assuming rogue code is not installed on a Windows box, the only point of easy penetration to a system seems to be via javascript running in a web browser. Yet both Mozilla's Firefox and Microsoft's Internet Explorer have already been patched. Google's Chrome is not currently patched, but it can reportedly be run in strict site isolation in order to prevent successful Sprectre and Meltdown attacks.

Given all the above (and assuming best practices of not running unknown code), does it really make sense to patch Windows for Spectre and Meltdown?

RockPaperLz- Mask it or Casket
  • 3,114
  • 21
  • 50
  • 15
    Windows is a multi-user operating system. If one user without admin privileges runs rogue code, that code shouldn’t be able to affect or compromise other users. But Meltdown allows it to do so. Running rogue code in user space should _not_ mean that your machine is completely compromised, and if it does then that’s a hole that needs patching. – Mike Scott Jan 12 '18 at 07:33
  • 8
    @MikeScott - I'd argue that Windows is very often a Single User box, because it's used by exactly one person. For a strictly personal box, I think it *might* make sense to *delay* these updates until MS figures out the mess they've made of it so far. My personal experience is: 90% of what I do on my computer is done through Firefox running in User Mode - if any exploit gets through FF, it doesn't matter too much anymore whether it can read everything. https://xkcd.com/1200/ – Martin Jan 12 '18 at 13:26
  • 2
    @Martin - It can't just be a personal box. It would have to be a personal box where everything confidential was accessed through and only through a patched browser with no other untrusted code running on the machine. As per my answer there are a lot more ways untrusted code runs than OP believed. – Hector Jan 12 '18 at 18:58
  • Also keep in mind that since Windows updates are no longer provided as individual patches, the only way to not install the patch for Meltdown and Spectre is to stop installing patches entirely. – Harry Johnston Jan 12 '18 at 23:27
  • A generic improvement to the mindset of *"should we apply this patch?"* is changing it to *"how long should we delay applying this patch?"*. – Peter Jan 14 '18 at 11:35
  • Being able to run code on a machine does not mean its compromised - the application might be and the account but not the box. If i find an RCE but then find the box is fully patched and runs a strict application whitelist and the account is restricted / sandboxed. I haven't compromised the box and I might never break out. – McMatty Jan 18 '18 at 23:42
  • 1
    I find it amusing that the COSTS of these patches are only indirectly discussed here. There is some vague mention of the extreme of turning off a computer and locking it away, which is of course not a practical solution, and everyone realizes it. But applying a patch that reduces performance by, say, 15 percent (doesn't sound like much, right?) is like turning off 1 in 7 computers, is it not? – NoelC Jan 27 '18 at 13:43

6 Answers6

85

the only point of easy penetration to a system seems to be via javascript running in a web browser.

How about Flash? Java? Silverlight? VBA in an office document? Any applications that load web-pages inside of themselves?

The thing is, once a box has rogue code running, it's already compromised.

With code running under your user account a lot can be done. But compromised is a relative term. You can't for example install a low level key logger. Permissions might stop you from reading other applications memory space even when run under the same user account. And of course you have no access to files and processes run under other user accounts. A user on a corporate machine could not hijack another logged in users session.

Being able to read arbitrary RAM values can give you the access tokens required to defeat all of this.

Hector
  • 10,893
  • 3
  • 41
  • 44
  • 13
    Also running code in the user space (by compromising a user account) produces a lot of forensic evidence in audit logs. Getting data from L1 cache of the processor through side channel is virtually undetectable through the OS or other high-layer routines. – void_in Jan 12 '18 at 04:59
  • 9
    @void_in It's not virtually undetectable. It **IS** undetectable, and that's why the security flaw is so bad. Nobody expected it to be an attack vector. It took 20 years to discover, and it is a relatively simple concept. The security flaw uses something that happens constantly on a computer. You outright can't detect the attack. – Nelson Jan 12 '18 at 07:29
  • 4
    @Nelson - reading any useful amount of data would generate unrealistic numbers of certain kinds of interrupts. So with some system profiling you would technically be able to detect it - albeit at a fairly major performance cost. – Hector Jan 12 '18 at 07:51
  • 2
    @Hector That's not necessarily true. There's nothing inherit to the exploit that requires all the speculative training and data reading to be done within a small time frame. The key is whether the CPU speculative reads are maintained for certain files that are repeatedly executed. If it is, just make it run at a low rate over a long period of time, slowly building up the memory read until you hit the needed data for access escalation, then the system is compromised and nobody's the wiser. – Nelson Jan 12 '18 at 11:26
  • @Hector: Interrupts are not technically required; that's just one particular exploit possibility. – MSalters Jan 12 '18 at 13:10
  • Do Flash or Silverlight plugins JIT-compile the untrusted code they sandbox? I haven't heard of Spectre attacks being plausible through interpreted code; too hard to train the indirect-branch predictor. Meltdown is even more unlikely; you need to arrange for something to try to load from a kernel address. Maybe you can do that via mis-speculation of some branches, but it's definitely a lot harder when you can't run arbitrary machine code. Javascript doesn't have C-like pointers that you can just set to kernel addresses... Plausible from a JIT sandbox, but interpreted is too many layers. – Peter Cordes Jan 13 '18 at 07:08
  • 2
    @PeterCordes Both use JIT yes. Silverlight scripts are basically sandboxed .Net - you can use any .Net language. As for JavaScript proof of concepts already exist and several browser vendors have confirmed their own internal tests showed it possible. – Hector Jan 13 '18 at 09:05
31

In my world, applying patches is a given. We're going to do it and it takes an exception to NOT apply a patch.

Right now, those are exploits we know about for Spectre and Meltdown. However, what's to guarantee that there won't be more? Further, many exploits out there (such as Wannacry/Petya) involve systems that aren't patched for this known issue.

I'd close with this thought: are you prepared to stake your professional reputation on not applying a known patch to fix a known vulnerability? That seems, to me, to not be a wise bet. Imagine in your enterprise if malware based on one of these two gets into your network. One of management's first questions is: how did this happen? Did we know it was possible? Were there preventions available and if so, did we apply them? I've been the subject of these questions based on management's decisions to accept a security risk and it was not a comfortable place to be.

To answer your question: no, it's not necessary. But failing to do so, IMO, is irresponsible.

baldPrussian
  • 2,768
  • 2
  • 9
  • 14
  • 5
    I think an excellent example of an exception to the rule where management may agree that the security risk is acceptable: You have a product delivery date in 2 weeks, and patching your grid will result in a slow down that causes you to miss the deadline. As baldPrussian pointed out, this is a management decision: they need to decide that making that release is a better value to the company than having the machines patched immediately. – Cort Ammon Jan 12 '18 at 00:58
  • 1
    @CortAmmon In that case it may be worthwhile to let the account manager communicate with the customer what they prefer: ship on time or ship with the fix X days later. It's usually the right thing to do with exploits of this (media-)magnitude. – Mast Jan 12 '18 at 09:22
  • Your Closing Thoughts remind me what 'caused' the Equifax breach... https://www.theregister.co.uk/2017/09/14/missed_patch_caused_equifax_data_breach/ -- a patch that wasn't deployed. I would not want to be that person responsible for patching. – Aron Jan 12 '18 at 17:05
  • @CortAmmon I've been in more than one situation where something far less critical but still dangerous took priority over million-dollar deliveries. I've never encountered a single corporate client that didn't understand a delay in that situation; in fact they're usually very supportive. I bet it has a lot to do with how the account manager handles the message. – thanby Jan 15 '18 at 18:11
8

Yes, because it can be used for privilege escalation. Usually, if an attack compromises a host, they only have user privileges. Using this vulnerability, they can escalate privileges by leaking credentials. Privilege escalation is important to attackers for carrying out many attacks, such as arp spoofing, SMB/LDAP relaying, token hijacking, credential dumping, etc.

Daniel Grover
  • 872
  • 5
  • 10
8

Install the patches unless you have a very strong reason not to.

The approach you describe can basically be summed up as this:

I know about exploit X. I could patch my OS to resolve exploit X, or I could carefully revisit every operation I do on my computer (including automated update tasks done for me). If none of those tasks provide a risk, then I do not need to install the patch.

Yes, indeed, your logic is sound. It is the same logic which says "A computer that is powered down and unplugged is very resilient against hackers." However, it will call for you to exist in a continuous state of vigilance. Every single byte of code which gets transferred to your computer needs to be from 100% reliable source. You may even be operating on a network where this logic is sufficiently sound. But most likely you are not, so install the patches. (Stuxnet may be the ultimate example of what happens when someone thinks their network is unhackable)

You will need to remain in this continuous state of vigilance forever, or at least until you buckle down and install the patches.

As Daniel Grover answers, consider this as a vector for privilege escalation. The security of many systems depends on the assumption that a secret is, indeed, a secret. Meltdown/Spectre challenges that assumption.

Cort Ammon
  • 9,206
  • 3
  • 25
  • 26
  • 1
    When my management asks me "how do we become completely secure?", my response is "power down the device, encase it in concrete, cut the cord, and bury it in a swamp somewhere. That's the only way to become hackproof." Security is about how we slow down attackers and make the attack not worth the reward. – baldPrussian Jan 12 '18 at 01:06
  • 3
    @baldPrussian I have heard a similar quote: "The only truly secure computer is powered down, unplugged, buried in a concrete bunker with armed guards posted at the entrance. Even then, I'd check on it every once in a while." – Cort Ammon Jan 12 '18 at 01:30
  • @CortAmmon You've just helped the attacker in a DoS attack at your computer. – Maya Jan 12 '18 at 18:28
  • @NieDzejkob I have recommended a risk analysis to properly decide the best security measures. Security is always in a balance. – Cort Ammon Jan 12 '18 at 18:49
  • @CortAmmon I was referring to the comment about a concrete bunker. – Maya Jan 13 '18 at 18:06
  • @NieDzejkob Ahh I gotcha. Missed that. – Cort Ammon Jan 13 '18 at 23:56
4

On Windows boxes, is patching for Spectre and Meltdown necessary?

From what I've read, Spectre and Meltdown each require rogue code to be running on a Windows box in order for attacks to take place. The thing is, once a box has rogue code running, it's already compromised.

First, it sounds an awful lot like you're saying that, to avoid being hacked via Spectre or Meltdown, you just need to avoid being hacked by any method at all. But that's a much harder thing to do!

Second, compare,

In a business, is locking the safe necessary?

From what I've read, stealing stuff from a safe requires a thief to be inside the building. The thing is, once a thief is inside the building, it's already compromised.

Well, sure, but protecting yourself from some of the things the thief could do is still better than throwing your hands up and saying, "Well, he got in so he may as well take everything."

David Richerby
  • 1,636
  • 12
  • 13
1

The best argument I've seen for patching when presented with this line of thinking is this:

Detecting Spectre and Meltdown is very difficult and your AV product is not going to stop these attacks.

These are flaws in hardware expoiting speculative execution (branch prediction, etc). Your processor is always doing this and detecting malicious use is going to be extremely difficult to do. The entire mitigation strategy therefore is to patch, since detection is off the table.

Given the number of exploit PoC that have been developed and demonstrated in the last week (and just from an idea of what the bugs were, before the embargo ended) I have no doubts that malicious weaponized exploits for these bugs exist.

casey
  • 111
  • 3
  • Who in his right mind installs AV products on a server ?!? – Stephan Schinkel Jan 15 '18 at 11:45
  • @StephanSchinkel - Lot's of people are required by law to have AV on a server. I have an AV on every single one of my servers and clients, both Linux and Windows, and have to update the signatures every single week. – Ramhound Jan 16 '18 at 17:50
  • @StephanSchinkel you may not have AV but you probably have an SOC doing IDS, monitoring, endpoint management, logging, etc. The point was detection for these exploits is going to be hard and isn't going to save you. Aside from that I didn't see where the OP specified servers, just "windows boxes". – casey Jan 16 '18 at 17:52