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

131–140 of 187 posts

Re: Meltdown Proof-of-Concept

#131

Post by white-flame »

Terr_ wrote: post #100
white-flame wrote: post #76

Earlier quoted context omitted.

No, creating a block of machine code bytes to execute would be a privileged operation. All code would run through a privileged CPU-specific compiler first, and there'd be no way to run raw machine code bytes otherwise. If there are bugs that can be exposed through various machine code patterns, the compiler can centralize the restrictions of what may be executed, enforce runtime checks, or prevent certain instruction…

> no way to run raw machine code bytes otherwise [...] restrictions of what may be executed, enforce runtime checks, or prevent certain instructions from being used at all [...] everything optimized for your environment better, allow much better compatibility across systems and prevent entire classes of privilege escalation issues. So... basically re-inventing Java? :) "Raw machine code bytes" aren't distributed but…

Well, to me Java is still new tech. ;-) But yes, it's certainly a reasonable sampling into non-machine code distribution, and enforcement of security rules when actually running/JITting the code, as were some mainframe developments before then.

Of course, Java certainly does have some higher level weaknesses as in the introspection API kerfuffle a while back, and is too locked into its Object Obsessed design for it to be a truly general purpose object code format.

Re: Meltdown Proof-of-Concept

#132

Post by dingo_bat »

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

Interesting that Firefox on my phone is shown vulnerable but Samsung browser is not.

Re: Meltdown Proof-of-Concept

#133

Post by Skunkleton »

logfromblammo wrote: post #107
Skunkleton wrote: post #74

Earlier quoted context omitted.

> The only way to make it make sense is add that we also know there is an entire spacefaring group of mercenaries whose entire hobby and/or job is deliberately throwing asteroids in Earths general direction. Maybe there is, but they are hilariously incompetent?

Nah, they're really far away, and there's an accumulated round-off error in their distance conversion between bloits (used by the client) and metrons (used by the subcontractor), so they're shooting at a target a quarter of a light-year away, and won't realize it for another 500 years.

Bureaucracy to the rescue!

Re: Meltdown Proof-of-Concept

#134

Post by rstuart4133 »

Does anyone have a link to Linux PoC code for Meltdown that uses speculative branch execution?

I've only seen two implementations: one based just doing the access to kernel memory, catching the SIGSEGV, and then probing the cache. Obviously that could be closed by the kernel flushing the cache prior handing control back t user space after SIGSEGV. Doing that would have no impact on normal programs.

The second is by exploiting a bug in Intel's transactional memory implementation. But I assume Intel could turn that feature off as they have done so in the past. Since bugger all programs use it doing so wouldn't have much impact.

Which means the approach being take now is done purely to kill the speculative branch method (ie, Spectre pointed at the kernel). The authors say it should work, but also say they could not make it work. I haven't been able to find working any PoC for my Linux machines.

So my question is: is there any out there?

Re: Meltdown Proof-of-Concept

#135

Post by rstuart4133 »

rstuart4133 wrote: post #134

Does anyone have a link to Linux PoC code for Meltdown that uses speculative branch execution? I've only seen two implementations: one based just doing the access to kernel memory, catching the SIGSEGV, and then probing the cache. Obviously that could be closed by the kernel flushing the cache prior handing control back t user space after SIGSEGV. Doing that would have no impact on normal programs. The second is by e…

Never mind: https://bugs.chromium.org/p/project-zero/issues/detail?id=12...

Re: Meltdown Proof-of-Concept

#136

Post by ahh »

tzs wrote: post #105
white-flame wrote: post #68

Earlier quoted context omitted.

To my understanding, the memory subsystem is fetching a byte in parallel with access permission checks. If the byte is discarded due to mis-speculation, then the result of the permission check is ignored, but the cache is still in an updated state. I believe one solution would be to put permission checks before the memory access, which would add serialized latency to all memory access. Another would be to have the sp…

> I believe one solution would be to put permission checks before the memory access, which would add serialized latency to all memory access. I don't see why that would have to add latency to all (or any) memory access. The addresses generated by programs (except in real mode, when everything has access to everything anyway so we don't care about these issues then) are virtual addresses, so they have to be translated…

> I don't see why that would have to add latency to all (or any) memory access. The addresses generated by programs (except in real mode, when everything has access to everything anyway so we don't care about these issues then) are virtual addresses, so they have to be translated to get the actual memory address.

L1 caches are generally virtually indexed for exactly this reason: to allow a L1 cache read to happen in parallel with the TLB lookup. (They're also usually, I believe, physically tagged, so we have to check for collisions at some point, but making sure there's no side channel information at that point is, obviously given recent events, hard.)

Re: Meltdown Proof-of-Concept

#137

Post by abritinthebay »

Skunkleton wrote: post #74
abritinthebay wrote: post #30

Earlier quoted context omitted.

I think you're being harshly down-voted without people explaining why. For a start - this is hardly a remote possibility when we already have proof of concepts like the linked repo. Secondly - your analogy makes no sense. The only way to make it make sense is add that we also know there is an entire spacefaring group of mercenaries whose entire hobby and/or job is deliberately throwing asteroids in Earths general dir…

> The only way to make it make sense is add that we also know there is an entire spacefaring group of mercenaries whose entire hobby and/or job is deliberately throwing asteroids in Earths general direction. Maybe there is, but they are hilariously incompetent?

This sounds like a new BlackAdder pitch...

"Sir, I have a cunning plan" "Does it involve that legion of rabid space weasels again?" "... maybe."

Re: Meltdown Proof-of-Concept

#138

Post by ridgeguy »

K0nserv wrote: post #93
Acen wrote: post #41

MacOS is yet to have a patch for 10.12.6 (Sierra) to resolve this.

It is patched on Sierra, this was part of the 2017-002[0] security update on the 6th of December. 0: https://support.apple.com/en-gb/HT208331

That link shows Meltdown in reference only to High Sierra, not Sierra. What am I missing?

Re: Meltdown Proof-of-Concept

#139

Post by _wmd »

tptacek wrote: post #128
krylon wrote: post #79

Earlier quoted context omitted.

> by the way, that PoC was intense. Makes you wonder if the NSA knew about it all along :) Colin Percival found a very similar issue with Intel's implementation of SMT on the Pentium 4 in 2005: http://www.daemonology.net/papers/htt.pdf So the general idea of using timing attacks against the cache to leak memory has been known for at least that long. In 2016, two researchers from the University of Graz gave a talk at…

Can I put a plug in again for how fucking cool the Meltdown and Spectre attacks are? They're much more interesting than just cache timing, which as you note have been well-known for at least a decade (and much earlier in the covert channel literature). Unlike "vanilla" cache-timing attacks: * Meltdown and Spectre involve transient instructions, instructions that from the perspective of the ISA never actually run . *…

There's no reason to invent new terminology for speculative execution. Also, the mapping between the variety of CPU caches and real memory has been known imperfect since the beginning of time.

But meanwhile, yes, can definitely agree how fucking cool it all is

Re: Meltdown Proof-of-Concept

#140

Post by che_shirecat »

garblegarble wrote: post #118
che_shirecat wrote: post #34

Earlier quoted context omitted.

#1 - realtime password input - https://www.youtube.com/watch?v=yTpXqyRYcBM #2 - physical memory leak - https://www.youtube.com/watch?v=kn0FopiF16o the videos aren't very long, someone should compress it to <10mb as an animated gif and do a pull request to put it in the README

>the videos aren't very long, someone should compress it to There's no need to use an awful format like gif, just embed an efficiently compressed video file with the tag

I completely agree with the sentiment, however github currently does not support embedded video in markdown [1]

Animated gifs do work when embedded, but need to be [1] https://stackoverflow.com/questions/4279611/how-to-embed-a-v...

[2] https://stackoverflow.com/a/46701929

Post reply on HN