What is a privilege elevation? It meant that someone who (maliciouslly) obtain higher privilege through some method that is not predicated by programmer.

In order to prevent it, we should avoid giving unnecessary privileges, and validate all input. However, in a imperfect world, just validating everything is not enough, since there are too many things that can not be validated easily.

On most Unix systems, we have a “set uid” bit that can allow subsequent process to run under other credentials. This, however, opens an window that we can potentially allow malicious code to be injected into the system, to obtain higher privileges.

This problem can affect programs in various ways. If you are linking against a library, and want to setuid your program, then the library must either carefully check every input, or prevent being lost with a case that can cause privilege leak.

For instance, in FreeBSD, we have a rtld-elf library that does runtime linking (like DLLs in Windows). Also, we have provided a libmap.conf for conveniency of overriding default shared libraries with other libraries that provides equivalent interfaces.

Linking against shared objects, (or “DLL” in Windows), however, opens a window that can pose you into danger if these DLLs can be easily replaced by an attacker. Recently, we have added a functionality that allows users to override the library with an environment variable LD_LIBMAP.

This has lead to concerns that crackers can exploit this to specify their own crafted shared objects to obtain higher privilege. However, fortunatelly, FreeBSD has guaranteed the problem by only allowing the operation in a trustable way.

In order to implement this, we check issetugid(2) before allowing users to override their shared libraries. issetugid(2) provides the information whether the current process is considered to be “tainted”, say, is created through execve(2) with suid or sgid bit set.

With the check found in rtld.c, the FreeBSD implementation of shared object overriding is secure.