Memory management bug in Intel CPUs threatens massive performance hits.

[Bicurico]

What I meant is: can the "bug" be prevented on a CPU that is using out-of-order processor, branch prediction, speculation, cache and side channel?
Is it possible to have address space isolation with branch prediction and out of order processing?
As far as I have read, the only CPU's that don't suffer from this "bug" are the ones that do not feature branch prediction and out of order processing.

Again, I am genuinely asking because I don't know the answer.

In my mind (oh God, I am listening to The Smiths - Heaven Knows I'm Miserable Now and was starting the sentece writing along...), which has a simplistic representation of how the CPU works, the only secur way I could imagine would be a cache cleaning routine, that would wipe any memory block that had to be dismissed, before allowing any other process to use it. I don't know how that would hit performance and if this would even make sense...

Regards,
Vitor

[dmills]

Such a cleaning routine would expose you the other way.... Now I am timing to see if my accessible cache line has been evicted from the cache by the speculative load!

Having the speculative load check the memory safety of BOTH branches before executing the cache load (And falling back on a pipeline stall followed by an in order load if the MMU reports that both addresses are not safe) looks like it would work, but would move the problem to the TLB (You would need to fall back it the TLB does not contain both possible target pages rather then loading a TLB entry!).
You would still have a small window between changing the MMU permissions and the speculative load that would need careful consideration as there might be a window of a few instructions there that could be exploited.

This is a non issue if you take care to ensure that you control the jobs running on your machines, which of course sucks for the cloud providers (My heart bleeds, bleeds I tell you!), and probably argues that we should NOT have ended up with turing complete web browsers!

I am surprised that folks are surprised by this, cache side channel attacks are a common and popular game for breaking badly written crypto and out of order execution and its interaction with the cache is about as hard to reason about as crypto implementations.


Regards, Dan.

[SeanB]

Basically this was known about years ago, as an erratum in a datasheet about the superscalar architecture, having variable latency in branching, due to the speculative code execution, branch prediction and other fun things to do with caching. Due to the CPU being so fast that waiting for the slow ( to the CPU) L2 cache to respond to a memory access request would involve 100 or more clock cycles that could otherwise be used, and the L2 cache similarly would have a 1000 or more cycle ( to the processor all of eternity plus some more in waiting time for the first byte to come through, then again an eternity for the rest of the byte) to main memory for data. Thus the need to use that otherwise unused cycle time, first by having a prediction algorithm to do the OOO execution, the predictive branching and the speculative execution in the waiting time, and then having extra cache space and controllers to handle all the data that came with it before it was discarded, and then seeing that a separate set of those cache blocks and some logic meant you could have a virtual processor to use the time that L1 was stalled waiting for L2 or main to respond, thus you could create hyperthreads in the same silicon with minimal overhead in most cases.

All this means that execution times per instruction depend on the other things around, and this was considered an annoyance as it prevented simple loops from being a good time ( as before on older X86 code with predictable number of cycle execution times and thus a known time to do a loop) standard. then just recently somebody took a look at that and thought that if the timing depends on what happens around the thread then there could be information leaking out of there. Thus Spectre and Meltdown, and previously Rowhammer where they thought about that old bug in memory, of bounce being an issue with memory cells if there was enough noise induced into a cell, to cause local reference rails to rise enough to cause a flipped bit in adjacent cells of memory.

[David Hess]

Simply because address space isolation is the bastion of multi-program, multi-user systems for the past 30 years.  It is meant to be absolutely impossibly for one program to read another's private memory.  The processor's architecture is meant to prevent this at a hardware level.  The bug means there is a way past this.

IBM should have known better but I saw a list of vulnerable processors which included theirs.  I think their Z series was on it.

What I meant is: can the "bug" be prevented on a CPU that is using out-of-order processor, branch prediction, speculation, cache and side channel?
Is it possible to have address space isolation with branch prediction and out of order processing?
As far as I have read, the only CPU's that don't suffer from this "bug" are the ones that do not feature branch prediction and out of order processing.

The thing in common with the processors which are vulnerable to Meltdown is that permission checks occur at instruction retirement which makes sense because that is where instruction faults must be resolved.  By definition, an instruction fault during speculation is irrelevant unless that side of the branch is taken which is why the exploit can take advantage of speculative instruction faults without causing an actual instruction fault which would be acted on.

All that is necessary to prevent Meltdown is an earlier permission check which either blocks speculative loads entirely or blocks the speculatively loaded data from being operated on during speculative instructions.  AMD apparently does this by invalidating (but not flushing) TLB entries on CR3 register changes which yields the benefits of the software workaround without the performance penalty and testing permissions of the speculative load before instruction retirement.

Having the speculative load check the memory safety of BOTH branches before executing the cache load (And falling back on a pipeline stall followed by an in order load if the MMU reports that both addresses are not safe) looks like it would work, but would move the problem to the TLB (You would need to fall back it the TLB does not contain both possible target pages rather then loading a TLB entry!).

There are no current processors which speculatively execute both sides of a branch which Wikipedia calls "eager execution".  If they did, then branch prediction would not be necessary because every branch would be automatically predicted correctly 100% of the time in retrospect.

[BrianHG]

LOL, I think the Motorola 68040 back in the day already had branch speculation caching as well.  Though, I don't believe it had the processing power with high resolution timers to take advantage of the flaw in the same way today's cpus can.

[BravoV]

Say there is a bad guy, and about to do a crime, also he worked as a programmer in a company that he has the know how the application's internal work that is used by the company.

Its running at an external hosting service to serve all their back office activities, say like general ledger, customers information or hell, even billing.

Now, once the guy quit the company, assuming he can order the same hosting service running at the "exact" same host as the company is using, and then do the snooping say all the customers info and etc and sell it to the company's competitor. 

Does this bug traceable if it happened ? I mean in system log ?

[David Hess]

Does this bug traceable if it happened ? I mean in system log ?

The data leak occurs through speculated instructions which are never retired as part of the visible instruction stream.  This is why monitoring for access violations will not reveal anything.  As far as the CPU is concerned, they never happened. 

If someone profiled the code they might wonder what it was doing; it might not seem to be getting anything done while using a lot of processor cycles.

[BravoV]

Does this bug traceable if it happened ? I mean in system log ?

The data leak occurs through speculated instructions which are never retired as part of the visible instruction stream.  This is why monitoring for access violations will not reveal anything.  As far as the CPU is concerned, they never happened. 

If someone profiled the code they might wonder what it was doing; it might not seem to be getting anything done while using a lot of processor cycles.

As I suspected, if the above scenario happened, it will be untraceable crime isn't it ?

I guess even the authority will have a real problem proofing the crime in the court.

[David Hess]

As I suspected, if the above scenario happened, it will be untraceable crime isn't it ?

I guess even the authority will have a real problem proofing the crime in the court.

People are usually caught through means other than technical so I doubt it will make a difference.  The perpetrator would be a former employee who stole confidential information and that would be enough.

[Mr. Scram]

Probably the best answer to this is to do all browsing in a virtual machine.

That said, the real issue here is that this has existed since 1995 and no security expert noticed it until now.  During that time it may well have been exploited by bad guys. There is no way of telling if it has.

When you think about it, if you forget to lock your house or car, the security issue doesn't arise when you realise you did so.  It arises when you walk away without locking it. Likewise, assuming this vuln hasn't been exploited in over 20 years of the computer being 'left unlocked' is naive. This is the fallacy behind the idea that patching and updating makes a computer secure. It is only marginally better than a placebo.

Especially as there are thousands of similar vulns in all operating systems, still unpatched.

Linux and MacOS are in principle no better then Windows in this respect, since they are all based on C, whose buffer overflow risk is the No1 cause of vulns. What is really needed is a completely new OS that ditches all of this bad code. 

The decision to use C instead of Pascal for the IBM PC, must rank as the single worst decision in the entire history of computing. That said, the really inexcusable thing is that C was allowed to become entrenched in the IT industry even after its security flaws became apparent. So deeply entrenched that it's now going to take the IT equivalent of D-Day to oust it. 

Virtual machines or sandboxing aren't effective in this case. That's pretty much the cause of all the consternation. Normally, you could assume that code run in a sandbox or VM could only touch its own userspace. Now it turns out that it could very well read data outside of its own area, breaking the barriers we rely upon for security. Data can leak between user and kernel, sandbox and kernel or VM and another VM.

Even though it's a complex attack, there's no doubt that malware makers are working on weaponizing it as we speak. It's likely that it will then be sold off to anyone willing to pay in a convenient package, so the smaller fish don't have to develop the complicated software themselves. Malware has unfortunately become a proper business and people have deep pockets to invest in new ways to make our lives a bit more difficult.

[dmills]

but would move the problem to the TLB (You would need to fall back it the TLB does not contain both possible target pages rather then loading a TLB entry!).

There are no current processors which speculatively execute both sides of a branch which Wikipedia calls "eager execution".  If they did, then branch prediction would not be necessary because every branch would be automatically predicted correctly 100% of the time in retrospect.

That is not quite what I was getting at, the question is not one of executing both sides of a branch, but "Could both conditions of this branch execute without causing a cache or TLB change before retirement?", execution has nothing to do with it, the question is will either condition of this branch change the cache or TLB state in a way that differs between the two branches. 

Of course thinking about it, even this does not really do it, because I can still use the timing differences between the speculation ok (Both things are in cache and TLB) case and the no speculation because one of these things is not in the cache or TLB to extract information, it is just another level of indirection!

Regards, Dan.

[Decoman]

And, somewhat related (to Intel and computer security):

"INTEL AMT SECURITY ISSUE LETS ATTACKERS BYPASS LOGIN CREDENTIALS IN CORPORATE LAPTOPS"
https://press.f-secure.com/2018/01/12/intel-amt-security-issue-lets-attackers-bypass-login-credentials-in-corporate-laptops/

"Intel AMT is a solution for remote access monitoring and maintenance of corporate-grade personal computers, created to allow IT departments or managed service providers to better control their device fleets. The technology, which is commonly found in corporate laptops, has been called out for security weaknesses in the past, but the pure simplicity of exploiting this particular issue sets it apart from previous instances. The weakness can be exploited in mere seconds without a single line of code."

"To exploit this, all an attacker needs to do is reboot or power up the target machine and press CTRL-P during bootup."

"Although the initial attack requires physical access, Sintonen explained that the speed with which it can be carried out makes it easily exploitable in a so-called “evil maid” scenario. “You leave your laptop in your hotel room while you go out for a drink. The attacker breaks into your room and configures your laptop in less than a minute, and now he or she can access your desktop when you use your laptop in the hotel WLAN."

"The issue affects most, if not all laptops that support Intel Management Engine / Intel AMT. It is unrelated to the recently disclosed Spectre and Meltdown vulnerabilities."

[bd139]

 

This should be turned off by default. First thing we do is kill AMT on our laptops fortunately.

[stj]

This should be turned off by default. First thing we do is kill AMT on our laptops fortunately.

unless your removing the module with a bios editor, i wouldnt assume it's "off"

and on that subject - [CRTL]-[P] anybody?!!
http://www.theregister.co.uk/2018/01/12/intel_amt_insecure/

[cdev]

The system is broken.

[stj]

The system is broken.

or the system is by design.

[timb]

The system is broken.

The BIOS’s closed.
The can’o’worms open.
Hackers ain’t got nothing to lose, they rollin’.
So good night cruel world, I’ll see you in the morning.

[paulca]

This may sound like paranoia but trust me it's not.  Governments have been building covert snooping backdoors into teleco hardware for years.  Why not domestic hardware.

[bd139]

Indeed. Cisco implants for example:

https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/

[Jeroen3]

There are cloud managed routers by Cicso. They don't even need to intercept the package.

[Marco]

If you don't have your own industry to manufacture your own telecom equipment you don't have security.

China has it right ... hell, as an European company scared of industrial espionage I'd trust Huawei over Cisco, they are more desperate for approval. The US is just so blatant in it's total disregard for its "allies", especially the non 5 eyes ones.

[Jeroen3]

There are a few European network gear companies though, Nokia, Mikrotik, AVM... Not enough.

[bd139]

I certainly wouldn't trust Huawei. NSA are targeting their hardware for implants.

Best approach for security is dumb switching, intelligent nodes, TLS with PFS or SSH between all nodes and assume that your entire network is insecure. Hardware encrypted disks with keys stored in TPM slows physical attacks down. Cold booting with a TPM is difficult if not impossible. Also some thermite filled plant pots and numerous tamper switches in the rack 

Any black box closed source appliance and you're SOL already otherwise. Can't win this battle with any closed source appliances. It's hard enough dealing with shit like ME / AMT.

Gonna get me a Z80 based X25 / TNC and use packet radio. That'll not have any implants in it

[paulca]

Indeed. Cisco implants for example:

https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/

That seems a targetted intercept and bug approach.

What I am talking about is "out of the factory" fitted with a covert channel.  Not mentioning the company, but while programming a front end management tool for a domestic broadband optical "OLT" 'head end' we were told there was one more interface, but we can't see it and not even the OS developers are allowed to see it or make it's presence known in diagnostics.  It is installed in hardware and the binary component that allows control over the link is provided to them.  The OS is not even allowed to show it's existence never mind if it's in use, but all units shipped must have it and it must be connected to a special link while in service.

All very cloak and dagger and the designers of the system didn't know much about what it actually did, except it was expected it could tap any of the optical interfaces and thus receive all data sent and received to all 64 or so connected premises on that port.

This was circa 2015.  A US company.

[bd139]

Oh nice. I'd be shitposting that all over the Internet if I got my hands on it.

Every nefarious fucker out there doing this sort of shit needs to watch their companies burn.