For this example, let us assume that the target system is connected to the Internet, and we are able to obtain root privileges on it. We also assume that we have an unprivileged account on our system, and it has a dynamically loaded kernel – means modules are added to the kernel at run-time through the program loadmodule. The important point to note is that the program loadmodule is privileged because it updates the kernel tables, and therefore, it can allow us, an unprivileged user, to execute a privileged process.
As already mentioned above, the program loadmodule loads the module dynamically. To load the module, the program loadmodule first validates the module as being a dynamically loadable module, and then invokes the dynamic loader ld.so to load the module. The program loadmodule also uses another program, arch, to determine the architecture of the system. The program loadmodule invokes the programs, ld.so and arch, at path “/bin/arch” and “/bin/ld.so” through a library function system.
At this point, we assume that a library function system does not reset any part of the environment. We also assume that in a system call, the environment in which we execute loadmodule, is passed to the subprocesses, and these subprocesses are run as root. Based on our assumption, we set the PATH variable to have “.” as the first directory to force our environment to look for programs in our local directory first, and then in system directories.
The library function system invokes the command interpreter sh. The IFS environment variable has as its value characters used to separate words in commands that sh executes. At this point, we change the value of IFS to include “/”, and reset PATH and IFS environment variables. Now to verify the penetration in a UNIX system, we can write a small program that prints out its effective UID, name it bin, move it to the current working directory, and run loadmodule program. If everything goes right then the process shall print its effective UID as 0 (root).