02-12-2016, 08:01 AM
(This post was last modified: 02-12-2016, 08:02 AM by Barracuda72.)
(02-12-2016, 05:12 AM)xoft Wrote: This is all fine as long as you have *const* data. The problem is, normally you don't. Quite a few programs have a global "buffer" object of a kind that they use for whatever buffering is needed, naturally it's stored in the writable data section. But on Windows, this still means code cannot execute from that location, so attacks cannot simply stuff data into that buffer and make it execute. On Linux, such an attack vector (oh so common for all the zero-day exploits) is perfectly viable. That, in my opinion, is very unsafe.Try to remove const qualifier from your code and see what happens. I will predict you: Segmentation fault. Why? Well, try to figure by yourself, it's not very interesting to read someone's ready explanation, don't you think? =D You can find an answer by looking at readelf output on binary; pay attention to the section main belongs in both cases and figure out where each section is loaded in memory, especially to which segment.
In short, there is no way to run modifiable data as code on Linux. You can run constant data, and it's okay: that data is defined on compilation time and can even be viewed as a part of code itself. It can't be modified. And you can have read-write data, but you will not be able to run it. Never. Yes, there are some tricks to surpass that (mremap), but it must be done by application manually. In Windows there too are some techniques for that as I remember (VirtualProtect or so), but I can't say exactly, I never done it on Windows.
To the last: Why do you really though that people so experienced as Linux kernel and Glibc developers can be stupid enough to allow execution of dynamically changeable data? It's very unclear for me...