Non-PIC code a security vulnerability..How??

kingkhan2006 · 03-30-2006, 06:49 PM

Hi people.
Buffer overflow , format strings and even return to glibc has enough documentation , exploit code and CVE's listed for a security researchers or searchers .

But if you go through PAX -> mprotect or PAX-> disable text relocations , the only thing you notice a suggestion to ensure every single line of code in your system should be Position Independent .

What is surprising is there doesn't seem to be a single known exploit that reflects how a NON-PIC code can be used to execute shell code attacks.

With or without PAX , How is NON-PIC code vulnerable?

Please answer the question citing or redirecting me to a simple example.

Regards
king khan

unSpawn · 03-31-2006, 04:58 AM

Explanation of Ulrich Drepper’s DSO optimization paper from Diary for wingo, 28 Apr 2005:

Quote:

"(..)text relocations, caused by non-PIC code in shared libraries, are bad, because they prevent those memory pages from being shared. (..) means that the dynamic linker has to make memory pages, which are otherwise read-only, temporarily writable. The period in which the pages are writable is usually brief, only until all non-lazy relocations for the object are handled. But even this brief period could be exploited by an attacker. In a malicious attack code regions could be overwritten with code of the attacker’s choice and the program will execute the code blindly if it reaches those addresses.

During the program startup period this is not possible since there is no other thread available which could perform the attack while the pages are writable. The same is not true if later, when the program already executes normal code and might have start threads, some DSOs are loaded dynamically with dlopen. For this reason creating DSOs with text relocation means unnecessarily increasing the security problems of the system."

Reading Deppers paper, the (excellent) Gentoo docs on PAX and this you can say it's not about exploiting this in the practical sense but about exploitability, trying to close one more loophole. I'm sure that if any exploits exist you can find them yourself. LQ is not the place to promote that kind of stuff.