this is a really cool read, well put together and very thorough, but near the end the author betrays a startling amount of naïveté:
> Considering how simple the PoC is, I hope it's clear that in order to be able to exploit a vulnerability, the planets really need to align. The vuln needs to exist, you need to somehow figure out how to craft the payload (hard if you're not on the system, and have access to source code, compile listings, and a debugging session), and get the payload on the system. Then, when you have arbitrary code execution, you need to know how the system is set up to do interesting stuff. Open sockets, create files, edit files, delete files, what have you.
This is not a good conclusion to come to. The overall, high level conclusion is that the hardware that Z/OS runs on still overlays code and data and has some rudimentary memory protections, but is not memory safe by design and can still be exploited via direct code injection or return to libc / ROP. Relying on the secrecy of the system (its configuration, code, and hardware) is not a strong guarantee as motivated attackers can defeat this.
Or to put another way: for reliable x86 exploitation, the planets also need to align, but attackers make them align regularly and have for 20 years...
During my training, I worked on a BIND4->BIND9 transition in a mainframe team and given the honourable task of looking for ways to make the configuration more secure.
I did quite a bit of reading back then, and I think I kind of remember reading something about z/Architecture having all the pieces in place to provide W^X-style memory protection, but the OS not using it (at least not z/OS). This article seems to say the opposite. Now I am confused if I mis-remember this detail or if the article I read back then was wrong. :-?
If anything didn't happen in the past couple years, the article is correct. z/Architecture doesn't have non-executable memory nor ASLR. The reason I think is in part that they don't have a free bit on each page descriptor to use.
Also, many mainframe programs are really old, and some may still rely on self-modification in unknown ways. And having ASLR would (IMHO) make debugging really painful, because they still rely on assembler programs a lot.
z/OS (which drives development of z/Architecture) is kind of Australia of operating systems. Early independent evolution -> lot of weird and backward stuff there.
>and some may still rely on self-modification in unknown ways
To the point that they have the EX instruction. It's an indirect logical or and execute single instruction to allow for re enterent self modifying code. How can you even begin to W^X given that you have that instruction?
I don't think EX typically accesses writable memory, so that wouldn't be a big problem (and hardware could actually enforce that target of EX is in executable storage). It's used as a workaround to have variable portion of instructions that aren't normally variable.
The actual non-reentrant code is becoming less common, but it still happens sometimes.
Although I think it could be possible to implement that writable pages cannot be executed via a special bit in PSW. Not sure about practical implications to z/OS, though.
Holy crap. If I'm reading this correctly, Z/OS servers do not support non-executable memory? The essential anti stack-smashing protection that was even added to Windows XP in 2004?
Even worse: If I understand "z/Architecture does not feature executable space protection" right, you can even just overwrite the function that is called next directly.
> Considering how simple the PoC is, I hope it's clear that in order to be able to exploit a vulnerability, the planets really need to align. The vuln needs to exist, you need to somehow figure out how to craft the payload (hard if you're not on the system, and have access to source code, compile listings, and a debugging session), and get the payload on the system. Then, when you have arbitrary code execution, you need to know how the system is set up to do interesting stuff. Open sockets, create files, edit files, delete files, what have you.
This is not a good conclusion to come to. The overall, high level conclusion is that the hardware that Z/OS runs on still overlays code and data and has some rudimentary memory protections, but is not memory safe by design and can still be exploited via direct code injection or return to libc / ROP. Relying on the secrecy of the system (its configuration, code, and hardware) is not a strong guarantee as motivated attackers can defeat this.
Or to put another way: for reliable x86 exploitation, the planets also need to align, but attackers make them align regularly and have for 20 years...