The third and absolutely worst case scenario is when the eip can be controlled to execute
malicious code at the system or root level. In Unix systems, there is only one
superuser, called root. The root user can do anything on the system. Some functions on
Unix systems should be protected and reserved for the root user. For example, it would
generally be a bad idea to give users root privileges to change passwords, so a concept
called SET User ID (SUID) was developed to temporarily elevate a process to allow some
files to be executed under their owner??™s privileged level. So, for example, the passwd
command can be owned by root and when a user executes it, the process runs as root.
The problem here is that when the SUID program is vulnerable, an exploit may gain the
privileges of the file??™s owner (in the worst case, root). To make a program an SUID, you
would issue the following command:
chmod u+s
or chmod 4755
The program will run with the permissions of the owner of the file. To see the full ramifications
of this, let??™s apply SUID settings to our meet program. Then later when we
exploit the meet program, we will gain root privileges.
#chmod u+s meet
#ls -l meet
-rwsr-sr-x 1 root root 11643 May 28 12:42 meet*
The first field of the last line just shown indicates the file permissions.
Pages:
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323