Dust off that R.E.M. record: this is gonna hurt.
February 15, 2017 12:09 AM Subscribe
It turns out ASLR (address space layout randomization) can be universally defeated. By javascript. Running in a browser. This is likely to greatly increase the number of javascript exploits in the coming days. In all browsers, on all systems. Arstechnica has an end-of-the-world article here.
There is some good news: browser developers can take some steps to mitigate against the attack. The authors of the exploit worked with Apple to harden Safari somewhat against the exploit; that was the focus of the recent Safari upgrade.
There is some good news: browser developers can take some steps to mitigate against the attack. The authors of the exploit worked with Apple to harden Safari somewhat against the exploit; that was the focus of the recent Safari upgrade.
Ok so I didn't read the actual paper because I am an idiot, but the arstechnica article seems to imply this affects mobile as well. Is that right? Does just turning off JavaScript take care of this? Do I need to be very worried?
posted by Literaryhero at 12:25 AM on February 15, 2017
posted by Literaryhero at 12:25 AM on February 15, 2017
How can I protect myself as a user against the AnC attack?
You unfortunately cannot as AnC exploits the fundamental properties of your processor. You can however stop untrusted JavaScript code from being executed on your browser using a plugin such as NoScript.
posted by vacapinta at 12:28 AM on February 15, 2017 [1 favorite]
You unfortunately cannot as AnC exploits the fundamental properties of your processor. You can however stop untrusted JavaScript code from being executed on your browser using a plugin such as NoScript.
This is what is confusing me. The first sentence says you can't protect yourself, but the second says turning off JavaScript protects you. Am I failing at reading comprehension?
posted by Literaryhero at 12:31 AM on February 15, 2017 [1 favorite]
This is what is confusing me. The first sentence says you can't protect yourself, but the second says turning off JavaScript protects you. Am I failing at reading comprehension?
posted by Literaryhero at 12:31 AM on February 15, 2017 [1 favorite]
the arstechnica article seems to imply this affects mobile
The authors say they've been able to successfully implement the exploit on every processor they've tested. They've tested 22 so far.
So, yes.
posted by lastobelus at 12:33 AM on February 15, 2017 [4 favorites]
The authors say they've been able to successfully implement the exploit on every processor they've tested. They've tested 22 so far.
So, yes.
posted by lastobelus at 12:33 AM on February 15, 2017 [4 favorites]
turning off JavaScript protects you
Ok well sure. You can read news & stuff safely still.
It's not the absolute end of the world. Just the end of the world (for a while) as we know it.
posted by lastobelus at 12:35 AM on February 15, 2017 [3 favorites]
Ok well sure. You can read news & stuff safely still.
It's not the absolute end of the world. Just the end of the world (for a while) as we know it.
posted by lastobelus at 12:35 AM on February 15, 2017 [3 favorites]
For the non-technical, part of what makes this scary is that it is a hardware side-channel attack, that attacks properties present in all modern processors.
That means, it breaks ASLR (a OS-level software strategy that protects against buffer overflow attacks) by a side-channel (not by attacking ASLR itself, which would require a different exploit for every OS, probably for every version of every OS).
This means this one exploit can be used to open up all operating systems on all modern hardware to buffer overflow attacks.
posted by lastobelus at 12:46 AM on February 15, 2017 [2 favorites]
That means, it breaks ASLR (a OS-level software strategy that protects against buffer overflow attacks) by a side-channel (not by attacking ASLR itself, which would require a different exploit for every OS, probably for every version of every OS).
This means this one exploit can be used to open up all operating systems on all modern hardware to buffer overflow attacks.
posted by lastobelus at 12:46 AM on February 15, 2017 [2 favorites]
This can be done from most languages, not just JavaScript. So don't run any untrusted code whatsoever, including relatively well-sandboxed languages like JavaScript.
posted by aubilenon at 12:48 AM on February 15, 2017 [6 favorites]
posted by aubilenon at 12:48 AM on February 15, 2017 [6 favorites]
For the non-technical, can you explain what a buffer overflow attack is?
posted by Grangousier at 12:49 AM on February 15, 2017 [1 favorite]
posted by Grangousier at 12:49 AM on February 15, 2017 [1 favorite]
Thanks, aubilenon. That's what I was wondering.
posted by Literaryhero at 12:50 AM on February 15, 2017 [1 favorite]
posted by Literaryhero at 12:50 AM on February 15, 2017 [1 favorite]
This can be done from most languages, not just JavaScript.
Right, and they didn't publish a javascript version, so we have some time before it starts showing up.
But it's the combination of a) in javascript , b) in any browser on any OS, c) on any hardware that makes it so potentially severe.
posted by lastobelus at 12:51 AM on February 15, 2017
Right, and they didn't publish a javascript version, so we have some time before it starts showing up.
But it's the combination of a) in javascript , b) in any browser on any OS, c) on any hardware that makes it so potentially severe.
posted by lastobelus at 12:51 AM on February 15, 2017
For the non-technical, can you explain what a buffer overflow attack is?
Overrunning the bounds of a variable (some string usually) in a way that causes a payload of code to be executed. Here's a link that's tries to be non-technical.
ASLR protected against such attacks by making it very difficult to guess where the interesting bits of code (ie, that would give you access to things you shouldn't have) would be in memory, so even if you had a working buffer overflow exploit it was difficult to do anything with it.
posted by lastobelus at 12:55 AM on February 15, 2017 [2 favorites]
Overrunning the bounds of a variable (some string usually) in a way that causes a payload of code to be executed. Here's a link that's tries to be non-technical.
ASLR protected against such attacks by making it very difficult to guess where the interesting bits of code (ie, that would give you access to things you shouldn't have) would be in memory, so even if you had a working buffer overflow exploit it was difficult to do anything with it.
posted by lastobelus at 12:55 AM on February 15, 2017 [2 favorites]
Ah. The analogies just make it worse. I find the straightforward explanation less confusing, tbh, assuming it's accurate. Thanks, though.
posted by Grangousier at 1:08 AM on February 15, 2017 [8 favorites]
posted by Grangousier at 1:08 AM on February 15, 2017 [8 favorites]
It should be noted - assuming I'm understanding what's being described correctly this time of night - that this does not mean "anything with JS is immediately exploitable." It means that countermeasures put in place to make it harder to exploit a particular - but historically very major - category of security flaw turn out to be reliably defeatable. You still need that actual buffer overflow bug - however this significantly increases the potential impact of such bugs in practice.
posted by atoxyl at 1:19 AM on February 15, 2017 [22 favorites]
posted by atoxyl at 1:19 AM on February 15, 2017 [22 favorites]
Not to say it's no big deal, because exploitable bugs will happen and when you do have a remote exploit via visiting a web page that's about as bad as things get.
posted by atoxyl at 1:25 AM on February 15, 2017
posted by atoxyl at 1:25 AM on February 15, 2017
I'm not a "hat" of any colour, but I think one of the reasons this is concerning is how much it increases the potential ROI of developing exploits by making them significantly easier to weaponize and harder to patch against.
posted by lastobelus at 1:33 AM on February 15, 2017
posted by lastobelus at 1:33 AM on February 15, 2017
Look on the bright side: because there's no fix, you don't need to emergency patch your systems.
posted by ryanrs at 1:45 AM on February 15, 2017 [36 favorites]
posted by ryanrs at 1:45 AM on February 15, 2017 [36 favorites]
Chances are, the NSA, Russian Mafia and/or People's Liberation Army have already had this exploit for a while.
posted by acb at 2:09 AM on February 15, 2017 [2 favorites]
posted by acb at 2:09 AM on February 15, 2017 [2 favorites]
Too many secrets.
posted by I_Love_Bananas at 2:26 AM on February 15, 2017 [7 favorites]
posted by I_Love_Bananas at 2:26 AM on February 15, 2017 [7 favorites]
it's the combination of a) in javascript , b) in any browser on any OS, c) on any hardware that makes it so potentially severe.
it has just become glaringly visible to the commercial and government entities with a dependence on web traffic and modern frameworks: js sandboxing is a single point of failure for, like, The Web.
wager: before the week is out, some gov network IAO (probably dod) is going to demand NOSCRIPT be set for all browser installations. that will be a big fuckin self-imposed DOS for all their intranet web app garbage.
posted by j_curiouser at 2:35 AM on February 15, 2017 [4 favorites]
it has just become glaringly visible to the commercial and government entities with a dependence on web traffic and modern frameworks: js sandboxing is a single point of failure for, like, The Web.
wager: before the week is out, some gov network IAO (probably dod) is going to demand NOSCRIPT be set for all browser installations. that will be a big fuckin self-imposed DOS for all their intranet web app garbage.
posted by j_curiouser at 2:35 AM on February 15, 2017 [4 favorites]
Seems a fix is not automatic, for the people. Things may accelerate - it's all part of life's rich pageant. All we can do is collapse into now.
posted by iotic at 2:42 AM on February 15, 2017 [24 favorites]
posted by iotic at 2:42 AM on February 15, 2017 [24 favorites]
WIRED has an article that I felt provided background and context and a clear explanation of the entire situation.
posted by hippybear at 2:48 AM on February 15, 2017 [2 favorites]
posted by hippybear at 2:48 AM on February 15, 2017 [2 favorites]
A simple (but not exactly 100% correct) explanation of a buffer overflow: Imagine you have a book with a list of directions. The computer reads this book page by page to know what to do. A buffer overflow is the equivalent of tricking your computer to read directions from the wrong page in order to cause random things to happen. But this attack allows not just reading from the wrong page but picking a new page and writing your own directions on it. In other words, it allows Javascript to fundamentally alter the book of directions your computer runs and allows them to do whatever they want.
posted by lubujackson at 3:19 AM on February 15, 2017 [1 favorite]
posted by lubujackson at 3:19 AM on February 15, 2017 [1 favorite]
I understand nothing that is being talked about here--zero. The simple explanations do me no good because they are simple explanations that don't explain what they're explaining.
Can someone who knows how to talk to people who aren't coders or remotely educated in computer anything besides how to watch Netflix explain, in small words, the immediate, concrete dangers and possible consequences of whatever the fuck this is about?
Can people access my bank account? Should I freeze it?
Can people pretend to be me and send things from my email addresses?
Can people download illegal things to my computer remotely and without my knowledge?
Should I just shut everything down, and disconnect from the internet?
What are you all talking about?
posted by tzikeh at 3:57 AM on February 15, 2017 [34 favorites]
Can someone who knows how to talk to people who aren't coders or remotely educated in computer anything besides how to watch Netflix explain, in small words, the immediate, concrete dangers and possible consequences of whatever the fuck this is about?
Can people access my bank account? Should I freeze it?
Can people pretend to be me and send things from my email addresses?
Can people download illegal things to my computer remotely and without my knowledge?
Should I just shut everything down, and disconnect from the internet?
What are you all talking about?
posted by tzikeh at 3:57 AM on February 15, 2017 [34 favorites]
tzikeh — all of the activities you mentioned are already only partially secure. People can already do the bad things you described! This news is good for attackers (hackers, criminals, nation-states) and bad for defenders (IT, businesses, nation-states).
It's kind of like discovering a new antibiotic-resistant strain of a disease. We had a general problem (buffer overflow attacks) that we found a general defense against (ASLR). Now somebody has figured out how to theoretically render that defense broadly useless.
But because it's so new, and so general, it will be a little while before the attackers can make use of it. And there's not at this point a lot you as an end user can do other than wait for the defenders to try and pre-empt them.
posted by sixswitch at 4:22 AM on February 15, 2017 [8 favorites]
It's kind of like discovering a new antibiotic-resistant strain of a disease. We had a general problem (buffer overflow attacks) that we found a general defense against (ASLR). Now somebody has figured out how to theoretically render that defense broadly useless.
But because it's so new, and so general, it will be a little while before the attackers can make use of it. And there's not at this point a lot you as an end user can do other than wait for the defenders to try and pre-empt them.
posted by sixswitch at 4:22 AM on February 15, 2017 [8 favorites]
Can people access my bank account? Should I freeze it?
Can people pretend to be me and send things from my email addresses?
Can people download illegal things to my computer remotely and without my knowledge?
Should I just shut everything down, and disconnect from the internet?
What are you all talking about?
They can potentially run arbitrary code on your machine when a buffer overflow is used that would previously be blocked, and yes, that could do all of that. Think of this as a potential route to install a virus, if you're looking for a simple analogy. They have essentially turned off the thing that normally makes a certain way to prevent installing a virus useless. You have fewer defences than you did have, and anyone who has had some ways to escalate privileges (to make a program run as admin when it shouldn't be able to) is probably going to combine it with this attack. No, you shouldn't freeze your account, because that seems disproportionate.
What I would do as an absolute matter of urgency is to install some adblock software, and that would ideally be uBlock Origin, if you want a lightweight recommendation. Most malware is delivered via ad networks, because you can put it in many sites at once with the simple application of stolen credit card details and criminals tend to have a lot of those. This isn't an attack for 'script kiddies' running random code they don't understand, but it's high value enough that people will attempt to run this. For serious scale, ad networks will be where it's at.
Also you might want to turn off Javascript where you don't need to use it (pretty much always good advice), but personally I probably won't be doing that in places I don't already do so absent some reports of real world attacks.
posted by jaduncan at 4:32 AM on February 15, 2017 [5 favorites]
Can people pretend to be me and send things from my email addresses?
Can people download illegal things to my computer remotely and without my knowledge?
Should I just shut everything down, and disconnect from the internet?
What are you all talking about?
They can potentially run arbitrary code on your machine when a buffer overflow is used that would previously be blocked, and yes, that could do all of that. Think of this as a potential route to install a virus, if you're looking for a simple analogy. They have essentially turned off the thing that normally makes a certain way to prevent installing a virus useless. You have fewer defences than you did have, and anyone who has had some ways to escalate privileges (to make a program run as admin when it shouldn't be able to) is probably going to combine it with this attack. No, you shouldn't freeze your account, because that seems disproportionate.
What I would do as an absolute matter of urgency is to install some adblock software, and that would ideally be uBlock Origin, if you want a lightweight recommendation. Most malware is delivered via ad networks, because you can put it in many sites at once with the simple application of stolen credit card details and criminals tend to have a lot of those. This isn't an attack for 'script kiddies' running random code they don't understand, but it's high value enough that people will attempt to run this. For serious scale, ad networks will be where it's at.
Also you might want to turn off Javascript where you don't need to use it (pretty much always good advice), but personally I probably won't be doing that in places I don't already do so absent some reports of real world attacks.
posted by jaduncan at 4:32 AM on February 15, 2017 [5 favorites]
Sixswitch - "we had a problem (buffer overflow attacks)" is exactly what I mean about the explanations not explaining what they're explaining. I don't know what any of these words mean and I don't know what is or isn't relevant.
I know that the activities I described could already happen, but I didn't worry about them too much because... well, because I figured the chance of someone coming after me and my not-remotely-important computer were slim. Maybe I was being foolish and ignorant. But the way this discussion is going (as far as I can decipher from the foreign language it's being spoken in, from tone and context clues) makes it sound like something APOCALYPTIC just happened in the world of "using your computer or phone," but no one has yet explained what. I don't know what a buffer is, or why it has an overflow, or why someone would attack said overflow, or what the risks are to me, right now.
posted by tzikeh at 4:34 AM on February 15, 2017 [3 favorites]
I know that the activities I described could already happen, but I didn't worry about them too much because... well, because I figured the chance of someone coming after me and my not-remotely-important computer were slim. Maybe I was being foolish and ignorant. But the way this discussion is going (as far as I can decipher from the foreign language it's being spoken in, from tone and context clues) makes it sound like something APOCALYPTIC just happened in the world of "using your computer or phone," but no one has yet explained what. I don't know what a buffer is, or why it has an overflow, or why someone would attack said overflow, or what the risks are to me, right now.
posted by tzikeh at 4:34 AM on February 15, 2017 [3 favorites]
It's important to remember, as atoxyl said, that this doesn't mean that every browser on every computer is now a sandbox for remote code execution. ASLR is a technique designed to prevent a certain kind of programming error from being exploited. (See here for the classic explanation). This kind of bug was once widespread and widely exploited, but we've felt pretty safe from it since ASLR became widespread. But if the bug isn't present, it can't be exploited, regardless of this new discovery.
That being said I'm gonna be pretty nervous on the web until we get a browser fully implemented in a language like Rust.
posted by dis_integration at 4:37 AM on February 15, 2017 [2 favorites]
That being said I'm gonna be pretty nervous on the web until we get a browser fully implemented in a language like Rust.
posted by dis_integration at 4:37 AM on February 15, 2017 [2 favorites]
Jaduncan - that helps a little bit. Thank you. I already have ad blocking software on my laptop - I don't know if it can be installed on a phone or tablet. I also don't know if JavaScript can be turned off on phones and tablets, and I don't know if I'll be able to do anything if JavaScript is turned off anyway - my understanding is that most websites make use of it in one way or another and won't function properly without it. I guess we'll find out.
posted by tzikeh at 4:39 AM on February 15, 2017
posted by tzikeh at 4:39 AM on February 15, 2017
tzikeh, the short answer is that you don't need to do anything for now. This is a major problem for the people who try to keep things secure, but it doesn't mean everything's instantly broken. Everything's just at more risk of being instantly broken. If and when that happens, there'll likely be a lot more news about it.
posted by Ickster at 4:43 AM on February 15, 2017 [3 favorites]
posted by Ickster at 4:43 AM on February 15, 2017 [3 favorites]
If you're wanting to block ad networks on your Android devices, I would recommend DNS66 installed via F-Droid. You'll need to allow installs from unknown sources in the settings, but you'll then have a local VPN that blocks almost all ad networks without root. I'm aware that's technical. The simpler version is that once you install that and turn it on you'll see a key and that will indicate that adblocking is working. Don't install random Android apps not from F-Droid or the Play Store though.
posted by jaduncan at 4:44 AM on February 15, 2017 [2 favorites]
posted by jaduncan at 4:44 AM on February 15, 2017 [2 favorites]
Security by obscurity - that is, trying to hide details about how the systems you're defending are implemented - is not, has never been, and will never be actual security. ASLR is a prime example of security by obscurity, and since being invented it's been treated as if it were a one-size-fits-all corrective for bad code containing potential buffer overflow vulnerabilities.
I'm actually quite happy to see it busted. Perhaps now we can get on with improving our ability to build software whose security depends on genuinely robust design rather than half-assed complexity-multiplying spackle slapped on over shit code to disguise all the cut corners.
Of course, I might just be feeling particularly sour right now, having only just been informed that this month's list of security vulnerabilities in Flash Player consists of 13 (thirteen!) that could lead to execution of attackers' code, all of which basically boil down to sloppy programming practices.
posted by flabdablet at 4:47 AM on February 15, 2017 [7 favorites]
I'm actually quite happy to see it busted. Perhaps now we can get on with improving our ability to build software whose security depends on genuinely robust design rather than half-assed complexity-multiplying spackle slapped on over shit code to disguise all the cut corners.
Of course, I might just be feeling particularly sour right now, having only just been informed that this month's list of security vulnerabilities in Flash Player consists of 13 (thirteen!) that could lead to execution of attackers' code, all of which basically boil down to sloppy programming practices.
posted by flabdablet at 4:47 AM on February 15, 2017 [7 favorites]
tzikeh - an even simpler analogy would be a case where your house was accidentally built with a secret, unlocked door. Somewhere, in a hidden location, is a map showing where the door is. Someone has come up with a way to "easily" identify the location of the map, and hence the location of the door.
In this analogy, the door is some security bug in the software and ASLR is the method which hides the location of the map. Someone has found a way to defeat ASLR and locate the bug.
So, this is only a problem is there is a bug to find in the first place (which is the argument that a lot of companies, such as Microsoft, are using to say this is not a significant issue).
So, if your system is regularly updated with patches for bugs as they are discovered, the chances of being affected by this are slim. If you follow normal online precautions, you are probably going to be OK until someone comes up with a proper solution to this.
If you are very concerned, turn off javascript (or use a plugin like NOSCRIPT) and you will lessen the odds even further. However, as others have said, this is not just a javascript problem so if someone is really out to get you, they will find a way - but this has always been the case.
In response to your later question, instructions to disable javascript on mobile devices can be found here:
iOS: https://www.lifewire.com/iphone-java-disable-445800
Android: http://ccm.net/faq/39964-google-chrome-for-android-turn-off-javascript
posted by oclipa at 4:47 AM on February 15, 2017 [4 favorites]
In this analogy, the door is some security bug in the software and ASLR is the method which hides the location of the map. Someone has found a way to defeat ASLR and locate the bug.
So, this is only a problem is there is a bug to find in the first place (which is the argument that a lot of companies, such as Microsoft, are using to say this is not a significant issue).
So, if your system is regularly updated with patches for bugs as they are discovered, the chances of being affected by this are slim. If you follow normal online precautions, you are probably going to be OK until someone comes up with a proper solution to this.
If you are very concerned, turn off javascript (or use a plugin like NOSCRIPT) and you will lessen the odds even further. However, as others have said, this is not just a javascript problem so if someone is really out to get you, they will find a way - but this has always been the case.
In response to your later question, instructions to disable javascript on mobile devices can be found here:
iOS: https://www.lifewire.com/iphone-java-disable-445800
Android: http://ccm.net/faq/39964-google-chrome-for-android-turn-off-javascript
posted by oclipa at 4:47 AM on February 15, 2017 [4 favorites]
It's running a program in a way that it can only access a little subset of things that it's allowed to touch rather than everything you can as the user. To pick a really simple example, you might want it to be able to save things to Downloads but not to be able to read the configuration files for your banking app. Sandboxing supplies those limits.
posted by jaduncan at 4:48 AM on February 15, 2017 [1 favorite]
posted by jaduncan at 4:48 AM on February 15, 2017 [1 favorite]
Sandboxing is running a program in its own little area of computer resources without access to lower-level stuff. Most browsers run largely sandboxed, because they're most directly exposed to the web.
posted by Ickster at 4:48 AM on February 15, 2017
posted by Ickster at 4:48 AM on February 15, 2017
Buffer overflows are exploits that push 500 carefully crafted bytes into a 5 byte form & trick the computer into running the extra 495 bytes as a program. It depends on something called the stack, basically a queue of instructions waiting to be executed, being in a predictable place in memory so when the 500 bytes are stuffed into a 5 byte space some part of the 495 extra bytes gets written onto the stack & executed. ASLR is a technique for randomizing the location of the stack (& some other things like the heap, another security-sensitive area in memory) so an attacker can't predict where the stack will be & the exploit won't work. Yay!
But now this ASLR Cache technique lets attackers use pretty much any language to de-randomize ASLR & find the stack. This technique uses a fundamental property of CPUs that can't be easily blocked. So now ASLR is effectively broken as a defensive mechanism, the stack & heap's hiding places can be found & buffers are waiting to be overflowed again. The problem isn't javascript, it's just a handy tool already in your browser for performing the de-randomizing. The problem is a fatal flaw in ASLR itself. It's become a key part of our defensive arsenal but now it can't be relied on.
posted by scalefree at 4:50 AM on February 15, 2017 [11 favorites]
But now this ASLR Cache technique lets attackers use pretty much any language to de-randomize ASLR & find the stack. This technique uses a fundamental property of CPUs that can't be easily blocked. So now ASLR is effectively broken as a defensive mechanism, the stack & heap's hiding places can be found & buffers are waiting to be overflowed again. The problem isn't javascript, it's just a handy tool already in your browser for performing the de-randomizing. The problem is a fatal flaw in ASLR itself. It's become a key part of our defensive arsenal but now it can't be relied on.
posted by scalefree at 4:50 AM on February 15, 2017 [11 favorites]
I try to be glass-half-full so two cheers for the impending decrapification of web pages.
posted by whuppy at 4:54 AM on February 15, 2017 [4 favorites]
posted by whuppy at 4:54 AM on February 15, 2017 [4 favorites]
And for what it's worth, there actually exists a one-size-fits-all security measure that works about 10x as well as ASLR ever did, at least judged by how well it protects the average person from having their shit tampered with:
BLOCK ADVERTISING. ALL OF IT.
Very nearly 100% of the malicious crap designed to attack your devices in 2017 gets its foot in your door by having your browser collect it from a subverted advertising server.
posted by flabdablet at 4:56 AM on February 15, 2017 [4 favorites]
BLOCK ADVERTISING. ALL OF IT.
Very nearly 100% of the malicious crap designed to attack your devices in 2017 gets its foot in your door by having your browser collect it from a subverted advertising server.
posted by flabdablet at 4:56 AM on February 15, 2017 [4 favorites]
BLOCK ADVERTISING. ALL OF IT.
Very nearly 100% of the malicious crap designed to attack your devices in 2017 gets its foot in your door by having your browser collect it from a subverted advertising server.
Are you saying you have this one weird security tip and marketers hate you?
posted by jaduncan at 4:58 AM on February 15, 2017 [29 favorites]
Very nearly 100% of the malicious crap designed to attack your devices in 2017 gets its foot in your door by having your browser collect it from a subverted advertising server.
Are you saying you have this one weird security tip and marketers hate you?
posted by jaduncan at 4:58 AM on February 15, 2017 [29 favorites]
BLOCK ADVERTISING. ALL OF IT.
Ok - blocking advertising on Safari on iPhone and iPad -- there's an app for that, so yay. Blocking advertising on Chrome for iPhone and iPad? Coming up empty....
posted by tzikeh at 5:02 AM on February 15, 2017 [1 favorite]
Ok - blocking advertising on Safari on iPhone and iPad -- there's an app for that, so yay. Blocking advertising on Chrome for iPhone and iPad? Coming up empty....
posted by tzikeh at 5:02 AM on February 15, 2017 [1 favorite]
Immediate, concrete dangers? A bunch of existing baddies have their work made easier. Probably doesn't affect your day-to-day. That said:
Can people access my bank account? Should I freeze it?
Can people pretend to be me and send things from my email addresses?
Can people download illegal things to my computer remotely and without my knowledge?
Install NoScript and disable Javascript for all sites, except ones you specify are ok. Namely: your bank, Netflix, Metafilter, etc. That more than makes up for the consequences of this particular attack.
Should I just shut everything down, and disconnect from the internet?
No, because then we wouldn't have you on Metafilter.
posted by iffthen at 5:12 AM on February 15, 2017 [5 favorites]
Can people access my bank account? Should I freeze it?
Can people pretend to be me and send things from my email addresses?
Can people download illegal things to my computer remotely and without my knowledge?
Install NoScript and disable Javascript for all sites, except ones you specify are ok. Namely: your bank, Netflix, Metafilter, etc. That more than makes up for the consequences of this particular attack.
Should I just shut everything down, and disconnect from the internet?
No, because then we wouldn't have you on Metafilter.
posted by iffthen at 5:12 AM on February 15, 2017 [5 favorites]
It would appear, if you can read this comment, that Metafilter degrades gracefully when denied JS for comments but does not do so for the formatting assistance or adding favourites etc.
posted by jaduncan at 5:15 AM on February 15, 2017
posted by jaduncan at 5:15 AM on February 15, 2017
...and you can. That probably also works wonders for really massive threads on phones.
posted by jaduncan at 5:15 AM on February 15, 2017 [1 favorite]
posted by jaduncan at 5:15 AM on February 15, 2017 [1 favorite]
Install NoScript and disable Javascript for all sites, except ones you specify are ok. Namely: your bank, Netflix, Metafilter, etc.
Also install uBlock Origin wherever you possibly can, because otherwise NoScript will drive you insane with decisions about allowing scripts for the advertising networks used by your bank, Netflix, Metafilter etc.
If all you're using is NoScript or similar script-whitelisting tools, it takes a certain amount of time and application to work out exactly which of the tens to hundreds of servers that build a modern advertising-laden web page are providing the scripts actually needed for it to work at all, and which are only there to track you or grab you by the eyeballs for commercial purposes. Using a good ad blocker like uBlock Origin lets you outsource a lot of that decision-making to people likely to be better informed than you are.
posted by flabdablet at 5:18 AM on February 15, 2017 [6 favorites]
Also install uBlock Origin wherever you possibly can, because otherwise NoScript will drive you insane with decisions about allowing scripts for the advertising networks used by your bank, Netflix, Metafilter etc.
If all you're using is NoScript or similar script-whitelisting tools, it takes a certain amount of time and application to work out exactly which of the tens to hundreds of servers that build a modern advertising-laden web page are providing the scripts actually needed for it to work at all, and which are only there to track you or grab you by the eyeballs for commercial purposes. Using a good ad blocker like uBlock Origin lets you outsource a lot of that decision-making to people likely to be better informed than you are.
posted by flabdablet at 5:18 AM on February 15, 2017 [6 favorites]
Ok, for the non-tech types:
The critical thing to understand about buffer overflow attacks is that computers only have one place where they store all the information of what's going on - RAM. So the operating system, the program you're running, all the other programs running that you don't see are all storing that information in the same place. And what's critical to remember is that, to a computer, all information is the same (just bits) until it is interpreted in some form. So, just looking at the contents of RAM, the commands that tell a program what to do are virtually indistinguishable from the other parts of the program, such as a picture or a string of text.
What the attack does is it tricks a program (since every program has errors) into trying to store in the extra space not used for commands (some of which the program has set aside for receiving new data from somewhere else) something too large for the space. If the program isn't written well, it will keep storing the data in the RAM until it is literally replacing parts of the original program code with the new data. Now, when the program tries to execute the commands stored in that spot, the information is actually different, and it can tell the computer to do something else. In particular, a successful attack makes sure that the data being written (and replacing the original program commands) is itself valid commands that can then be run by the computer, and the program can now be instructed to do something entirely different, like open a dedicated channel to listen to more commands from the attacker.
ASLR tries to mitigate the risk of this attack by shuffling around the parts of a program when it gets loaded into RAM, so that an attacker cannot predict what parts of the program's code they'll be overwriting. That heavily increases the chances that an attack will fail, because the attacker doesn't know if the new code they added will ever get run, and even if it is run it's more likely to be run somewhere in the middle of the new code, which will simply crash the program (a crashed program sucks for the user, but when the program is unloaded from RAM, the attack is erased with it, and the program can usually be re-loaded from the hard-drive and run again).
The recent discovery is that there is a way for javascript, running in a browser, to essentially help in "de-jumbling" the code enough for the attacker to be able to still carry out an effective attack. It does so by first attacking a place where a list of all the program's pieces (the ones that have been jumbled) are stored - useful, since those pieces have been jumbled and that makes them fast to find again. It messes that list up in a local super-fast copy the processor keeps called the "cache," which then forces the processor to grab a fresh copy from the actual RAM. Do that enough, and the code can figure out where in the RAM it resides, which allows it to figure out how to construct the buffer overflow attack so that it can succeed.
posted by mystyk at 5:30 AM on February 15, 2017 [11 favorites]
The critical thing to understand about buffer overflow attacks is that computers only have one place where they store all the information of what's going on - RAM. So the operating system, the program you're running, all the other programs running that you don't see are all storing that information in the same place. And what's critical to remember is that, to a computer, all information is the same (just bits) until it is interpreted in some form. So, just looking at the contents of RAM, the commands that tell a program what to do are virtually indistinguishable from the other parts of the program, such as a picture or a string of text.
What the attack does is it tricks a program (since every program has errors) into trying to store in the extra space not used for commands (some of which the program has set aside for receiving new data from somewhere else) something too large for the space. If the program isn't written well, it will keep storing the data in the RAM until it is literally replacing parts of the original program code with the new data. Now, when the program tries to execute the commands stored in that spot, the information is actually different, and it can tell the computer to do something else. In particular, a successful attack makes sure that the data being written (and replacing the original program commands) is itself valid commands that can then be run by the computer, and the program can now be instructed to do something entirely different, like open a dedicated channel to listen to more commands from the attacker.
ASLR tries to mitigate the risk of this attack by shuffling around the parts of a program when it gets loaded into RAM, so that an attacker cannot predict what parts of the program's code they'll be overwriting. That heavily increases the chances that an attack will fail, because the attacker doesn't know if the new code they added will ever get run, and even if it is run it's more likely to be run somewhere in the middle of the new code, which will simply crash the program (a crashed program sucks for the user, but when the program is unloaded from RAM, the attack is erased with it, and the program can usually be re-loaded from the hard-drive and run again).
The recent discovery is that there is a way for javascript, running in a browser, to essentially help in "de-jumbling" the code enough for the attacker to be able to still carry out an effective attack. It does so by first attacking a place where a list of all the program's pieces (the ones that have been jumbled) are stored - useful, since those pieces have been jumbled and that makes them fast to find again. It messes that list up in a local super-fast copy the processor keeps called the "cache," which then forces the processor to grab a fresh copy from the actual RAM. Do that enough, and the code can figure out where in the RAM it resides, which allows it to figure out how to construct the buffer overflow attack so that it can succeed.
posted by mystyk at 5:30 AM on February 15, 2017 [11 favorites]
This will end up being a bigger headache than people think once fixes start to be rolled out. This is because most, if not all, "fixes" are almost guaranteed to apply only to the latest versions of affected software, OSes, hardware, etc., leaving a not-insubstantial chunk of users exposed. For instance, the Safari update was not backward compatible.
Of course, as usual, the response from the tech world will be the usual tired, elitist chant of "Upgrade or die", exhorting everyone to immediately buy the latest hardware, so you can install the latest software, ignoring that so, so many people don't have the disposable income to spring for new gear as often (if at all) as the denizens of the tech world seem to.
Fixes that aren't applicable to software and hardware several generations old are going to be failures. It's the equivalent of saving the rich neighborhoods from the flood waters and letting the rest of the community fend for itself.
posted by Thorzdad at 5:32 AM on February 15, 2017 [7 favorites]
Of course, as usual, the response from the tech world will be the usual tired, elitist chant of "Upgrade or die", exhorting everyone to immediately buy the latest hardware, so you can install the latest software, ignoring that so, so many people don't have the disposable income to spring for new gear as often (if at all) as the denizens of the tech world seem to.
Fixes that aren't applicable to software and hardware several generations old are going to be failures. It's the equivalent of saving the rich neighborhoods from the flood waters and letting the rest of the community fend for itself.
posted by Thorzdad at 5:32 AM on February 15, 2017 [7 favorites]
Also install uBlock Origin wherever you possibly can, because otherwise NoScript will drive you insane with decisions about allowing scripts for the advertising networks used by your bank, Netflix, Metafilter etc.
Yeah, I run privacy badger and an adblocker and leave noscript deactivated most of the time, and that's bad enough. Noscript breaks pretty much everything. And it's not like it used to be where there were a handful of servers/scripts to authorize.
Shit.
posted by snuffleupagus at 5:33 AM on February 15, 2017 [2 favorites]
Yeah, I run privacy badger and an adblocker and leave noscript deactivated most of the time, and that's bad enough. Noscript breaks pretty much everything. And it's not like it used to be where there were a handful of servers/scripts to authorize.
Shit.
posted by snuffleupagus at 5:33 AM on February 15, 2017 [2 favorites]
Fixes that aren't applicable to software and hardware several generations old are going to be failures. It's the equivalent of saving the rich neighborhoods from the flood waters and letting the rest of the community fend for itself.
The one that makes me wince is old Android devices. Some OEMs will dump devices after 18 months.
posted by jaduncan at 5:40 AM on February 15, 2017 [2 favorites]
The one that makes me wince is old Android devices. Some OEMs will dump devices after 18 months.
posted by jaduncan at 5:40 AM on February 15, 2017 [2 favorites]
I like the way that browser vendors came up with a minor mitigation for the problem — not by admitting the problem was essentially unfixable, but by deliberately fucking up the results of JS's performance.now() method. This is the ultimate in turd-polishing.
So I guess Harvard architecture — separate code and data memories — doesn't seem such a bad idea after all now. That von Neumann, what a fuckin' chancer, eh?
posted by scruss at 5:50 AM on February 15, 2017 [7 favorites]
So I guess Harvard architecture — separate code and data memories — doesn't seem such a bad idea after all now. That von Neumann, what a fuckin' chancer, eh?
posted by scruss at 5:50 AM on February 15, 2017 [7 favorites]
So I guess Harvard architecture — separate code and data memories — doesn't seem such a bad idea after all now.
I have a building blocks and Brio trains level of understanding when it comes to deep wizardry (or any wizardry, really) but doesn't this also imply trading off certain kinds of polymorphism and self-modifying code, etc?
posted by snuffleupagus at 5:53 AM on February 15, 2017 [3 favorites]
I have a building blocks and Brio trains level of understanding when it comes to deep wizardry (or any wizardry, really) but doesn't this also imply trading off certain kinds of polymorphism and self-modifying code, etc?
posted by snuffleupagus at 5:53 AM on February 15, 2017 [3 favorites]
doesn't this also imply trading off certain kinds of polymorphism and self-modifying code, etc?
Yes it does. To which the perfectly reasonable response from the Harvard Architecture fans is "suck it up, buttercup."
Modern processors are more than fast enough not to need help from Mel any more.
That said: Harvard architectures typically do have instructions and perhaps even DMA controller hardware for getting stuff into program RAM; it's just that those instructions and controllers are separate from, and frequently slower than, those that read and write the data RAM.
posted by flabdablet at 5:59 AM on February 15, 2017 [6 favorites]
Yes it does. To which the perfectly reasonable response from the Harvard Architecture fans is "suck it up, buttercup."
Modern processors are more than fast enough not to need help from Mel any more.
That said: Harvard architectures typically do have instructions and perhaps even DMA controller hardware for getting stuff into program RAM; it's just that those instructions and controllers are separate from, and frequently slower than, those that read and write the data RAM.
posted by flabdablet at 5:59 AM on February 15, 2017 [6 favorites]
Blocking advertising on Chrome for iPhone and iPad? Coming up empty....
Purify is maintained by the same guy who now looks after one of the uBlock forks, so I would expect it to work similarly well.
posted by flabdablet at 6:03 AM on February 15, 2017
Purify is maintained by the same guy who now looks after one of the uBlock forks, so I would expect it to work similarly well.
posted by flabdablet at 6:03 AM on February 15, 2017
Fixes that aren't applicable to software and hardware several generations old are going to be failures.
This is a hardware vulnerability and I don't think a "fix" there is even possible. If caching is built into a processor's architecture, there isn't going to be a way to just turn it off.
posted by thelonius at 6:03 AM on February 15, 2017 [1 favorite]
This is a hardware vulnerability and I don't think a "fix" there is even possible. If caching is built into a processor's architecture, there isn't going to be a way to just turn it off.
posted by thelonius at 6:03 AM on February 15, 2017 [1 favorite]
This is the main reason why I use the Brave.com browser: it has a persistent per-site JavaScript toggle built in, which means I can browse with it disabled by default – which is also much faster, especially on mobile – and enable it only on the relatively small number of sites which actually do something of value with it.
posted by adamsc at 6:05 AM on February 15, 2017 [2 favorites]
posted by adamsc at 6:05 AM on February 15, 2017 [2 favorites]
The only actual genuine fix is for system designers to realize that ASLR was never much good to begin with and just get used to living in a world where it doesn't work any more. Time spent re-engineering hardware to make ASLR work again would be far better spent on working out ways to actually fix the buffer overflow and use-after-free mistakes it partially mitigates.
posted by flabdablet at 6:07 AM on February 15, 2017 [3 favorites]
posted by flabdablet at 6:07 AM on February 15, 2017 [3 favorites]
I do wonder if anyone knows if Firefox's recent implementation of W^X (write xor execute memory, which means that although you might be able to discover where the instruction pointer is, you can't write to it) makes this a relative non issue.
posted by dis_integration at 6:08 AM on February 15, 2017 [2 favorites]
posted by dis_integration at 6:08 AM on February 15, 2017 [2 favorites]
Given this looming ASLR disaster, perhaps I shall calm myself down with some ASMR today...
posted by twsf at 6:13 AM on February 15, 2017 [5 favorites]
posted by twsf at 6:13 AM on February 15, 2017 [5 favorites]
That being said I'm gonna be pretty nervous on the web until we get a browser fully implemented in a language like Rust.
What about Rust makes a sandbox built by it not exploitable in the way one built in C? The big finding here seems to be that sandboxes in general can be used to defeat ASLR via indirect means.
posted by ignignokt at 6:18 AM on February 15, 2017 [2 favorites]
What about Rust makes a sandbox built by it not exploitable in the way one built in C? The big finding here seems to be that sandboxes in general can be used to defeat ASLR via indirect means.
Our attack relies on the interplay between the MMU and the caches during virtual to physical address translation—core hardware behavior that is central to efficient code execution on modern CPUs. The underlying problem is that the complex nature of modern microarchitectures allows attackers with knowledge of the architecture to craft a carefully chosen series of memory accesses which manifest timing differences that disclose what memory is accessed where and to infer all the bits that make up the address.Does anyone who's read the whole paper know if there's a specific sandbox restriction that would defeat this?
posted by ignignokt at 6:18 AM on February 15, 2017 [2 favorites]
Harvard architecture — separate code and data memories — doesn't seem such a bad idea after all now.
There's a large class of exploits that still work on Harvard machines. They're somewhat trickier to get right than the kind of simple shellcode you typically see used with a buffer overflow, where the attacker provides code that actually runs once the exploit is triggered.
Instead of directly running code provided by the attacker, the trick is to call pre-existing library functions in ways that do whatever the attacker wants done. This can be done purely by messing with subroutine return addresses stored in the stack; no new code need be supplied.
This class of exploits also works against von Neumann machines with CPUs and memory management hardware that implements various schemes for executable space protection.
The cleanest way to counter these exploits is to have the compiler generate code that uses completely separate memory pages for call stacks and data stacks, so that the only way to write a return address into the call stack is to make a genuine procedure call. Buffer overflows that happen inside the data stack, or inside the heap, will at worst then corrupt other data; they have no way to affect actual program flow, or at least not directly.
Languages like Javascript that allow for closures (where at least some of the data held for the private use of any given subroutine has to persist across multiple calls to that routine) tend to do this pretty much automatically.
posted by flabdablet at 6:24 AM on February 15, 2017 [2 favorites]
There's a large class of exploits that still work on Harvard machines. They're somewhat trickier to get right than the kind of simple shellcode you typically see used with a buffer overflow, where the attacker provides code that actually runs once the exploit is triggered.
Instead of directly running code provided by the attacker, the trick is to call pre-existing library functions in ways that do whatever the attacker wants done. This can be done purely by messing with subroutine return addresses stored in the stack; no new code need be supplied.
This class of exploits also works against von Neumann machines with CPUs and memory management hardware that implements various schemes for executable space protection.
The cleanest way to counter these exploits is to have the compiler generate code that uses completely separate memory pages for call stacks and data stacks, so that the only way to write a return address into the call stack is to make a genuine procedure call. Buffer overflows that happen inside the data stack, or inside the heap, will at worst then corrupt other data; they have no way to affect actual program flow, or at least not directly.
Languages like Javascript that allow for closures (where at least some of the data held for the private use of any given subroutine has to persist across multiple calls to that routine) tend to do this pretty much automatically.
posted by flabdablet at 6:24 AM on February 15, 2017 [2 favorites]
Me: Blocking advertising on Chrome for iPhone and iPad? Coming up empty....
flabdablet: Purify is maintained by the same guy who now looks after one of the uBlock forks, so I would expect it to work similarly well.
Says it's only for Safari on iPad and iPhone. Works on Chrome only on laptop/desktop computers.
posted by tzikeh at 6:24 AM on February 15, 2017
flabdablet: Purify is maintained by the same guy who now looks after one of the uBlock forks, so I would expect it to work similarly well.
Says it's only for Safari on iPad and iPhone. Works on Chrome only on laptop/desktop computers.
posted by tzikeh at 6:24 AM on February 15, 2017
Does uBlock Origin for Chrome not work in the iOS version of Chrome? I don't have an iOS device here to test against.
posted by flabdablet at 6:27 AM on February 15, 2017
posted by flabdablet at 6:27 AM on February 15, 2017
So this is pretty much proof that there really is nothing that Javascript can't ruin.
posted by the painkiller at 6:31 AM on February 15, 2017 [3 favorites]
posted by the painkiller at 6:31 AM on February 15, 2017 [3 favorites]
What about Rust makes a sandbox built by it not exploitable in the way one built in C? The big finding here seems to be that sandboxes in general can be used to defeat ASLR via indirect means.
This isn't about sandbox escape in general, it's about a method of sandbox escape that depends on a class of bugs that (safe) Rust code entirely eliminates. There are no off-by-one or buffer overflow bugs in Rust. Period. (sprays the thread with a water pistol). ASLR solves a problem that Rust doesn't need solved, because Rust forbids the unsafe use of memory.
posted by dis_integration at 6:34 AM on February 15, 2017 [4 favorites]
This isn't about sandbox escape in general, it's about a method of sandbox escape that depends on a class of bugs that (safe) Rust code entirely eliminates. There are no off-by-one or buffer overflow bugs in Rust. Period. (sprays the thread with a water pistol). ASLR solves a problem that Rust doesn't need solved, because Rust forbids the unsafe use of memory.
posted by dis_integration at 6:34 AM on February 15, 2017 [4 favorites]
Like a Rust program could just advertise the entire memory layout and tell you where the stack was etc and then be like "come at me bro" and the best you could do is panic it.
posted by dis_integration at 6:35 AM on February 15, 2017
posted by dis_integration at 6:35 AM on February 15, 2017
Hadn't installed noscript on my new laptop. Until just now.
posted by Splunge at 6:36 AM on February 15, 2017
posted by Splunge at 6:36 AM on February 15, 2017
The researchers have dubbed the technique ASLR Cache or AnC for short.
Wait, what? Where'd that 'n' come from?
posted by Theta States at 6:48 AM on February 15, 2017
Wait, what? Where'd that 'n' come from?
posted by Theta States at 6:48 AM on February 15, 2017
The researchers have dubbed the technique ASLR Cache or AnC for short.
Wait, what? Where'd that 'n' come from?
That should be ASLR⊕Cache. ASLR and Cache attack. So the attack works because processor caches break ASLR.
posted by dis_integration at 6:52 AM on February 15, 2017
Wait, what? Where'd that 'n' come from?
That should be ASLR⊕Cache. ASLR and Cache attack. So the attack works because processor caches break ASLR.
posted by dis_integration at 6:52 AM on February 15, 2017
Like a Rust program could just advertise the entire memory layout and tell you where the stack was etc and then be like "come at me bro"
...and that is how security should work.
Well engineered software security still relies on secrets, but those secrets (generally referred to as "keys") are many bits long (128 or more), purely data rather than code, and very very very carefully handled by very very very well tested, well vetted and well known code and/or dedicated hardware.
Keys are diamond-hard little nuggets of secrecy and the software or data they protect typically doesn't even get to exist if they're wrong. The features that make keys work are that they are specific - re-using the same key for multiple purposes is poor security design - as well as being revocable and replaceable so that if a key is found to have leaked it can simply be replaced by a different one.
Security-by-obscurity, where you try to make attacks more difficult by trying to hide certain features of how your system works, always fails eventually - and when it fails, it fails hard because knowledge spreads faster than obscurity can be re-engineered. This new attack against ASLR, which is clearly security-by-obscurity even though the obscurity is generated automatically on demand rather than being held in somebody's fireproof safe somewhere, breaks ASLR everywhere it gets used; ASLR is a technique, not a key.
posted by flabdablet at 6:53 AM on February 15, 2017 [6 favorites]
...and that is how security should work.
Well engineered software security still relies on secrets, but those secrets (generally referred to as "keys") are many bits long (128 or more), purely data rather than code, and very very very carefully handled by very very very well tested, well vetted and well known code and/or dedicated hardware.
Keys are diamond-hard little nuggets of secrecy and the software or data they protect typically doesn't even get to exist if they're wrong. The features that make keys work are that they are specific - re-using the same key for multiple purposes is poor security design - as well as being revocable and replaceable so that if a key is found to have leaked it can simply be replaced by a different one.
Security-by-obscurity, where you try to make attacks more difficult by trying to hide certain features of how your system works, always fails eventually - and when it fails, it fails hard because knowledge spreads faster than obscurity can be re-engineered. This new attack against ASLR, which is clearly security-by-obscurity even though the obscurity is generated automatically on demand rather than being held in somebody's fireproof safe somewhere, breaks ASLR everywhere it gets used; ASLR is a technique, not a key.
posted by flabdablet at 6:53 AM on February 15, 2017 [6 favorites]
The only actual genuine fix is for system designers to realize that ASLR was never much good to begin with and just get used to living in a world where it doesn't work any more.
Yeah, probably.
Time spent re-engineering hardware to make ASLR work again would be far better spent on working out ways to actually fix the buffer overflow and use-after-free mistakes it partially mitigates.
Memory unsafe software is the "last mile" of security: there's a ton of it and replacing it is a pain in the ass.
posted by a snickering nuthatch at 6:57 AM on February 15, 2017 [1 favorite]
Yeah, probably.
Time spent re-engineering hardware to make ASLR work again would be far better spent on working out ways to actually fix the buffer overflow and use-after-free mistakes it partially mitigates.
Memory unsafe software is the "last mile" of security: there's a ton of it and replacing it is a pain in the ass.
posted by a snickering nuthatch at 6:57 AM on February 15, 2017 [1 favorite]
I have AdBlock but I whitelist Metafilter and a few other sites so they get that sweet ad revenue.
Should I not do that?
(oh and this explains why my workplace IT just instituted 2-factor authentication)
posted by emjaybee at 6:58 AM on February 15, 2017
Should I not do that?
(oh and this explains why my workplace IT just instituted 2-factor authentication)
posted by emjaybee at 6:58 AM on February 15, 2017
Rust is not a panacea. If your Rust code uses unsafe blocks, uses a shared library, or makes any system calls, then your application is potentially vulnerable to buffer overflows, just like C or C++ code.
posted by pabs at 7:19 AM on February 15, 2017 [1 favorite]
posted by pabs at 7:19 AM on February 15, 2017 [1 favorite]
Rust is not a panacea. If your Rust code uses unsafe blocks, uses a shared library, or makes any system calls, then your application is potentially vulnerable to buffer overflows, just like C or C++ code.
Let's be honest here though. Asking for Rust in this context is waiting for Mozilla to finish the Servo engine. It entirely depends on how well they implement that, and how well sandboxed that code is.
posted by jaduncan at 7:39 AM on February 15, 2017 [2 favorites]
Let's be honest here though. Asking for Rust in this context is waiting for Mozilla to finish the Servo engine. It entirely depends on how well they implement that, and how well sandboxed that code is.
posted by jaduncan at 7:39 AM on February 15, 2017 [2 favorites]
"I have AdBlock but I whitelist Metafilter and a few other sites so they get that sweet ad revenue.
Should I not do that?"
If I remember correctly, AdBlock whitelists certain sites automatically which leaves you vulnerable which is why I switched to uBlock Origin.
But your comment reminded me that I didn't whitelist Metafilter on this computer. Time to do that now.
posted by I-baLL at 7:40 AM on February 15, 2017
Should I not do that?"
If I remember correctly, AdBlock whitelists certain sites automatically which leaves you vulnerable which is why I switched to uBlock Origin.
But your comment reminded me that I didn't whitelist Metafilter on this computer. Time to do that now.
posted by I-baLL at 7:40 AM on February 15, 2017
Rust is not a panacea. If your Rust code uses unsafe blocks, uses a shared library, or makes any system calls, then your application is potentially vulnerable to buffer overflows, just like C or C++ code.
The culture surrounding Rust strongly discourages using unsafe on an ad hoc basis. But the unsafety of FFI is a weak spot that may never go away.
posted by a snickering nuthatch at 7:49 AM on February 15, 2017 [2 favorites]
The culture surrounding Rust strongly discourages using unsafe on an ad hoc basis. But the unsafety of FFI is a weak spot that may never go away.
posted by a snickering nuthatch at 7:49 AM on February 15, 2017 [2 favorites]
Let's be honest here though. Asking for Rust in this context is waiting for Mozilla to finish the Servo engine. It entirely depends on how well they implement that, and how well sandboxed that code is.
Even with Servo, Firefox still relies on a large number of third party libraries written in other languages, including things like libav, libjpeg, and SQLite. And even if all of those third party libraries were rewritten in Rust, Firefox would still rely on system calls to interact with the operating system.
Which brings us back to my original point: switching to a safe language like Rust does not eliminate the possibility of buffer overflows, it only reduces the attack surface.
posted by pabs at 7:58 AM on February 15, 2017
"I have AdBlock but I whitelist Metafilter and a few other sites so they get that sweet ad revenue.
Should I not do that?
From a security perspective, you should not do that, from a mefite perspective, either whitelist Metafilter or block and donate.
Sites that use ad networks trust those ad networks to serve not-going-to-exploit-your-browser content, but ad networks are one source of malware.
So you may trust the capable owners of a site, but do you trust the servers and technical team of the ad networks?
posted by zippy at 8:04 AM on February 15, 2017 [2 favorites]
Should I not do that?
From a security perspective, you should not do that, from a mefite perspective, either whitelist Metafilter or block and donate.
Sites that use ad networks trust those ad networks to serve not-going-to-exploit-your-browser content, but ad networks are one source of malware.
So you may trust the capable owners of a site, but do you trust the servers and technical team of the ad networks?
posted by zippy at 8:04 AM on February 15, 2017 [2 favorites]
I wanted to favorite Thorzdad, but I turned off JavaScript. :(
posted by sageleaf at 8:16 AM on February 15, 2017 [6 favorites]
posted by sageleaf at 8:16 AM on February 15, 2017 [6 favorites]
Also install uBlock Origin wherever you possibly can, because otherwise NoScript will drive you insane with decisions about allowing scripts for the advertising networks used by your bank, Netflix, Metafilter etc.
After years of resisting, I finally got fed up by one more browser hijack, and today I'm using uBlock Origin and NoScript. And so far it's actually way less trouble, way more usable than I had expected.
And boy howdy does it speed things up, too.
posted by Western Infidels at 8:25 AM on February 15, 2017 [1 favorite]
After years of resisting, I finally got fed up by one more browser hijack, and today I'm using uBlock Origin and NoScript. And so far it's actually way less trouble, way more usable than I had expected.
And boy howdy does it speed things up, too.
posted by Western Infidels at 8:25 AM on February 15, 2017 [1 favorite]
I tried turning off Javascript when my browser got slow (It was an older install with too many extensions installed/uninstalled on a netbook), and most websites didn't even render correctly. Including news pages.
It's sad, too. So much of the scripts aren't even for the user's enjoyment, or even to display an ad the user will see, but just to track and analyse you.
I get we're not the customer, but the product, but if you're gonna run scripts on my computer and waste processor time, maybe use that to search for aliens or fold proteins?
posted by MuppetNavy at 8:29 AM on February 15, 2017 [2 favorites]
It's sad, too. So much of the scripts aren't even for the user's enjoyment, or even to display an ad the user will see, but just to track and analyse you.
I get we're not the customer, but the product, but if you're gonna run scripts on my computer and waste processor time, maybe use that to search for aliens or fold proteins?
posted by MuppetNavy at 8:29 AM on February 15, 2017 [2 favorites]
Wait, what? Where'd that 'n' come from?
Here 'n there.
posted by scalefree at 8:31 AM on February 15, 2017
Here 'n there.
posted by scalefree at 8:31 AM on February 15, 2017
It's sad, too. So much of the scripts aren't even for the user's enjoyment, or even to display an ad the user will see, but just to track and analyse you.
I get we're not the customer, but the product, but if you're gonna run scripts on my computer and waste processor time, maybe use that to search for aliens or fold proteins?
Seriously, there are so many sites whose purpose is served by styled text and images that won't even display when Javascript is turned off. Everyone is taking their sheaf-of-documents site and shoehorning it into a web app because the bloated Javascript frameworks available today make that the path of least resistance. It's not even just security issues being aggravated by this, a ton of the web is inaccessible in rural areas and developing nations because of this.
posted by indubitable at 9:02 AM on February 15, 2017 [5 favorites]
I get we're not the customer, but the product, but if you're gonna run scripts on my computer and waste processor time, maybe use that to search for aliens or fold proteins?
Seriously, there are so many sites whose purpose is served by styled text and images that won't even display when Javascript is turned off. Everyone is taking their sheaf-of-documents site and shoehorning it into a web app because the bloated Javascript frameworks available today make that the path of least resistance. It's not even just security issues being aggravated by this, a ton of the web is inaccessible in rural areas and developing nations because of this.
posted by indubitable at 9:02 AM on February 15, 2017 [5 favorites]
ASLR is not a first line of defense, it's a last ditch effort to prevent an attacker, who has already found a way to control the execution of your program, from managing to do anything damaging for a while.
It's like, the horses have bolted, barn door is open, so let's put these vaults in their way. Oh, horses can learn to jump over stuff?!
Return Oriented Programming etc are already well known ways around ASLR. They only require the attacker to do more work.
posted by joeyh at 9:07 AM on February 15, 2017 [3 favorites]
It's like, the horses have bolted, barn door is open, so let's put these vaults in their way. Oh, horses can learn to jump over stuff?!
Return Oriented Programming etc are already well known ways around ASLR. They only require the attacker to do more work.
posted by joeyh at 9:07 AM on February 15, 2017 [3 favorites]
Here's an idea. performance.now() is wholly unnecessary except to developers. Scrap it while the browser isn't in developer mode.
posted by Talez at 9:12 AM on February 15, 2017 [2 favorites]
posted by Talez at 9:12 AM on February 15, 2017 [2 favorites]
Talez: the problem with that is that collecting data from real users is essential for debugging – applications notoriously work correctly on the systems used to develop them but you often find yourself using things like timing data to understand which part is running too slow for 2% of your visitors.
posted by adamsc at 10:03 AM on February 15, 2017 [2 favorites]
posted by adamsc at 10:03 AM on February 15, 2017 [2 favorites]
I'm teaching beginning html/css/javascript to high school students and yesterday a student said he thought using javascript for styling was easier than using css. I told the class that some people turn off javascript in their browser so you shouldn't depend on it, and I was kicking myself all day for feeling like such an old...
posted by maggiemaggie at 10:36 AM on February 15, 2017 [1 favorite]
posted by maggiemaggie at 10:36 AM on February 15, 2017 [1 favorite]
→ performance.now() is wholly unnecessary except to developers. Scrap it while the browser isn't in developer mode.
… and many games and videos become flickery and unreliable. It seems to be the go-to way of determining frame rate. Also, this developer mode you speak of: it has cryptographically secure ways of ensuring it's off and stays off? Otherwise, someone will find a way to flick it back on.
posted by scruss at 10:58 AM on February 15, 2017
… and many games and videos become flickery and unreliable. It seems to be the go-to way of determining frame rate. Also, this developer mode you speak of: it has cryptographically secure ways of ensuring it's off and stays off? Otherwise, someone will find a way to flick it back on.
posted by scruss at 10:58 AM on February 15, 2017
… and many games and videos become flickery and unreliable. It seems to be the go-to way of determining frame rate.
Javascript games should be using requestAnimationFrame to dispatch a finished frame to the browser before the next vsync tick.
posted by Talez at 11:03 AM on February 15, 2017 [2 favorites]
Javascript games should be using requestAnimationFrame to dispatch a finished frame to the browser before the next vsync tick.
posted by Talez at 11:03 AM on February 15, 2017 [2 favorites]
flabdablet: "And for what it's worth, there actually exists a one-size-fits-all security measure that works about 10x as well as ASLR ever did, at least judged by how well it protects the average person from having their shit tampered with:
BLOCK ADVERTISING. ALL OF IT.
Very nearly 100% of the malicious crap designed to attack your devices in 2017 gets its foot in your door by having your browser collect it from a subverted advertising server."
Once again, if you have an old machine that can run Linux, set up a Pi-hole instance. I not only use it to block ads, but pretty much any site that annoys me. I also grab lists of known malware domains AND I have just started blocking all of some of the newer TLD's like .download and .online. You can always whitelist specific sites rather easily if needs must.
OTOH, I read an article about a TERRIBLE way EVIL PEOPLE can fingerprint your PC even if you switch browsers. I ran a test in Firefox and Chrome. Did NOT work. Just because this stuff is published does NOT mean it works in the field. (The paper is here).
So I plan on not panicking until we see some real cases of this actually happening.
posted by Samizdata at 11:48 AM on February 15, 2017 [1 favorite]
BLOCK ADVERTISING. ALL OF IT.
Very nearly 100% of the malicious crap designed to attack your devices in 2017 gets its foot in your door by having your browser collect it from a subverted advertising server."
Once again, if you have an old machine that can run Linux, set up a Pi-hole instance. I not only use it to block ads, but pretty much any site that annoys me. I also grab lists of known malware domains AND I have just started blocking all of some of the newer TLD's like .download and .online. You can always whitelist specific sites rather easily if needs must.
OTOH, I read an article about a TERRIBLE way EVIL PEOPLE can fingerprint your PC even if you switch browsers. I ran a test in Firefox and Chrome. Did NOT work. Just because this stuff is published does NOT mean it works in the field. (The paper is here).
So I plan on not panicking until we see some real cases of this actually happening.
posted by Samizdata at 11:48 AM on February 15, 2017 [1 favorite]
(On the downside, Pi-hole does NOT allow you to whitelist advertising by site, since it runs as your DNS forwarder. The best you can do is suspend it while you visit a site you trust. OTOH, it works for EVERY machine on your LAN, even things like game consoles, and it also blocks app ads.)
posted by Samizdata at 11:55 AM on February 15, 2017
posted by Samizdata at 11:55 AM on February 15, 2017
Yes it does. To which the perfectly reasonable response from the Harvard Architecture fans is "suck it up, buttercup."
If we couldn't run arbitrary stuff from RAM at all we wouldn't have e.g. JIT would we? Which is a pretty big deal now and especially in browsers. I was under the impression that modern processors have features to flag memory as non-executable, but can't use them when stuff like that is involved - I'm not a hardware guy at all though so I could be misunderstanding parts of this discussion.
posted by atoxyl at 12:19 PM on February 15, 2017
If we couldn't run arbitrary stuff from RAM at all we wouldn't have e.g. JIT would we? Which is a pretty big deal now and especially in browsers. I was under the impression that modern processors have features to flag memory as non-executable, but can't use them when stuff like that is involved - I'm not a hardware guy at all though so I could be misunderstanding parts of this discussion.
posted by atoxyl at 12:19 PM on February 15, 2017
Here's an idea. performance.now() is wholly unnecessary except to developers.
What? Having access to a reliable monotonically increasing clock is useful in a ton of application contexts. It would be less useful if other clock methods in JS weren't so bad (there's no guarantee that Date.now() timestamps increase at a constant rate, which makes measuring elapsed time reliably impossible).
posted by thefoxgod at 12:58 PM on February 15, 2017
What? Having access to a reliable monotonically increasing clock is useful in a ton of application contexts. It would be less useful if other clock methods in JS weren't so bad (there's no guarantee that Date.now() timestamps increase at a constant rate, which makes measuring elapsed time reliably impossible).
posted by thefoxgod at 12:58 PM on February 15, 2017
Memory unsafe software is the "last mile" of security: there's a ton of it and replacing it is a pain in the ass.
That's a really apt metaphor of why buffer overflow attacks are so easy/prevalent. Thanks!
posted by eclectist at 2:04 PM on February 15, 2017
That's a really apt metaphor of why buffer overflow attacks are so easy/prevalent. Thanks!
posted by eclectist at 2:04 PM on February 15, 2017
tzikeh: Don't panic (yet). Ad blocking was already a good idea, as is rejecting untrusted javascript. The impact of this is likely to be pretty technical. One long-term downside for consumers is that ASLR has been advertised as a key security feature for MSWin and OS X. Now that's no longer the case.
How to explain this shortly?
1. A buffer overflow bug allows for an attacker to write instructions to unauthorized memory.
2. Older forms of memory allocation allowed for an attacker to identify the most vulnerable memory locations.
Result: An attacker could use a buffer overflow bug to run malware, (also called a "payload") with variable effects from crashing the system to total control.
ASLR was a bandaid for #2. But buffer overflow bugs are a major priority for security design with billions of dollars spent identifying them, fixing them, or preventing them. They're also not the only tool attackers have.
posted by CBrachyrhynchos at 2:37 PM on February 15, 2017 [1 favorite]
How to explain this shortly?
1. A buffer overflow bug allows for an attacker to write instructions to unauthorized memory.
2. Older forms of memory allocation allowed for an attacker to identify the most vulnerable memory locations.
Result: An attacker could use a buffer overflow bug to run malware, (also called a "payload") with variable effects from crashing the system to total control.
ASLR was a bandaid for #2. But buffer overflow bugs are a major priority for security design with billions of dollars spent identifying them, fixing them, or preventing them. They're also not the only tool attackers have.
posted by CBrachyrhynchos at 2:37 PM on February 15, 2017 [1 favorite]
I don't think ASLR is "security by obscurity" in the traditional sense of that phrase, since without the benefit of this timing attack one could read the source for the ASLR logic in a particular OS (the "implementation," as I understand that word) without having any leg up on determining the starting address of the heap in practice. The runtime layout is effectively a secret key, it just turns out that it's easily compromised. I agree that it's a pretty weak defense, and I can see it having acted as a crutch that let us hang out in a bad local maximum for a while, but ubiquitous memory safety is one of those hard social problems that requires concerted effort and long-term thinking on the part of a bunch of different actors who are mostly predisposed to self-interested behavior and short-term vision. I can see why it was an appealing solution from a pragmatic perspective.
posted by invitapriore at 4:07 PM on February 15, 2017 [2 favorites]
posted by invitapriore at 4:07 PM on February 15, 2017 [2 favorites]
Also, the best defense against buffer overflow attacks is to use software that's actively maintained, and to install security updates in a timely manner.
posted by CBrachyrhynchos at 4:19 PM on February 15, 2017
posted by CBrachyrhynchos at 4:19 PM on February 15, 2017
The runtime layout is effectively a secret key, it just turns out that it's easily compromised.
It's not even close to cryptographically strong. It's always been a half-assed shit-grade kludge.
If we want a one-size-fits-all mitigation for 99% of stack smashing buffer overflows in badly written C code, there's a much better way to do it than ASLR.
First thing is to get rid of the ridiculous tradition that everything local to activation of a procedure belongs in a single contiguous chunk of memory. It's long been traditional to devote two CPU registers (stack pointer and frame pointer) to point into that memory, though most modern compilers will let you generate code that dispenses with the frame pointer and does everything relative to SP. Even the venerable 8086 had separate registers (SP and BP) for these purposes.
I say we bring back those frame pointers, and devote them to maintaining a data only stack kept in a different MMU segment from the call stack. Keep using the normal stack pointer register to manage the call stack, so that CALL and RETURN instructions still work the same as always; just make sure that the only code that ever writes into that stack is actual CALL instructions (or link register spills, if on an architecture that does CALL using a register for the return address).
Use the frame pointer register to maintain a separate data stack. Start empty data stacks at the lowest address in their MMU segment, rather than the highest address as is traditional for stacks that have to include CPU-saved return addresses; and have the compiler lay out data stack frames so that in any given procedure's stack frame, all the scalar variables are allocated first and array variables after, with the char and wchar_t arrays that are the traditional victims of overflow allocated last of all. And in procedure exit code, zero the first word of the procedure's stack space before deallocating it.
Together, what these rules would do is guarantee that overflowing a local char buffer can at worst destroy another char buffer within the same procedure's local variables, or at best overwrite unallocated RAM that's not used for anything at all; it can't get anywhere near the call stack, so it can never corrupt a return address and disturb control flow. If the overflow is so extensive that it overwrites the whole MMU segment devoted to data stack space, it causes a segfault and crashes the app; denial of service sure, but arbitrary code execution never.
posted by flabdablet at 5:03 PM on February 15, 2017 [3 favorites]
It's not even close to cryptographically strong. It's always been a half-assed shit-grade kludge.
If we want a one-size-fits-all mitigation for 99% of stack smashing buffer overflows in badly written C code, there's a much better way to do it than ASLR.
First thing is to get rid of the ridiculous tradition that everything local to activation of a procedure belongs in a single contiguous chunk of memory. It's long been traditional to devote two CPU registers (stack pointer and frame pointer) to point into that memory, though most modern compilers will let you generate code that dispenses with the frame pointer and does everything relative to SP. Even the venerable 8086 had separate registers (SP and BP) for these purposes.
I say we bring back those frame pointers, and devote them to maintaining a data only stack kept in a different MMU segment from the call stack. Keep using the normal stack pointer register to manage the call stack, so that CALL and RETURN instructions still work the same as always; just make sure that the only code that ever writes into that stack is actual CALL instructions (or link register spills, if on an architecture that does CALL using a register for the return address).
Use the frame pointer register to maintain a separate data stack. Start empty data stacks at the lowest address in their MMU segment, rather than the highest address as is traditional for stacks that have to include CPU-saved return addresses; and have the compiler lay out data stack frames so that in any given procedure's stack frame, all the scalar variables are allocated first and array variables after, with the char and wchar_t arrays that are the traditional victims of overflow allocated last of all. And in procedure exit code, zero the first word of the procedure's stack space before deallocating it.
Together, what these rules would do is guarantee that overflowing a local char buffer can at worst destroy another char buffer within the same procedure's local variables, or at best overwrite unallocated RAM that's not used for anything at all; it can't get anywhere near the call stack, so it can never corrupt a return address and disturb control flow. If the overflow is so extensive that it overwrites the whole MMU segment devoted to data stack space, it causes a segfault and crashes the app; denial of service sure, but arbitrary code execution never.
posted by flabdablet at 5:03 PM on February 15, 2017 [3 favorites]
There is an astonishing amount of just incorrect info in this thread surrounding ASLR.
Modern memory corruption exploitation consists of using leveraging two primitive types: writes and reads. These are generally the bug types you find: the ability to write a value somewhere in memory you're not supposed to be able to, or the ability to read memory from areas you're not supposed to be able to.
Before ASLR, you had a series of hard coded addresses where values would live, and because these were the same across all systems, you could exploit a system with only one bug, a write bug.
ASLR relocates a program a program every time its loaded. So, for example, your stack, heap, and text segment have random base addresses on load. This means you need to leak addresses (using a read primitive) to know where to use your write bug. Thus, ASLR raises the bar from one bug to exploit a system to two bugs*.
ASLR doesn't have to be cryptographically strong, because you can't effectively brute force it in many of the contexts people care about. On a 64 bit system, you have 46 usable userspace addresses. Assume page alignment will reduce it by another 12, then preferred load addresses will reduce by, I don't know, another 12? This still gives you 22 bits of address space to move things around in. This means, on average you'd need 2^21 tries to brute force the address. Now, this is totally doable on modern computers except every time you fail the targets browser crashes. If you go: "Hmm, well the last ten times I tried to open this page I got the sad Chrome window, I wonder what happens if I tried it another two million" then yeah...
ASLR prevents getting code execution in the first place. ROP is not a way around ASLR, ROP is a way around NX/DEP/W^X (all the same thing). Sandboxes are the last-ditch method where you assume the attacker is executing native code on your machine and you try to limit what they have access to by (usually) restricting the syscall/ipc interfaces.
It's amusing to see people lose their shit over this now. Firefox didn't have ASLR for-fucking-ever (2015?) because, if i recall correctly, if the executable was ASLR enabled, it wouldn't be properly detected by Nautilus. Most Linux software on mainstream distros like Ubuntu isn't fully ASLR'd today.
I don't mean to downplay this -- breaking ASLR matters lot in browsers, it's just like shit, where's the outrage at mainstream Linux distros that just never bothered to enable the shit in the first place?
flabdablet: What you described is called safe stack or shadow stack, and exists in clang and visual studio. Unfortunately (fortunately?) most exploitation today, especially in browsers, is heap related and safe stack doesn't really help too much**.
* this isn't strictly true, but we're simplifying here.
** it will help with other things though!
posted by yeahwhatever at 5:31 PM on February 15, 2017 [7 favorites]
Modern memory corruption exploitation consists of using leveraging two primitive types: writes and reads. These are generally the bug types you find: the ability to write a value somewhere in memory you're not supposed to be able to, or the ability to read memory from areas you're not supposed to be able to.
Before ASLR, you had a series of hard coded addresses where values would live, and because these were the same across all systems, you could exploit a system with only one bug, a write bug.
ASLR relocates a program a program every time its loaded. So, for example, your stack, heap, and text segment have random base addresses on load. This means you need to leak addresses (using a read primitive) to know where to use your write bug. Thus, ASLR raises the bar from one bug to exploit a system to two bugs*.
ASLR doesn't have to be cryptographically strong, because you can't effectively brute force it in many of the contexts people care about. On a 64 bit system, you have 46 usable userspace addresses. Assume page alignment will reduce it by another 12, then preferred load addresses will reduce by, I don't know, another 12? This still gives you 22 bits of address space to move things around in. This means, on average you'd need 2^21 tries to brute force the address. Now, this is totally doable on modern computers except every time you fail the targets browser crashes. If you go: "Hmm, well the last ten times I tried to open this page I got the sad Chrome window, I wonder what happens if I tried it another two million" then yeah...
ASLR prevents getting code execution in the first place. ROP is not a way around ASLR, ROP is a way around NX/DEP/W^X (all the same thing). Sandboxes are the last-ditch method where you assume the attacker is executing native code on your machine and you try to limit what they have access to by (usually) restricting the syscall/ipc interfaces.
It's amusing to see people lose their shit over this now. Firefox didn't have ASLR for-fucking-ever (2015?) because, if i recall correctly, if the executable was ASLR enabled, it wouldn't be properly detected by Nautilus. Most Linux software on mainstream distros like Ubuntu isn't fully ASLR'd today.
I don't mean to downplay this -- breaking ASLR matters lot in browsers, it's just like shit, where's the outrage at mainstream Linux distros that just never bothered to enable the shit in the first place?
flabdablet: What you described is called safe stack or shadow stack, and exists in clang and visual studio. Unfortunately (fortunately?) most exploitation today, especially in browsers, is heap related and safe stack doesn't really help too much**.
* this isn't strictly true, but we're simplifying here.
** it will help with other things though!
posted by yeahwhatever at 5:31 PM on February 15, 2017 [7 favorites]
Adguard Adblocker runs on iOS, Android, Mac, Windows. It uses a VPN so ads don't even get through to my machine. Simple to use context menu to control white/blacklists.
So far I get adblocking in iOS Chrome and Twitter and Tumblr.
Am I doing adblocking right?
posted by Jesse the K at 5:34 PM on February 15, 2017
So far I get adblocking in iOS Chrome and Twitter and Tumblr.
Am I doing adblocking right?
posted by Jesse the K at 5:34 PM on February 15, 2017
indubitable: "It's not even just security issues being aggravated by this, a ton of the web is inaccessible in rural areas and developing nations because of this."
And also it sticks to blind users. Even if their screen readers can understand the page imagine having to listen to that crap before they can get to the content.
posted by Mitheral at 7:04 PM on February 15, 2017 [1 favorite]
And also it sticks to blind users. Even if their screen readers can understand the page imagine having to listen to that crap before they can get to the content.
posted by Mitheral at 7:04 PM on February 15, 2017 [1 favorite]
Seconding what yeahwhatever said. ASLR is a mitigation, and while it's important, breaking this mitigation doesn't mean everything is going to hell immediately. There have been many other ASLR bypasses in the past, one for every successful exploit against any modern program. The hooha around this one is mostly technical, because its a cool and clever trick. And of course, because it is a generic ASLR bypass that can't easily be fixed. But by itself it isn't a full exploit; an attacker would still need to find another bug, and possibly more to overcome other kinds of limitations. Not having to worry about ASLR would make things a lot easier for them though, but nowadays ASLR is just another hoop they have to jump through (via an exploit for it) rather than this huge THOU SHALT NOT PASS barrier.
I should also note that ASLR is a mitigation against more than just buffer overflow attacks. It basically makes life harder for the attacker by not allowing them to know in advance where things are in memory. Any kind of exploit that requires knowledge of memory is affected by ASLR. So heap bugs like use-after-frees need ASLR bypasses to work too. That's one reason why ASLR is useful, because its pretty generic, unlike say stack canaries or heap metadata validation.
Anyway, for a normal user, I would recommend against doing anything drastic. Life will go on as usual, more or less. Just make sure you patch your browser often. Actual memory corruption / remote code execution bugs are much more serious and more likely to result in immediate carnage than mitigation defeating bugs.
posted by destrius at 7:17 PM on February 15, 2017 [4 favorites]
I should also note that ASLR is a mitigation against more than just buffer overflow attacks. It basically makes life harder for the attacker by not allowing them to know in advance where things are in memory. Any kind of exploit that requires knowledge of memory is affected by ASLR. So heap bugs like use-after-frees need ASLR bypasses to work too. That's one reason why ASLR is useful, because its pretty generic, unlike say stack canaries or heap metadata validation.
Anyway, for a normal user, I would recommend against doing anything drastic. Life will go on as usual, more or less. Just make sure you patch your browser often. Actual memory corruption / remote code execution bugs are much more serious and more likely to result in immediate carnage than mitigation defeating bugs.
posted by destrius at 7:17 PM on February 15, 2017 [4 favorites]
« Older This beetle bites an ant’s waist and pretends to... | Tradition is based on religion; religion is based... Newer »
This thread has been archived and is closed to new comments
posted by potrzebie at 12:17 AM on February 15, 2017 [1 favorite]