Is my assumption true, that on Unix/Linux, the only way to GAIN root access is to execute a setuid-root file?
In other words, the system calls setuid(), setgid() are all about DROPPING privileges?
Please note that my question is not about exploits.
That's true. The only way for a non-root process (assuming it's running a non-setuid program) to become root is to exec a setuid program. If it's running a set-uid root program, then its effective uid is root and real uid is whoever ran it. It can then do setuid(0) to make its real uid 0.
Related
if /usr/bin/bash has the suid bit set
why does my euid change to root only when I use the -p option like so /usr/bin/bash -p
what does this -p option stand for?
and when you spawn a bash shell from a suid binary why euid is set to root and why not uid?
From the documentation:
-p
Turn on privileged mode. In this mode, the $BASH_ENV and $ENV files are not processed, shell functions are not inherited from the environment, and the SHELLOPTS, BASHOPTS, CDPATH and GLOBIGNORE variables, if they appear in the environment, are ignored. If the shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, these actions are taken and the effective user id is set to the real user id. If the -p option is supplied at startup, the effective user id is not reset. Turning this option off causes the effective user and group ids to be set to the real user and group ids.
This is done because setuid shell scripts have been a common source of security bugs. So the programmer is required to use the -p option to indicate that they really need the privilege escalation, e.g. by using
#!/usr/bin/bash -p
Without this, setting the suid bit on /usr/bin/bash itself would be an enormous security hole, since most scripts don't take the necessary precautions needed when running with elevated permissions.
I have a root server where I disabled login via user root and created another user that is in the sudoer list. So when I want to work on the server I do:
ssh myusername#IP_ADDRESS
On the server:
sudo su
enter my password to get root rights. This worked fine for 6 months now. Today I get this message when doing sudo su:
sudo: no tty present and no askpass program specified
What the hack is happening? What does this error mean and why do I get it?? Without root rights I cannot do so much on the server. Any idea how to fix this?
sudo tries to open /dev/tty for read-write and prints that error if it fails. You've indicated in comments that /dev/tty is missing on your system.
Sudo has an option -S to read the password from standard input instead of /dev/tty. You should be able to run sudo -S to become root.
Regarding how to recover /dev/tty, It's possible that rebooting the server would be sufficient; the system might recreate all devices in /dev during bootup. Alternately, to create a device, you use the mknod command, but you need to know the correct major and minor numbers for the tty device. On an Ubuntu system I have available, I see these entries in /dev:
crw------- 1 root root 5, 1 Apr 16 18:36 console
crw-rw-rw- 1 root tty 5, 2 Sep 24 15:35 ptmx
crw-rw-rw- 1 root tty 5, 0 Sep 24 14:25 tty
In this case, the major number is 5 and the minor number is 0. /dev/console and /dev/ptmx have the same major number. So I'd inspect /dev/console or /dev/ptmx to find the correct major number, then run:
mknod /dev/tty c major 0
where "major" is the correct major number.
After recreating /dev/tty, make sure the permissions are correct:
chmod 666 /dev/tty
It fails, because sudo is trying to prompt on root password and there is no pseudo-tty allocated.
You've to either log-in as root or set-up the following rules in your /etc/sudoers
(or: sudo visudo):
# Members of the admin group may gain root privileges.
%admin ALL=(ALL) NOPASSWD:ALL
Then make sure that your user belongs to admin group (or wheel).
Ideally (safer) it would be to limit root privileges only to specific commands which can be specified as %admin ALL=(ALL) NOPASSWD:/path/to/program
One thing to check is whether the OS thinks that the various processes "have a tty". If you are still having problems, it's probably worth doing this in both the shell within which you run ssh and the shell within which you run sudo. The easy way to check is the command "tty" - if it returns "not a tty", that shell doesn't have a "controlling tty" and cannot open /dev/tty even if it exists in the file system.
Various circumstances can cause a shell to not have been run using a controlling tty, and some of them do not provide any visible warning. E.g., I recently ran into a problem on High Sierra with Emacs shell windows (Cannot open pty under Mac OS High Sierra) -- High Sierra uses a different mechanism for allocating pty's than earlier Mac OS X releases, so if your code isn't reconfigured for it, it will fail to allocate a pty.
OS is Linux SuSE 2.6.16.60-0.21-smp
I have one executable bin file (name is bmu) which has been configured SUID, as shown in below
-rwsr-sr-x 1 root root 14968899 2012-03-29 10:35 bmu
And this program invoke dmidecode inside.
Operation will be ok if it was run by root, but dmidecode invoked will return null if the program was run by non-root user.
What is the reason of this problem and how to fix it?
Edit: Added code and description from comment:
read_fp = popen("dmidecode | grep 'Product Name'", "r");
/* ...... */
chars_read = fread(buffer, sizeof(char), BUFSIZ-1, read_fp);
Return of read_fp is not null, but length of buffer is 0 which there should be some value.
The problem was solved in an unsafe way.
It is not enough to add SUID in the program bmu, dmidecode should also be.
-rwsr-sr-x 1 root root 59504 2006-06-16 22:08 /usr/sbin/dmidecode
The dmidecode program needs access to /dev/mem which ordinary users doesn't have permission for. The most common fix to such a problem is either to do as you already do and make the program SUID, or to add the user to the kmem group (the group owning /dev/mem).
When I use shellcode such as the ones provided here* as payload to some vulnerable program, how is the shell executed as root? I am asking about how the privileges are elevated to root? The shellcode doesn't seem to call setuid or anything to change user.
* http://www.tenouk.com/Bufferoverflowc/Bufferoverflow5.html
Those examples include the following:
mov $70, %al #setreuid is syscall 70
So they're using the setreuid(2) syscall, which sets both the real and effective user IDs of the process:
int setreuid(uid_t ruid, uid_t euid);
In order to execute shellcode you need a vulnerability like a buffer overflow. The shellcode has all of the rights as the running process. So if you exploit a binary that is setuid root like the passwd command or otherwise running as root such as the cupsd daemon process then the attacker will have root access. The kernel can also suffer from a buffer overflow, and root access can be obtained this way as well.
first you need to giving the program as root privileges (use chown and chmod as root). and you need setreuid() for your payload. that's would give you root, if you can exploit the program by other user.
Of course, if your vuln program has an owner root and your shellcode have a setuid(0) syscall, you can execute /bin/sh as root
I have a requirement to run a java jar on a low privilege user on linux.
e.g. If I am currently logged in as a 'root' user and want to execute a shell script that should run with the privileges of a low privileged linux user like 'postix' user account.
Is it possible?
If yes, please post relevant references as I don't know how to do it.
Thanks in advance
Ashish
you can use the sudo command to run the script as another user.
If its set up properly, you can use it like this
sudo -u andrew myprog
will run myprog as the user andrew
Not sure what you mean by priority. If you think about scheduling priority, you can use the nice command to run the script with low priority on the CPU. Being logged as 'root' does not give any scheduling priority.
Besides this, it is always a bad idea to be logged in as 'root'.
I think sudo should do the trick .
You can also create script that will run your app change its owner and set suid bit for it
useful commands: chmode, chown