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) by q.kontinuum on Wednesday July 29 2015, @05:19AM
Actually, the operating system should allow me to do exactly that, and guarantee that only the user-account running the executable is at risk. That is the very basic concept of any multi-user operating system. (BTW: When you want to send me the binary, make sure it is wine-compatible...)
This is only a minor point compared to the previous one, but there are many web-based services requiring JavaScript, and many workplaces depending on those web-based services. I'm not 100% sure and not willing to go through all these services just to try, but IIRC, I had to enable JavaScript to use Gerrit, Jenkins, JIRA, Confluence, Webmail and many other services essential for my daily work. This might be mitigated by switching to other services, but for now, this is still a very serious problem.
Registered IRC nick on chat.soylentnews.org: qkontinuum
(Score: 0) by Anonymous Coward on Wednesday July 29 2015, @09:05AM
Why is webmail essential to your daily work? What's wrong with SMTP/IMAP and a dedicated mail application? I consider webmail a crutch for situations where no proper mail application is available.
(Score: 2) by q.kontinuum on Wednesday July 29 2015, @10:55AM
Because the webmail I have to use is outlook.com, with calendar etc. I prefer to use Linux instead of Windows, and didn't yet find a good, free outlook-alternative. I could use Windows as well, but I don't like it, and in regards of security I feel it would kind of defeat the purpose...
Registered IRC nick on chat.soylentnews.org: qkontinuum
(Score: 0) by Anonymous Coward on Wednesday July 29 2015, @03:38PM
Really, you failed to find Thunderbird? You also failed to find the Lightning and Exchange EWS add ons for Thunderbird?
My goodness you must suck at your job
(Score: 2) by q.kontinuum on Wednesday July 29 2015, @04:21PM
No, I used it temporarily. Only the plugins didn't work as expected, Thunderbird kept eating 100%CPU and kept crashing once twice a day.
Registered IRC nick on chat.soylentnews.org: qkontinuum
(Score: 1, Insightful) by Anonymous Coward on Wednesday July 29 2015, @04:31PM
The problem with javascript is the laziness of developers in designing sites that require it to provide basic services to the site visitor. I browse SN all the time with JavaScript disabled, and the site functions.
Heck, even Amazon is somewhat functional with JavaScript disabled.
For most web developers, everything is a nail and JavaScript is the hammer.
It is poor design that an article or image link to one's site does not render the article or image unless JavaScript is enabled.
Design and implementation should have focus on what can be achieved with plain HTML and CSS, with JavaScript only done to enhance and optimize the experience. This approach actually tends to make the site easier to maintain due to reduced complexity of lots of JavaScript. I.e. What may take more time in the design phase of providing a non-JavaScript-enabled functional site, is saved in the maintenance costs of maintaining a large JavaScript code base, which still requires browser-specifc handling despite the state of current standards. There is also the benefit of making the site more accesible to the myriad of devices and user types.