Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The mysterious case of the Linux Page Table Isolation patches

pythonsweetness.tumblr.com

Post reply on HN
Print view View original

121–130 of 264 posts

Re: The mysterious case of the Linux Page Table Isolation patches

#121

Post by Aissen »

Guess: it is not directly related to RowHammer/DRAM, and is purely a CPU issue. Maybe PageFault timing info leaks or cache timing, like this pwnie award winner: http://www.cs.vu.nl/~giuffrida/papers/anc-ndss-2017.pdf

If this last one can defeat ASLR, imagine leaking bit by bit from a co-hosted VM, to extract secrets of other cloud customers… This is the reason anyone serious about cloud security will reserve instances so that they won't share physical hardware with other customers (think EC2 dedicated instances).

Re: The mysterious case of the Linux Page Table Isolation patches

#122

Post by saas_co_de »

yeukhon wrote: post #115
saas_co_de wrote: post #75

Earlier quoted context omitted.

Once there is disclosure then 100% of users can make the choice to take appropriate mitigation steps. Prior to disclosure there will always be the possibility that some users are being exploited without their knowledge. Therefore disclosure always improves the situation by giving those who could have been exploited without their knowledge the choice to take mitigation steps. All of the "responsible disclosure" nonsen…

> Once there is disclosure then 100% of users can make the choice to take appropriate mitigation steps. And what are those mitigation steps?

Depends on the exploit, but all exploits can be mitigated by stopping your use of the exploited product. That is what companies don't want to happen so they would prefer to sacrifice their users' security and wait until they have a fix before the exploit is disclosed.

Re: The mysterious case of the Linux Page Table Isolation patches

#123

Post by snom380 »

vitaliyf wrote: post #113

This may or may not be related, but there is a Xen advisory embargoed until Thursday (see https://xenbits.xen.org/xsa/ ) and I am aware of at least one VM provider who scheduled emergency VM reboots across their entire fleet this week because the issue cannot be addressed through hot-patching.

I got around 10% of our Xen instances scheduled for reboot on Jan 4th, mostly long running instances. It's the first time I've seen that many instances scheduled at once.

Re: The mysterious case of the Linux Page Table Isolation patches

#124

Post by brazzledazzle »

jstanley wrote: post #59
avh02 wrote: post #39

Earlier quoted context omitted.

No, but they prevent everybody with ill-intent from exploiting the issue en-masse

No they don't. They prevent everybody with ill intent who doesn't already know about it from finding out about it from the guys without ill intent . That's all.

The reality is that there's a group you're excluding from consideration and I don't think it's unreasonable to conclude that embargoes keeps every random "hacker" from taking advantage of it in a packaged form. Being vulnerable to the minority population that can and would take advantage of it vs. anyone that would is a valid consideration and shouldn't be dismissed so casually.

Re: The mysterious case of the Linux Page Table Isolation patches

#125

Post by saas_co_de »

avh02 wrote: post #104
saas_co_de wrote: post #87

Earlier quoted context omitted.

Exactly. This is just some random nerd. There are people all over the world whose full time job it is to track open source projects to develop exploits.

and when script kiddies get wind that there is something potentially disastrous in the open, it can be exploited 10 times harder, that's all I'm saying. I understand (and agree) that the system admins/owners should also be able to mitigate through knowledge, but it's a dilemma that I think is better resolved by the other solution (in this case it's apparently a complex issue, but history has shown that there are surp…

No "script kiddies" can write exploit code for something on this level.

This guy is not releasing an exploit implementation, he is just pointing to the existence of a potential exploit that has a patch in development. He can't even figure out exactly what it is.

The only people who would be able to code this exploit would be the ones who already figured it out before this guy.

Re: The mysterious case of the Linux Page Table Isolation patches

#126

Post by pkaye »

blattimwind wrote: post #109
tzs wrote: post #64

Earlier quoted context omitted.

Almost everything I've seen on error rates from radioactive decay and cosmic particles has been on servers in data centers. I wonder if home systems are equally vulnerable, or if there is something about data center system design or facilities that make them more susceptible? I ask because I had a couple of home desktop Linux boxes once, without ECC RAM, that were running as lightly loaded servers. I ran a background…

> I wonder if home systems are equally vulnerable, or if there is something about data center system design or facilities that make them more susceptible? I was told once that today's concrete has a much higher background radiation than brick and mortar from before the 50s. There is also more steel in data centres. However, I'm not at all sure if background radiation of building materials is even in the right order o…

I think you need high energy radiation like cosmic rays from space to create problems. So those at higher elevation are at more risk. Heavy material like concrete may block this radiation.

Re: The mysterious case of the Linux Page Table Isolation patches

#127

Post by brazzledazzle »

saas_co_de wrote: post #122
yeukhon wrote: post #115

Earlier quoted context omitted.

> Once there is disclosure then 100% of users can make the choice to take appropriate mitigation steps. And what are those mitigation steps?

Depends on the exploit, but all exploits can be mitigated by stopping your use of the exploited product. That is what companies don't want to happen so they would prefer to sacrifice their users' security and wait until they have a fix before the exploit is disclosed.

In this specific scenario what's the mitigation for cloud customers? Or even cloud providers? A customer can't migrate all of their infrastructure before a packaged exploit can be distributed. A provider can't dedicate hardware for every single customer. Let's be realistic here.

Re: The mysterious case of the Linux Page Table Isolation patches

#128

Post by damnyou »

saas_co_de wrote: post #11
tbrownaw wrote: post #2

"Hey, I think I noticed a horrible horrible embargoed security bug. I know, I should do my best to pole holes in the embargo early!"

Embargos do not make you secure. If the bug exists the only safe assumption is that it is already being exploited. The faster the information gets out the better.

People are generally willing to make the slightly less safe assumptions that targeted and mass attacks are different threat models, and that coordinated disclosure might not help against the former but does help against the latter.

People are willing to make these assumption because they correspond closer to reality.

Re: The mysterious case of the Linux Page Table Isolation patches

#130

Post by dang »

jtchang wrote: post #84
userbinator wrote: post #20

IMHO, with RowHammer, the hardware is broken and it will continue to be broken until users complain enough --- maybe to the point of absolutely refusing to buy --- that the manufacturers and designers stop thinking "works 99.9999999999% of the time" is good enough: https://news.ycombinator.com/item?id=12410274

Umm this is very shortsighted and absolutely trash. There are many types of users and some don't care if it fails in a blue moon. Hell 99% might be good enough if the price was right.

Please don't call names in arguments here. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html
Post reply on HN