Slashdot Mirror
Researchers Bypass ASLR Protection On Intel Haswell CPUs (softpedia.com)
An anonymous reader writes: "A team of scientists from two U.S. universities has devised a method of bypassing ASLR (Address Space Layout Randomization) protection by taking advantage of the BTB (Branch Target Buffer), a component included in many modern CPU architectures, including Intel Haswell CPUs, the processor they used for tests in their research," reports Softpedia. The researchers discovered that by blasting the BTB with random data, they could run a successful collision attack that reveals the memory locations where apps execute code in the computer's memory -- the very thing that ASLR protection was meant to hide. While during their tests they used a Linux PC with a Intel Haswell CPU, researchers said the attack can be ported to other CPU architectures and operating systems where ASLR is deployed, such as Android, iOS, macOS, and Windows. From start to finish, the collision attack only takes 60 milliseconds, meaning it can be embedded with malware or any other digital forensics tool and run without needing hours of intense CPU processing. You can read the research paper, titled "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR," here.
... was it ever worth it?
Here's a better idea. Don't run malware.
The Enhanced Mitigation Experience Toolkit, which is offered by Microsoft for the Windows operating system, provides a software implementation of Address Space Layout Randomization (ASLR), in addition to what is or is not provided in hardware, but that's not all. The software also offers Data Execution Prevention (DEP), Structured Exception Handler Overwrite Protection (SEHOP), Certificate Trust (Pinning) and blocks untrusted fonts. Granted, this is an optional add-on for Windows that requires some expertise on the part of the user to make the best use of, but in knowledgeable hands tools like these can be used to further enhance the security of the system by making it that much harder for attackers to successfully inject executable code into the address space of privileged processes.
Apps don't execute code. Since these idiots don't undertstand this, dismiss it as the nonsense it is.
I've been a true blue IT pro foss loonix guy for most of the last 16 years. And every year. Nay. Every 6-10 months some hardware designed to "thwart" crackers, and other crypto attackers goes the way of the dodo.
I think the industry looks at security the wrong way and the lulzsec guys weren't wrong in that ideological rant they made. You can't predict the unpredictable. Firewalls aren't a wall in any meaningful sense. "Software defined" networks are just a catchphrase for networking complex things in a dynamic manner. Intrusion Prevention Systems do not prevent. Hell, if you let your cisco guy deploy it, it wont even log a thing and when it dies you will have no idea why.
Bollocks, Shenanigans and costly Stupidity (don't get me started on "hardware routers" or "storage networks"). This is what I have found in my years in the battlefields, young grasshoppers. And a deeply felt wish that I had chosen archeology instead.
NO SIG
Imagine the infinite ways of using other people's computers without their explicit permission.
I will guarantee can't be hacked electronically and will sell you one.
The grass is always greener...
I wonder how many archeologists with bad pay wish they had become an IT professional instead.
removing the BTB entirely. I've seen libraries rip out faster routines or add some nondeterminism to the latency just so that it could mask such a "hot cache" vulnerability. It seems a bit backward to rip out a performance enhancing capability in the architecture just because of ASLR bypass.
If the NSA says the big US brands they work with are safe, buy them and enjoy the US industry standards.
Stop making networks interesting. Put PR on the internet when the project is done and ready for sale.
Until then keep everything secret.
Doing code work for years on internet facing networks on hardware designed for easy police and security service access is just a big risk.
Too many nations, their staff, ex staff, cults and smart people have the keys or know of the trap doors and backdoors.
Domestic spying is now "Benign Information Gathering"
They attack the kernel ASLR (or some other program running as root).
Without that critical information the summary makes no sense, since what would be the point of defeating ASLR if you can already run arbitrary code?
Browsers might need to be careful that something similar isn't possible via Javascript, but I suspect as long as no sufficiently precise time source are available it should be ok, but that isn't the subject of the paper.
A lot of people have said before that kernel ASLR is crap anyway, and I don't think ASLR was meant to protect much against local attacks.
That puts this into the "interesting, but not very relevant for most" category. If you already are executing malicious code on your machine, I am not sure that the jump to root/kernel permissions makes things all that much worse in most cases, especially since you STILL need to have an exploit.
...again. Provided this screwup is on Broadwell and Skylake, which is not a far fetched possibility *at all*.
Intel SGX is all about running secret code on untrusted processors, and this kind of side-channel allows one to probe inside the SGX container. One of the useful (read: non-DRM-crap) uses for SGX would be to implement secured data+code areas to run crypto-sensitive portions of SSH, GnuPG, etc. Unfortunately, branch probing is good for a lot more than defeating ALSR, you can actually, when one is unlucky, probe into code that is manipulating secrets, thereby leaking bits of private keys, etc.
It is an exploit of the CPU's cache, a cache collision attack, if your data's location is referenced in the "Branch Target Buffer" cache then it is vulnerable, if you can find the location table random locations are meaningless. As such this threatens all software implementations Windows, Linux, whoever does it they are all vulnerable unless they find and implement a way of avoiding the collision or removing themselves from the cache (at a performance cost).
Maybe Intel didn't really have security in mind when the implemented this, is what I am thinking, not being an expert.
TL;DR: because of this bypass ASLR cannot prevent local privilege escalation. but ASLR can still prevent remote access.
The point of ASLR is that it's not easy to determine where the functions are located in memory.
So, if there's an exploit where you can force code to jump at some specific point in memory, you cannot use this exploit to call the function you want because you don't know where they are.
(e.g.: stack smash. Overrun some temporary buffer that is stored on the stack buffer, up to the point where you can overload the return address. So once a function finished, it's doesn't jump back to the caller [it doesn't return] it jumps instead to the address you've overwritten [it jumps to the next function you want to abuse as part of you exploit] )
2 possible situations:
- You've already managed to get (user-level) shell acces (or at least run any payload of your choosing). You want to escalate privileges up to root. You know of a bug in some kernel piece of code that you can try to exploit. ASLR would prevent you from doing it because you don't know where the piece of code is exactly in kernel memory space. So you run the bypass proposed by the researcher and you obtain a list of where is what.
Now you can run your exploit, and gain root.
- You're outside the machine. You want to get remote access. You know a bug in some code (be it kernel or userspace) that could be exploited. But you need to jump into specific function whose precise location in memory you don't know because of ASLR.
So ASLR won't block local privilege escalation anymore (because when you have local access you could defeat ASLR's randomisations)
But ASLR will still block remote access (without local access, you can't get a map of all ASLR-ised functions you need to inject in your remote exploit).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
You should read up on the AS/400 Architecture. So different from the PC word and much more logical, no such thing as device drivers and buffer overflows can't happen.
Only the State obtains its revenue by coercion. - Murray Rothbard
Yes I read the Soltis book recently.
The x86 is collecting so much crap these days much of which doesn't work for anything but marketing and your electrical supplier.
I'm all for IBM sorting out POWER.
Age, Sex, Location....
Religion?
See subject: Stack smashing protection via CPU hardware "shadow stacks" mirroring the "real" stack vs. changes - they do that? It'll stop buffer overflow type attacks & 'stack smashing'... it'd supplement OS + software & compiler protections vs. it as well (along w/ better programming practices).
* I'm personally surprised it's never been implemented!
(Not EXACTLY "on-topic" here but there 'tis...)
APK
P.S.=> It'd work... apk
Re: "...no such thing as device drivers..."
Ah, what the hell do you think a *DEVD is?? (That's a Device Description, for those not familiar with the iSeries, née AS/400 architecture).
The AS/400 couldn't print to non-IBM printers back in the early 90's because the needed Device Descriptions didn't exist. IBM wouldn't make them because they 'only supported IBM equipment' and the OEM printer manufacturers wouldn't make them because the AS/400 market was too small and they didn't have access to the equipment and expertise needed. Finally, IBM relented and created the *DEVD objects needed, but it took years of pressure from the customer base.
For those knowledgeable readers who object and say "oh yes there was a way to print without native *DEVD support", save your breath. I know all about PC/Support hosted printers, emulated printers, OS/2 supported printers and all the rest. They were all hacks and workarounds designed to get around the limitations caused by the absence of native OS/400 support. They increased the complexity of your environment, introduced multiple new failure modes, increased costs, and good luck getting support for those solutions.
Support in the AS/400 world is a big deal, a really big deal. Though there are limited exceptions, the vast majority of the AS/400 customer base hates unsupported solutions. Many won't run unsupported workarounds at all as a matter of policy.
Every 6-10 months some hardware designed to "thwart" crackers
Except this time it is the hardware compromising the software mitigations against crackers. All because of the "relentless pursuit of performance" and "time to market".
You will never have perfect security. There is no such thing. All you can do is put up sufficient roadblocks that a miscreant will give up before they are successful.
And all the security measures in the world arn't going to make a lick of difference if the user opens the door and waves the bad guy in.
No in it doesn't function vs. technical weakness in buffer overflow stack smashing but it does vs. attack sources & malware infiltration/infestation via say, maliciously scripted sites or malware being downloaded + even email malicious payload links blocked out - after all - you CAN'T be harmed by what you CANNOT touch in the 1st place...
* How's that?
APK
P.S=> Yes, I know you're just "unidentifiable ac trolling me" but the point of stopping stack smashing attacks via shadow stack implementation (not in software but rather hardware) is a good idea & method of prevention... apk
"Overrun some temporary buffer that is stored on the stack buffer, up to the point where you can overload the return address" - by DrYak ( 748999 ) on Thursday October 20, 2016 @08:17AM (#53114013)
See subject - Here's a way to do it in "Return Oriented Programming":
pop %ebx
pop %eax
ret
&
mov %eax, (%ebx)
ret
* 1ST pulls 2 values off the stack storing them in the registers ebx & eax ... 2nd writes the contents of eax into the memory address pointed to by ebx.
(Together they let you edit content of any memory address a currently targetted running thread has rights to change via "arbitrary write"...)
Malware's that do 'stack smashing' do this all the time...
APK
P.S.=> Which is WHY I posted what I did to STOP IT GOING ON (done in cpu 'shadow stack' construction comparison mirroring) & YES, it'd work-> https://news.slashdot.org/comments.pl?sid=9791849&cid=53114763/... apk
I said it works & what I did is more than YOU have APK Hosts File Engine 9.0++ SR-4 32/64-bit https://www.google.com/search?... which protects vs. infectors + speeds you up (doing more for less...)
APK
P.S.=> See subject - you fail... apk
See subject: My program stops things like this that must be delivered 1st. Hosts stall that if host-domain name served (9/10 are).
On CET etc.: I never said I INVENTED IT, so quit trying to put words in my mouth I never said fool!
I'm pointing out useful fixes, you're not!
(Which I saw a long time back as useful info in a security data textfile I jot things in & remembered it'd apply here but I had no cited source for it there - does it matter? It works!)
On "sanity" Mr. "SiDeWaLk-ShRiNk of /."?
You troll by unidentifiable ac posts & fail repeating that same mistake over & over vs. me expecting diff. results = a definition of insanity
You're insanity's "ne'er-do-well" poster child (lol).
APK
P.S.=> I've obviously crushed you before - hence, your unidentifiable ac trolling post... apk
(Obscurity. You keep using that word, I do not think it means what you think it means)
ASLR is NOT obscurity.
ASLR is quite the opposite : it's a way to mitigate obscurity.
(Just like a password is NOT security through obscurity).
A kernel without ASLR is obscurity: you count on the attacker not known where the kernel (or any other critical software) stores its code.
Once the address map is known, every single instance of this kernel (or software) everywhere on planet Earth is at risk.
With ASLR (which is, in Linux kernel case, publicly documented and known - exactly as any cryptographic algorithme - the exact opposite of obscurity), every single instance can, based on a small random token (which plays the same role as a password or a private key in a cryptographic system), can manage to hide *its own peculiar instance of stuff* from a potential attacker.
Knowing how ASLR works isn't critical (and in Linux case, it's actually documented).
Knowing the token (=the password) is the critical step.
It's not "Security through Obscurity", it's side channel attack (= managing to guess the security key by using a feature of the Haswell CPU that locally leaks the information - the "clear text").
Security through Oscurity is hoping that nobody actually understands how your magical security solution works under the hood.
If anyone gets to know the internals, the *whole technology* is toast for ever.
Cryptography and other forms of sensible and modern security is the opposite: it counts on a technology that is as widely known and published as possible (so it undergoes as many tests and reviews as possible, to make sure it is sound).
If something is kept secret, it's a small token, a number, a code, a key. Just a piece of data. Not the actual open standard code which will process the data.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]