OpenSUSE Tumbleweed Is Now Built With PIE

[AnAk]

Still not enabled in Arch unfortunately, it was supposed to be finally enabled in October last year but it never happened.

https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html

[tinko]

If im understanding correctly, this seems like the wrong solution to a common problem.

Sounds like trying a hammer on screws.

Could you elaborate?

Either you fix all bugs that make exploits possible which rely on manipulating specific memory locations in the near future (and large parts of the GNU/Linux userland are written in C, so good luck with that) or you want something to mitigate this risk until you get to that point.

[tg--]

If im understanding correctly, this seems like the wrong solution to a common problem.

Sounds like trying a hammer on screws.

Since you're not sure if you understand it correctly (you don't): Maybe the wiser approach would be to assume the groups who invented, implemented, and deploy the technique do actually understand correctly.
It's actually simple: nowadays virtual address spaces are huge, but without PIE you can easily find out where executables are located - and if you know those executables have exploitable bugs, you quickly find out how to reach them. With PIE you can't easily find out, and you're having a much harder time to find them.

Since your hammer/screws analogy doesn't even make the slightest sense here, I'll give you another one:
Imagine a bank's sky scraper, which is well secured to keep people out who shouldn't get in. The sky scraper is built with 1000 windows - and you happen to know one of them has a faulty locking mechanism (maybe because you built it). If all the windows have serial numbers and are built-in in order, you'll know what ladder to bring to break in easily.
But if you make sure each window can be placed in any window opening (PIE), the bank can shuffle the order around (ASLR) and you'll have to figure out which one the defective window is.
The fault in the locking mechanism might be subtle and not easy to find and fix.
Doesn't cost a lot (just make sure every window fits everywhere), and thus is an easy solution for this single (but potentially severe) problem.

Is it ideal? No. Is it valuable? Yes.

[Luke]

Regarding ffmpeg and PIE: an exploit in ffmpeg triggerable by a specially crafted video file can be a remote exploit due to use of ffmpeg by Firefox. If it is not possible for ffmpeg devs to refactor all that old assemby code to be compatable with PIE due to the text relocation issue, than ffmpeg devs will always have to be on the ball to prevent these sorts of exploits in the first place.

I don't see desktop Linux following Android down the route of blocking non-PIE binaries, and even if they did changing that default would be a kernel compilation option away. Would be a real mess. No idea how the Google/ffmpeg deadlock will resolve, but phones normally ship as bought devices with paid (and hardware accelerated) codecs on them anyway, and their own video players.

Somehow I don't see anyone running kdenlive on a phone for high definition video. I could see mplayer/mpv/vlc becoming a factor if phones start shipping with video players that can't play local video files that did not come from a source of DRM video and thus are not in an online database of copyrighted and licensed work. That kind of DRM (presume pirate until proven otherwise) would however make cameras on phones useless, and people care more about their phone camera than about being able to use a whole month's bandwidth on one sitting on Netflix.

[sdack]

If im understanding correctly, this seems like the wrong solution to a common problem.

Sounds like trying a hammer on screws.

It is. It's purely build on hope and buys security a little bit of time at best. It only helps against old malware. There are already hacks around, which work around address space randomization. In the long run does it make it easier for malware, because it no longer needs to work with absolute addresses and no longer needs to recalculate offsets, but can work on its own independent of position.

So will finding pieces of code in memory become easier, because malware no longer needs to deal with absolute addresses, but because it's all relative can it be reduced to a simple byte comparison or even hashing. You don't need to know where i.e. malloc() is, but you only need to know a piece of code, which calls malloc(), search for the code piece up to the function call, and what follows will be the call to malloc() - and you'll have the address to it.

[reimar]

First, a question: does anyone know if this means the -pie -static is FINALLY working? Or will they drop this requirement on any statically linked binaries?

sounds like ffmpeg won't run anymore in Tumbleweed.

Either you (and quite a few others) are completely misunderstanding this, or you have let people tell you lies (or you misunderstood/took their comments out of context, e.g. Gentoo hardened has related but different issues).

First, this is about PIE, not PIC, so it only affects EXECUTABLES, people talking about libraries here are thus completely off.
Second, on 64 bit, ALL libraries have to be PIC (the Linux definition of it, not the "computer science"/pedantic one, which means the library can be placed at a different location, not that it can be done for free/without patching the code with relocations). And for 64 bit, PIE on the FFmpeg binaries has been supported since quite some time, though it seems an easy configure option to enable it has been a recent thing.

Now why do Gentoo hardened and some BSDs have issues with FFmpeg?
For 32 bit: It starts with PIC/PIE it ALWAYS costing a lot of performance due to losing a whole general-purpose register (of 4-6 overall), so spending effort to support it was in custom assembly was not considered very useful work and you'll lose many assembly optimizations. Plus as I remember it by the time people really were asking for it, 32 bit was not all that relevant anymore anyway. Also, ASLR on 32 bit barely works anyway (in browsers, it is justified to say it doesn't work at all), so the benefit is very limited.
For 64 bit: Because they ALSO require libraries/binaries to be free of relocations. While that is reasonable for a hardened system, and aligns with a more "computer science" definition of "position independent code", it is NOT required for ASLR and it is NOT part of what OpenSuSE etc. aim for/require. And there have been efforts to reduce the number of relocations (though I haven't checked lately what the status is). This also applies to 32 bit and makes things almost unusable there. If you wonder why 32-bit is so much worse: It's because it doesn't have PC-relative addressing instructions.

And personally I find it a bit ridiculous just how long this took (just as I find it ridiculous that noexecstack wasn't made default back then, resulting in insecure-by-default for the benefit of an absolute minority and so you still have to specify it if you want to be sure your compiler won't mess up - still causing vulnerabilities today, e.g.: CVE-2017-1000376), MPlayer switched to that by default on 64 bit in 2012 according to the source history. I'll also add the the toolchain and its weird bugs (like -pie suddenly breaking if you also add -static, so you need a special case for it) were a bigger issue in enabling it than the code, even for FFmpeg which seems to have such a horrible reputation on it.

[reimar]

assemby code to be compatable with PIE due to the text relocation issue

For any TL;DR on my other long comment: PIE/PIC - at least on non-hardened Linux - does NOT require "free of .text relocations", thus invalidating that whole comment and others like it.

[GrayShade]

It's actually simple: nowadays virtual address spaces are huge, but without PIE you can easily find out where executables are located - and if you know those executables have exploitable bugs, you quickly find out how to reach them. With PIE you can't easily find out, and you're having a much harder time to find them.

To be fair, non-PIE code doesn't prevent ASLR, but text relocations must then be used. It works (this is how Windows does it), but it has some trade-offs like slower loading, and higher memory usage because code pages can no longer be shared between processes. PIE, on the other hand, has a 10% or more run-time performance overhead on x86 and around 5% on x64.

[reimar]

There are already hacks around, which work around address space randomization.

I know of basically 3 approaches, and they are not as gloomy as you make it out, and could more be described as "if your basic design choices are stupid enough even ASLR can't save you".
The ones I know are:
1) Information leak bugs. Exploit code can just ask for the ASLR'd addresses remotely somehow. In that case, at least you need to critical bugs instead of just 1 to write an exploit...
2) Stupid ASLR implementations. Applies to all 32-bit ones (just not enough bits), Windows (just doesn't use enough bits even on 64 bit), Android (only randomizes once at boot, so you potentially get infinite tries, plus uses too few bits, instant-kill double-whammy). Linux is kind of ok, but should use a few more mostly due to 3). Yes, despite using Linux Android broke something that works in Linux.
3) Programs running basically arbitrary untrusted code from a remote server and letting it allocate multiple GBs of virtual memory. That essentially means browsers etc. running JavaScript without any memory constraints on it (or using a badly chosen allocator). Here a timing-attack becomes possible because that huge multi-GB allocation that the browser allowed the JavaScript to do (why on earth do they do that?!?) makes it possible to hunt down the ALSR bits one by one, like a number lock that lets you feel when one of the rings is in the right place. Luckily so far at least, these are in the "why did you needlessly make it easy for attackers?" realm. Ok, for Firefox. For Chrome it was actually a case of "oops, you were too clever for your own good and your clever memory allocation strategy actually made it easier for attackers instead of harder as you intended".

Anything else you know about that would really change this?

[reimar]

To be fair, non-PIE code doesn't prevent ASLR, but text relocations must then be used. It works (this is how Windows does it)

There is no difference between Windows and Linux here. The difference and point of confusion on Linux is that OS, toolchains etc. define PIE as just "relocatable" while most people in this thread like you define it as "relocatable without .text relocations". That pretty much confuses and sometimes makes impossible any discussion on the subject.