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

Meltdown Proof-of-Concept

github.com

Post reply on HN
Print view View original

11–20 of 187 posts

Re: Meltdown Proof-of-Concept

#11

Post by hannasanarion »

john_teller02 wrote: post #4

These two bugs (Meltdown and Spectr) are really very speculative things. It is like when human beings became aware of astroid orbits they thought that earth is in danger of being hit by one. Now that is indeed a theoritical possibility but what are the chances? These two bugs have been existent for 20 years and there is no known exploits of them. In the GitHub demos also they mention that the demos will work only if…

If you don't know the difference between the existence of an earthbound asteroid and the existence of people who write computer viruses, I don't know what to tell you.

Re: Meltdown Proof-of-Concept

#12

Post by K0nserv »

revelation wrote: post #10

The secret program confirms what others have seen, it's not so much "read any physical memory" as "read memory in cache"

> "read any physical memory" as "read memory in cache"

You can force values from any memory to affect the cache in a predictable manner which enables you to read all physical memory. See https://news.ycombinator.com/item?id=16108574 or read the paper yourself https://meltdownattack.com/meltdown.pdf

Re: Meltdown Proof-of-Concept

#13

Post by koolba »

K0nserv wrote: post #12
revelation wrote: post #10

The secret program confirms what others have seen, it's not so much "read any physical memory" as "read memory in cache"

> "read any physical memory" as "read memory in cache" You can force values from any memory to affect the cache in a predictable manner which enables you to read all physical memory. See https://news.ycombinator.com/item?id=16108574 or read the paper yourself https://meltdownattack.com/meltdown.pdf

> You can force any memory into the cache so yes it's is read any physical memory.

Is there a direct method for that or do you mean that you can repeatedly try reading memory addresses until the address that you want to access is actually in the cache prior to your access?

Re: Meltdown Proof-of-Concept

#14

Post by ehPReth »

runesoerensen wrote: post #3

The Project Zero bug report (with PoCs/timeline) was also made public a few minutes ago https://bugs.chromium.org/p/project-zero/issues/detail?id=12...

I wonder what happened to "This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public." Executive meddling?

Edit: Probably the 'extreme circumstances' bit mentioned in https://news.ycombinator.com/item?id=16108434

Re: Meltdown Proof-of-Concept

#15

Post by adjkant »

ehPReth wrote: post #14
runesoerensen wrote: post #3

The Project Zero bug report (with PoCs/timeline) was also made public a few minutes ago https://bugs.chromium.org/p/project-zero/issues/detail?id=12...

I wonder what happened to "This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public." Executive meddling? Edit: Probably the 'extreme circumstances' bit mentioned in https://news.ycombinator.com/item?id=16108434

I think for a bug this big it is pretty understandable. So far, it seems clear the actions of all involved were in a good spirit of responsible disclosure.

Re: Meltdown Proof-of-Concept

#16

Post by [deleted] »

K0nserv wrote: post #12
revelation wrote: post #10

The secret program confirms what others have seen, it's not so much "read any physical memory" as "read memory in cache"

> "read any physical memory" as "read memory in cache" You can force values from any memory to affect the cache in a predictable manner which enables you to read all physical memory. See https://news.ycombinator.com/item?id=16108574 or read the paper yourself https://meltdownattack.com/meltdown.pdf

[deleted]

Re: Meltdown Proof-of-Concept

#17

Post by ehPReth »

adjkant wrote: post #15
ehPReth wrote: post #14

Earlier quoted context omitted.

I wonder what happened to "This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public." Executive meddling? Edit: Probably the 'extreme circumstances' bit mentioned in https://news.ycombinator.com/item?id=16108434

I think for a bug this big it is pretty understandable. So far, it seems clear the actions of all involved were in a good spirit of responsible disclosure.

Hmm, wasn't there that Microsoft Windows(?) bug that they derestricted before the patch was out? Memory escapes me at the moment. I thought it somewhat cemented/promoted their adherence to 90 days regardless of patch availability.

Re: Meltdown Proof-of-Concept

#18

Post by K0nserv »

koolba wrote: post #13
K0nserv wrote: post #12

Earlier quoted context omitted.

> "read any physical memory" as "read memory in cache" You can force values from any memory to affect the cache in a predictable manner which enables you to read all physical memory. See https://news.ycombinator.com/item?id=16108574 or read the paper yourself https://meltdownattack.com/meltdown.pdf

> You can force any memory into the cache so yes it's is read any physical memory. Is there a direct method for that or do you mean that you can repeatedly try reading memory addresses until the address that you want to access is actually in the cache prior to your access?

The exploit is based on reading values that you shouldn't be allowed to access in speculative execution and then using the returned values to create persistent changes in the cache(they persist even after the CPU detects your illegal access). Those persistent changes are then read via a side channel attack.

So you read any address you want speculatively and then use the result to prime the cache in such a way that you can determine what the value you read speculatively was. This works because modern operating systems map kernel space addresses into normal processes and to make syscalls faster.

I'd recommend reading the paper[0], it's fascinating stuff.

https://meltdownattack.com/meltdown.pdf

Re: Meltdown Proof-of-Concept

#19

Post by kodablah »

diyseguy wrote: post #9
kodablah wrote: post #2

This was the GitHub repo mentioned in the meltdown.pdf that was 404'ing until now. We have native Spectre replication code too. What still seems to be elusive is the JS-based Spectre impl (probably waiting at least for Chrome 64, though I confirmed via https://jsfiddle.net/5n6poqjd/ that Chrome seems to have disabled SharedArrayBuffer even before they said they would which wasn't the case a few days ago).

This is the closest thing to a javascript implementation I have seen: http://xlab.tencent.com/special/spectre/js/check.js from: http://xlab.tencent.com/special/spectre/spectre_check.html

Nice. Reviewing the code, it is as the PDF said where they are just constantly incrementing a val in the shared buffer to get a fairly precise timer. But it seems to be using the timing to determine across 256 indices (99 tries to check) to check cache hits. So just removing this timer is not enough, it just increases the surface area of bytes you have to read and sift through to see if you have other mem? Anyone have a writeup on this?

Re: Meltdown Proof-of-Concept

#20

Post by ctrlrsf »

koolba wrote: post #13
K0nserv wrote: post #12

Earlier quoted context omitted.

> "read any physical memory" as "read memory in cache" You can force values from any memory to affect the cache in a predictable manner which enables you to read all physical memory. See https://news.ycombinator.com/item?id=16108574 or read the paper yourself https://meltdownattack.com/meltdown.pdf

> You can force any memory into the cache so yes it's is read any physical memory. Is there a direct method for that or do you mean that you can repeatedly try reading memory addresses until the address that you want to access is actually in the cache prior to your access?

It doesn’t force memory into cache directly. It determines values of bytes in memory by using the byte as a multiplier to an offset in memory. To determine byte value you can check all the offset combinations to see which was cached. Details in the meltdown paper.
Post reply on HN