Intel bug incoming.

Beastie7 said:
Very concerning times with these hardware exploits. All I can say is.. this is going to turn out well for AMD.
Click to expand...
MarcoB said:
Well the ceo of Intel sold a lot of his stock on nov. 29th. So that transaction will be investigated I guess. And 2018 will be a good year for AMD.
Click to expand...
Highly unlikely.

What is most likely going to happen (so I think, hope to be proven wrong) is that in roughly 2 months time everyone will have forgotten all about it. "Some" operating systems(?) will even have slowed down their processing in order to mimic an actual patch and everyone will continue on and no one will bother anymore.

See: I see resemblances with an open source mess up. Debian OpenSSL disaster anyone? Where a package maintainer knowingly and willingly messed up and basically broke OpenSSL to such extends that some ISP's (GoDaddy comes to mind) decided to revoke ALL Linux based certificates issues in the past years and either refund or rebuild the certs).

In an open source community I would have expected that moron to get fried and thrown out of the project. Not necessarily as a public spectacle but at least have him fess up for his incompetence. But to my knowledge none of that happened. He simply get doing his thing as if nothing had happened. Yaaay.

If that's how things work within the world of open source do you really expect a different result in the real world?

I sure don't (unfortunately).
 
Avernar said:
I don't believe that the caches other than the TLB are flushed. With the kernel no longer in the page tables the speculative load bug would not be able to modify the caches with kernel data anymore.

A a TLB miss requires 4 extra memory access for a total of 5 in 64-bit long mode for a 4K page. That's why this hurts performance so much.
Click to expand...

The main CPU cache is probably not flushed, but because the physical addresses are different, there will be a whole slew of cache misses until it is populated with the new data. So, in effect, the cache is flushed. However, to mitigate the slowdown, one could preload the cache with the new data. I can see a fundamental architecture change in the way that x86 works which may break backwards compatibility with older software. One other thing to consider too is that CPUs have different instruction and data caches. I could see how Intel would not be doing security checks for data already in the cache.
 
So my impression for now:
This speculative execution exploit feature permits interested people/programs to probe memory addresses.
The timing then reveals whether a particular virtual memory address block actually is mapped or not.

This cool Intel processor feature enables one to do this without causing unwanted exceptions.

I am still reading the Meltdown paper.
Imho an average kernel memory read data rate of about 1/2 MB/sec is not bad.

If the kernel is one big chunk of data and not many small ones sprayed over the address space, then I guess this could be the standard approach:

1. scan the virtual address space with increments of about half kernel size.
2. as soon as mapped memory has been found, find its start/end addresses
3. Finally walk through the kernel memory and retrieve the interesting things (accounts, certs, ...)
 
Now that more information has come to light about the bug, this definitely has to do with speculative execution. What I have found out this: An attacker can use the time it takes the CPU to execute a speculative set of instructions before it is known if a branch is to be taken or not to find out where the kernel memory is in the process address space. And the bug is actually more serious than that. By using this technique, an attacker can actually read kernel memory, which contains all sorts of useful information. They can even use this attack to read memory from a different process, breaking process isolation. So yeah, this is a real nasty bug.

Intel's statement is a nice piece of work. They are trying to say that other CPU vendors have the same issue. ARM, for it's credit, has stated that some of their CPUs are affected by this bug as well. AMD, which has been pointed out on here before, is immune to this type of attack, although Intel is implying that they are not immune. So it looks to me like Intel is trying to say everyone has this flaw, even when some do not, so they don't stink so bad.
 
Snurg said:
So my impression for now:
1. scan the virtual address space with increments of about half kernel size.
2. as soon as mapped memory has been found, find its start/end addresses
3. Finally walk through the kernel memory and retrieve the interesting things (accounts, certs, ...)
Click to expand...

In effect, chmod +r /dev/kmem is just as effective.
 
Maelstorm said:
although Intel is implying that they are not immune
Click to expand...
AMD is vulnerable to only 1 of the 3 attacks. The one that needs the PTI fix, which is the one with the big performance hit, is not it. And so far only FX and the APU chips are shown to be vulnerable to that one.

https://mobile.twitter.com/ryanshrout/status/948683677244018689

Number 3 is the one that required the PTI fix. But yeah, Intel is implying that AMD will be hit just a bad which is far from the truth.
 
Maelstorm said:
In effect, chmod +r /dev/kmem is just as effective.
Click to expand...
I wonder whether Microsoft will make an exception and issue a security fix for discontinued Windows XP and 7, as they did when there was this thing which allowed to take over Windows PCs with a single IP packet.

Regarding the Intel press release, they are talking of an embargo end next week.
I wonder whether that was their original plan, as several posts like this Xen advisory page indicate that the embargo will end today at midnight.
As I do not believe that, for example, the Xen team, would break one-sidedly the embargo appointment, I conclude that originally Jan 4th was the planned date to lift the embargo.

Thus I get the impression that Intel, for some reason, apparently decided to postpone the embargo lift.
But, why?

Attempt to save face by getting some more time to calm waves until the broad public has lost the interest?
Or, has it turned out that the thing is in fact even worse?
(Just had to think of the Fukushima nuclear catastrophe, where Tepco admitted the obvious only months later, that the cores have molten down?
 
lebarondemerde said:
I feel it is more like to find a way to also deep imply AMD in the thing.
Click to expand...
I have a similiar feeling.
What wonders me is that there is no official AMD press release yet.
That might be related to the fact that the Google project zero team identified a bounds checking flaw (thanks Avernar for the link) in the AMD processors (which can be fixed, with quasi zero impact on performance).
The only AMD message was from an AMD employee. And AMD always could say, his statement was not official and not authorized. Thus AMD is not "fully clean", either.

Admittedly, compared to the severity of what they found on Intel processors, this AMD bug is (almost) nothing.
But, will the broad public understand that?

Edit: At the end of the ProjectZero report there is a link provided by AMD. This is official, but quiet... no press release or such.
 
Interestingly, RHEL does imply IBM in the thing too, in HERE.

Btw, #freebsd and #freebsd-social are super hot on the subject all day long.
 
So the bug is reported to Intel, AMD and ARM in the summer. Apple fixes it in December; no other OSes have fixes yet. It becomes public knowledge on January 2nd, and on January 3rd Intel claims that (a) it is not a problem anyway, and (b) AMD and ARM have the same problem. There are no known exploits of it.

That reminds me of two jokes. The first one is from the 80s: If in January an American scientist invents a new semiconductor device in Silicon Valley, then in February the Pravda will publish that it was already invented 30 years ago by Comrade Markov; in March citizens committee's form in Germany to protest the environmental impact of the new technology, and in April the first products based on the idea are shipped by the Japanese.

Second one: A guy is in court, being sued to pay damages for having broken an earthenware jug he had borrowed. His defenses are threefold: First, that the jug isn't actually broken at all. Second, that the jug was already broken when he borrowed it. Third, that it wasn't his fault that the jug fell down and broke.
 
Now the Xen team released a report.
A few quotes:
This vulnerability was originally scheduled to be made public on 9
January. It was accelerated at the request of the discloser due to
one of the issues being made public.
Click to expand...
We believe that ARM is affected, but unfortunately due to the
accelerated schedule, we haven't been able to get concrete input from
ARM. We are asking ARM and will publish more information when it is
available.
Click to expand...
 
You must log in or register to reply here.
Back
Top