SoylentNews is people
SoylentNews
from the for-those-who-ask-for-javascript dept.
A very interesting attack was unveiled in Friday, 24 June by Daniel Gruss, Clémentine Maurice, Stefan Mangard. Maybe the Rowhammer is the next Hearthbleed, or worse?
As DRAM has been scaling to increase in density, the cells are less isolated from each other. Recent studies have found that repeated accesses to DRAM rows can cause random bit flips in an adjacent row, resulting in the so called Rowhammer bug. This bug has already been exploited to gain root privileges and to evade a sandbox, showing the severity of faulting single bits for security. However, these exploits are written in native code and use special instructions to flush data from the cache.
In this paper we present Rowhammer.js, a JavaScript-based implementation of the Rowhammer attack. Our attack uses an eviction strategy found by a generic algorithm that improves the eviction rate compared to existing eviction strategies from 95.2% to 99.99%. Rowhammer.js is the first remote software-induced hardware-fault attack. In contrast to other fault attacks it does not require physical access to the machine, or the execution of native code or access to special instructions. As JavaScript-based fault attacks can be performed on millions of users stealthily and simultaneously, we propose countermeasures that can be implemented immediately.
http://arxiv.org/abs/1507.06955
Full report can be found here (PDF)
(Score: 2, Informative) by Anonymous Coward on Wednesday July 29 2015, @01:16AM
Just don't allow user processes to trigger their own clflushes.
Don't execute arbitrary code.
Compile apps for P4 arches, or with clflush optimized out.
This bug was only a problem because Intel in its infinite malice (incompetence? Depends on who you ask) pushed this into the Pentium 4s way back when despite people indicating this was a possibility.
Turns out they were right. Nothing to see here.
(Score: 1, Informative) by Anonymous Coward on Wednesday July 29 2015, @01:21AM
*less than p4*
Dumb html filtering. Plain Old Text mode should pre tag its contents.
(Score: 1) by ese002 on Wednesday July 29 2015, @01:29AM
This is a hardware bug. I don't agree that the problem is user code cache flushes. That just makes it exploitable. Even without deliberate cache flushes, crosstalk can cause random memory corruption. If software doing allowed operations can cause hardware to fail, even if it is improbable, then that is a serious hardware bug and the machine becomes unusable for any tasks where correct computation is actually important.
(Score: 4, Interesting) by Runaway1956 on Wednesday July 29 2015, @01:37AM
I wonder if this exploit works on ECC memory.
I've built my rigs around Opteron processors for years now. And, those rigs are built with ECC memory. I kinda doubt that this exploit is going to get very far when there is a dedicated chip ensuring that data is not corrupted.
# inxi -m
Memory: Array-1 capacity: 32 GB (est) devices: 16 EC: Single-bit ECC
Device-1: DIMM0 size: 2 GB speed: 333 MHz type: DDR2
Device-2: DIMM1 size: 2 GB speed: 333 MHz type: DDR2
Device-3: DIMM2 size: 2 GB speed: 333 MHz type: DDR2
Device-4: DIMM3 size: 2 GB speed: 333 MHz type: DDR2
Device-5: DIMM4 size: 2 GB speed: 333 MHz type: DDR2
Device-6: DIMM5 size: 2 GB speed: 333 MHz type: DDR2
Device-7: DIMM6 size: No Module Installed type: N/A
Device-8: DIMM7 size: No Module Installed type: N/A
Device-9: DIMM8 size: 2 GB speed: 333 MHz type: DDR2
Device-10: DIMM9 size: 2 GB speed: 333 MHz type: DDR2
Device-11: DIMM10 size: 2 GB speed: 333 MHz type: DDR2
Device-12: DIMM11 size: 2 GB speed: 333 MHz type: DDR2
Device-13: DIMM12 size: 2 GB speed: 333 MHz type: DDR2
Device-14: DIMM13 size: 2 GB speed: 333 MHz type: DDR2
Device-15: DIMM14 size: No Module Installed type: N/A
Device-16: DIMM15 size: No Module Installed type: N/A
(Score: -1, Troll) by Anonymous Coward on Wednesday July 29 2015, @01:44AM
Sorry, I stopped reading at "my rigs" because you might as well just declare publicly that you are an asshole. If you use a word like "rigs" then you're either a trucker or an asshole, and you're an asshole, right?
(Score: 2, Insightful) by Anonymous Coward on Wednesday July 29 2015, @01:48AM
Perhaps you're the asshole for complaining about a word choice.
(Score: -1, Troll) by Anonymous Coward on Wednesday July 29 2015, @01:51AM
Assholes are just the right size to fit my cock in.
(Score: 1, Troll) by aristarchus on Wednesday July 29 2015, @07:14AM
No, Runaway is a trucker. Admitted as much some time ago. And his posts match the stereotype. Of course, being a trucker does not reduce the odds of being an asshole, in fact, it increases it exponentially. Rubber duck is long dead, and Kris only stars in Black Vampire movies now. Silver bullets? Or silver-iodide-shine-in-the-dark bullets? Javascript based attacks. As Switch said, just before she died, "Not like this! Not like this!"
(Score: 0) by Anonymous Coward on Wednesday July 29 2015, @03:31PM
1st Gear
vrrmmm
2nd gear
Vrrrm
Kill some hooker
3rd gear
vrrmm
4th gear
vrrmmm
hit a pedestrian
5th gear
vrrm
6th gear
vrrm
Kill another hooker
TOP GEAR!!
(Score: 2) by albert on Wednesday July 29 2015, @03:40AM
Getting it to work is certainly harder, but not by a great deal. Even without the more advanced attack methods (directed results) you have only cut down the success probability by a very small factor.
ECC is worthwhile I think, but don't imagine you are safe.
(Score: 3, Insightful) by zeigerpuppy on Wednesday July 29 2015, @05:43AM
I doubt this attack would work at all against ECC,
A single bit flip is detected and more than that causes a RAM error,
It's very unlikely to get multiple flips that aren't detected.
(Score: 2) by opinionated_science on Wednesday July 29 2015, @01:40PM
inxi -m
Memory: Placeholder: Feature not yet developed
I get this. What am I missing?
(Score: 3, Informative) by Runaway1956 on Wednesday July 29 2015, @03:00PM
Maybe you're using an outdated version?
# inxi --version
inxi 2.2.26-00 (2015-07-06)
If your inxi is up to date, then you are possibly missing some dependency. Then again, it may be a glitch in your OS - I know that inxi couldn't get uptime for awhile after systemd was instituted. Now it works again, so that particular glitch has been addressed.
You might want to address any glitches on the forum - http://techpatterns.com/forums/index.php [techpatterns.com] The top two subforums are dedicated to the inxi-related scripts.
(Score: 2) by opinionated_science on Wednesday July 29 2015, @04:22PM
thanks! I grabbed the latest version from svn, though the debian version is a bit old.
Works fine for me now. Very cool tool.
(Score: 2) by q.kontinuum on Wednesday July 29 2015, @05:12AM
This bug defeats the hardware-backed security concepts of the PC, thus also defeating the the operating system security measures depending on the hardware. It also defeats the sandbox-security-model of the javascript interpreter. Your recommendations would even render an MS DOS computer secure, but also pretty unusable. If you consider this "mitigatable", you could also propose to stop using computers altogether.
I do use NoScript for my private purposes already, but that is only supposed to protect the data of the same user. Protection of other users data or from other users attack on the same system is the task of the OS.
Registered IRC nick on chat.soylentnews.org: qkontinuum
(Score: 2, Insightful) by chrysosphinx on Wednesday July 29 2015, @06:45AM
Don't execute arbitrary code.
Your advise is worthless since it blindly ignores ancient fundamental truth: Data is Code and Code is Data.
The real problem is: hardware which cannot be trusted.
(Score: 1) by anubi on Wednesday July 29 2015, @08:22AM
I beg to differ with you about data and code.
When I open a text file, I have no intention of executing it. I just want to display the data on the screen as its ASCII equivalent. The furthest stretch of the imagination is to consider a line feed and carriage return as cursor placement instructions and the end of file sentinel stopping the display.
The first malware I encountered was known at the time as an "ANSI bomb". This was the result of mixing code and data. It was shown to me right then and there that mixing executables in along with the data was a terrible idea.
You do not know just how bad I was hoping the Linux guys would come up with a HTML equivalent of a text editor. Safely read anything. HTML tags would direct streams of data to the proper interpreter... and have it simple. Standard font and only standard multimedia files for images, audio, and video - using thoroughly understood codecs.
Sure, the thing may be useless at first, but if people adopted it just so they did not have to constantly virus-scan their machine, businesses would be forced to comply to it or risk getting the following message presented to their customer....
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 0) by Anonymous Coward on Wednesday July 29 2015, @03:33PM
But data is code and code is data; all it needs is a chmod +x