Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Let's supose i have an executable file a.exe and it uses stdlib for some operations. Let's suppose an attacker changes the system stdlib to a "malicious" stdlib. The implications of this might be very bad, specially if the a.exe has SUID permissions. What are the main mechanisms already in place to avoid fake code loading?

share|improve this question
I'd assume that on a properly configured system a SUID executable should only load libraries from locations that can't be written to by an untrusted user. – CodesInChaos Jun 16 '13 at 18:45
up vote 3 down vote accepted

Code signing and ACL'ing the system locations are two mechanisms. windows won't load DLL's or EXE's that aren't signed by the Windows code signing key for system calls. Windows also periodically verifies the state of the files by making sure only code-signed file are present. Further, the default ACL's prevent writing to the system directories that store these DLL's and EXE's unless you're an administrator.

Windows has no real notion of protecting against administrators.

share|improve this answer
i forgot to mention that i was referring to Unix systems. I guess in Linux one just can ACL the libraries. Are there any other mechanisms in use? – danieltorres Jun 16 '13 at 22:14
The "a.exe" kind of made it a bit confusing. ;) – Steve Jun 17 '13 at 4:15
Found out that there is always the possibility of using integrity check tools like Integrit. – danieltorres Jun 18 '13 at 20:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.