script-as-root-via-php - doesn't work without a c program and SUID bit!
Setting the sticky bit tells Unix that once the concerned application is executed, it should remain in memory.
the setuid bit is disabled on a lot of *nix implementations due the massive security holes it incurs.
SUID stands for Set User ID
This means that if the SUID bit is set for any application then your user ID would be set as that of the owner of application/file rather than the current user, while running that application.
e.g. an EXE whose owner is root and the SUID bit set, even when run by a normal user, will
"run as root" and therefore be able to do very serious things and access forbidden places
This is a security feature as an alternative to giving SU/sudo permissions for something that
a super user knows normal users need to run regularly
(but do not need to modify/customize or otherwise access),
e.g. reading the access.log or copying to a mounted windows partition
THUS the user can ONLY do what's been written in the script (and can't modify the script).
BE CAREFUL about using SUID on scripts that take parameters (buffer overload exploits!)
NOTE that
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
chmod a+s /usr/bin/xmms
4000 SETUID Exe with this bit set will run with effective uid of the file owner.
e.g. chmod 4550 sets owner & group to be able to read & execute the file/script
NOTE no permission has been given to "other users"
chown root:gname NOTE that the GROUP then is the only one who gets the owner uid elevation
NOTE: SGID bit for a file sets your group ID to the file's group
NOTE if you have colors enabled it will be highlighted in red
chmod 4755 addusers.sh
(or)
chmod u+s addusers.sh
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Note that SETUID and SETGID flags on Directories mean that new files/subdirs inherit
the permissions of the parent (including the SETGUID/SETGID)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
POSSIBLE EXPLOITS OF SUID
If the program calls any other programs using the system() function call, the hacker may be able to fool it by changing IFS
If the program contains a line that looks like this:
system("/bin/date")
and the hacker changes IFS to '/' the shell will then interpret the proceeding line as:
bin date
Now, if the hacker has a program of his own in the path called "bin" the suid program will run his program instead of /bin/date.
create a symbolic link to the program named "-i" which will cause the interpreter shell (/bin/sh) to start up in interactive mode (only works on Shell Scripts)
% ln suid.sh -i
% -i
Fortunately this security hole can easily be closed by making the
first line:
#!/bin/sh -
The `-' signals the end of the option list: the next argument `-i'
will be taken as the name of the file to read commands from, just
like it should!
Sending BAD input to the SUID program
suidprog ; id
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
One way of solving this problem is to call the shell script from a program that can use the setuid bit. For example, here is how you would accomplish this in a C program:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
int main()
{
setuid( 0 );
system( "/path/to/script.sh" );
return 0;
}
gcc runscript.c -o runscript