
Smashing the Z/OS LE "Daisy" Chain for Fun and Cease and Desist Letters - luu
https://www.reddit.com/r/mainframe/comments/400ogh/smashing_the_zos_le_daisy_chain_for_fun_and_cease/
======
munin
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...

------
krylon
Very interesting read!

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. :-?

~~~
js8
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.

~~~
monocasa
>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?

~~~
js8
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.

------
yalue
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?

~~~
legulere
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.

~~~
PeCaN
And on top of that, it only has some weird sort of pseudo-ASLR.

