The first "instruction" of your program is the last address on the stack, in the list of addresses you pushed to the stack.
You are executing code, but you did not inject any executable code, you did not need to modify any existing code pages (which are probably read only), you did not need to attempt to execute code out of a data page (which is probably marked non executable).
Address Space Layout Randomization is a way to prevent the "return oriented programming" attack. When a process is launched, the address space is randomly laid out so that the attacker cannot know which address in memory the std C lib printf function will be located at -- in this process.
Now let's think about the kernel. If you could know all of the addresses of important kernel routines, you could potentially execute a "return oriented programming" attack against the kernel with kernel privileges. Without modifying or injecting any kernel level code. These hardware vulnerabilities allow user space code to deduce information about kernel space addresses.
Now that's a lot of hoops to jump through in order to execute an attack. But there are people prepared to expend this and even more effort in order to do so. Well funded and well staffed adversaries who would stop at nothing in order to access more and better pr0n collections.
> If you could know all of the addresses of important kernel routines, you could potentially execute a "return oriented programming" attack against the kernel with kernel privileges. Without modifying or injecting any kernel level code.
The user <-> kernel transition is mediated (on x86-64) with the SYSCALL instruction, which jumps to a location specified by a non-user writable MSR. How does return-oriented programming work in that case?
The crucial point here being that there must already be an existing overflow vulnerability in the kernel. Knowing all the addresses is no use if you can't force execution to go to them.
AIUI, the present circumstances are:
- there exists a public PoC from some researchers of side-channel leaking kernel address information into userland via JavaScript which may be unrelated
- there exists a Xen security embargo that expires Thursday that might be unrelated
- AWS and Azure have scheduled reboots of many things for maintenance in the next week, which seems unlikely to be unrelated to the Xen embargo
- a feature that appears to be geared toward preventing a side-channel technique of unknown power has been rushed into Linux for Intel-only (both x86_64 and ARM from Intel)
- a similar class of prevention technique has been landed in Windows since November for both Intel and AMD x86_64 chips (no idea about ARM)
- the rush surrounding this, and people being amazingly willing to land fixes that imply a 5-30% performance impact, strongly suggest that unlike almost every major CPU bug in the last decade, you can't fix or even work around this with a microcode update for the affected CPUs, which is _huge_. The AMD TLB bug, the AMD tight loop bug that DFBSD found, even the Intel SGX flaws that made them repeatedly disable SGX on some platforms - all of them could be worked around with BIOS or microcode updates. This, apparently, cannot. (Either that or they're rushing out fixes because there's live exploit code somewhere and they haven't had time to write a microcode fix yet, but O(months) seems like they probably concluded they outright can't, rather than haven't yet.)
- Intel issued a press release saying they planned to announce this next week after more vendors had patched their shit, which lends me more cause to believe that the Xen bug might be the same one [1]
- Intel claims in the same PR that "many types of computing devices — with many different vendors’ processors" are affected, so I'll be curious to see whether non-Intel platforms fall into the umbrella soon
- macOS implemented partial mitigations in 10.13.2 and apparently has some novel ones coming up in 10.13.3 [2]
- someone reasonably respected claims to have a private PoC of this bug leaking kernel memory [3]
- ARM64 has KPTI patches that aren't in Linus's tree yet [4] [6] ([6] is just a link showing the patches from 4 aren't in Linus's tree as of this writing)
- all the other free operating systems appear to have been left out of the embargoed party (until recently, in FBSD's case), so who knows when they'll have mitigations ready [5]
- So far, Microsoft appears to have only patched Windows 10, so it's unknown whether they intend to backport fixes to 7 or possibly attempt to use this as another crowbar to get people off of XP 2.0
- Update: Microsoft is pushing an OOB update later today that will auto-apply to Win10 but not be forced to auto-apply on 7 and 8 until Tuesday, so that's nice [7]
[1] - https://newsroom.intel.com/news/intel-responds-to-security-r...
[2] - https://twitter.com/aionescu/status/948609809540046849
[3] - https://twitter.com/brainsmoke/status/948561799875502080
[4] - https://patchwork.kernel.org/patch/10095827/
[5] - https://lists.freebsd.org/pipermail/freebsd-security/2018-Ja...
[6] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
[7] - https://www.theverge.com/2018/1/3/16846784/microsoft-process...
Seems that Google/Project Zero felt the need to go ahead and break embargo. Worth adding to the above list of news sources.
If you read the article you quoted:
> We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation. The full Project Zero report is forthcoming (update: this has been published; see above).
Just from public Gooogling, I believe it may have been the Register who tried to get in on the scoop, and broke the embargo:
https://www.theregister.co.uk/2018/01/04/intels_spin_the_reg...
My checking doesn't show any of those three explicitly listed in Apple's security updates up through 10.13.2/2017-002 Sierra.
EDIT: This post[2] discusses the specific speculative execution cache attack and claims there is a JavaScript PoC (but doesn't cite a source for that claim)
[1] https://www.youtube.com/watch?v=ewe3-mUku94
[2] https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoA...
Also, RUH-ROH. https://twitter.com/brainsmoke/status/948561799875502080
ASLR, PIC (position independent code: chunks of the binary move around between executions), and RELRO (changing the order and epermissions of an ELF binaries headers: a common ROP pattern is to set up a fake stack frame and call a libc function in the ELFs Global offset table) are all mitigations against ROP, but none solve the underlying problem.
The reason ROP exists is that x86-64 use a Von Neumann architecture, which means that the stack necessarily mixes code (return addresses) and data. The only true solution is an architecture that keeps these stacks separate, such as Harvard architecture chips.
As for bypassing the aforementioned mitigations...
ASLR: Only guarantees that the base address changes. Relative offsets are the same. So to be able to call any libc function in a ROP chain, all you need is a copy of the binary (to find the offsets) and to leak any libc function address at runtime. There are a million ways for this data to be leaked, and they are often overlooked in QA. Once you have any libc address, you can use your regular offsets to calculate new addresses.
PIC: haven't yet dealt with it myself, but you can use the above technique to get addresses in any relocated chunk of code, but I think you'll need to leak two addresses to account for ASLR and PIC.
RELRO: This makes the function lookup table in the binary read only, which doesn't stop you from calling any function already called in the binary. Without RELRO, you can call anything in libc.so I think, but with RELRO you can only call functions that have been explicitly invoked. This is still super useful because the libc syscall wrappers like read() and write() are extremely powerful anyway. Full RELRO (as opposed to partial RELRO) makes the procedure linkage table read only as well, which makes things harder still.
If this is the kinda thing that interests you, I heartily recommend ropemporium.com which has a number or ROP challenge binaries of varying difficulty to solve. If you're not sure where to start, I also wrote a write-up for one of the simpler challenges [1] that is extremely detailed, and should be more than enough to get you started (even if you have me experience reversing or exploiting binaries)
Disclaimer: I'm just some dipshit that thinks this stuff is fun, if I've made a mistake in the above please let me know. I also haven't done any ROP since I wrote the linked article, so im probably forgetting stuff.
[1] https://medium.com/@iseethieves/intro-to-rop-rop-emporium-sp...
Are those kernel logical addresses?
This seems very wrong. I'm not aware of any privilege isolation in Windows relying on the secrecy of any value. Security tokens have opaque handles for which "guessing" makes no sense. Are you aware of anything?
1. Read the root ssh private key from the openssh deamons kernel pages maintaining the crypto context and ssh into the system
2. Read a sudo auth key generated for someone using sudo and then use that to run code as a root user
3. Read the users password's whenever a session manager asks the users to reauth
4. If running in AWS/GCP inside a container/vm meant to run untrusted code, read the cloud provider private keys and get control on account
5. RCE to ROP powered privilege escalation exploit seems reasonable...
6. Rowhammer a known kernel address (since you can now read kernel memory) to flip some bits to give you root
Also remember running JS is basically RCE if you can read outside the browser sandbox, ads just became much more dangerous...
Incidentally, this seems to indicate that zero-copy I/O is actually a security improvement as well, not just a performance improvement?
I am not really sure how/if zero copy may/may not solve this problem.
If this bug only allows reading kernel pages, zero copy may actually help if the unprivileged user can't read your pages, but from the small amount of available description it looks like it can read any page, but kernel pages are more interesting because thats a ring lower and which is why all the focus is on that.
I am fairly certain there is more protection against being able to read memory owned by process on a lower ring level so zero copy may be a bad idea for security critical data.
And based on the disclosure that google published, looks like any memory can be read
I'm cursed when it comes to timing. It's like when I bought that house in 2007, held onto it waiting for the market to recover, then tried to sell it only to find out my tenants had been using it to operate a rabbit-breeding business for years and completely trashed the place (thank you, useless property manager), forcing me to sell it at a loss anyway (6 months ago).
Also, I hate rabbits now. And I veered off topic, sorry.
Well I guess you're not the right person to without about a great ninja-rockstar position at our new RaaS startup.
/one has to joke sometimes to avoid crying over taking a 30% hit in costs... over a stupid CPU bug
sudo cat /dev/mem
I'm having a hard time understanding why this is worse than any other local root escalation bug except for the consequences of the necessary patch.
EDIT: I see that /dev/mem is no longer a window on all of physical RAM in a default secure configuration. Is it true that there's no way for root to read kernel memory in a typical Linux instance? If so, the severity of this issue makes more sense to me.
> I'm having a hard time understanding why this is worse than any other local root escalation bug except for the consequences of the necessary patch.
It's not, as far as I'm aware. The fact that the patch has perf consequences is why it's such a big deal.
a) It would allow any non-root process to read full memory, including the kernel and other processes, or
b) It would allow one cloud VM to read full memory of other cloud VMs on the same physical machine, or
c) With enough cleverness, it would allow even sandboxed Javascript on a web page to read full memory of the computer that it is running on.
Based on all the hoopla around the linux kernel patches the thinking is : yes it can. Or VM escape. Or both.
>>attack that would be almost expected in a processor with speculative execution unless special measures were taken to prevent it.
if you're going to put in features with expected attacks you should definitely be putting in features to prevent it , and if it is an expected attack it shouldn't be special measures it should just be an inherent part in introducing the feature.
Doesn't multi-user timesharing and virtualization predate every modern CPU and OS though?
At first, computers were very expensive, and so were shared between many users. Mainframes, UNIX, dumb terminals, etc.
Then computers became cheap. Users could each have their own computer, and simply communicate with a server. Each business could have their own servers co-located in a datacenter.
Then virtualization got really good, and suddenly cloud servers became viable. You didn't have to pay for a whole server all the time, and if demand rapidly increased you didn't need to buy lots of new hardware. And if demand decreased you didn't get stuck with tons of useless hardware.
The second stage (dedicated servers) was the case when speculative execution was implemented. We're currently in the third stage, but Intel haven't changed their designs.
Indeed, this reminds me of cache-timing attacks, which probably can be done on every CPU with any cache at all --- and they've never seemed to be much of a big deal either.
The thing is, AMD probably very narrowly just missed this one --- if they did more aggressive speculative execution, they would be the same.