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).
Related
I'm writing a basic char device driver for Linux kernel.
For this, the code flow I have considered is as follows:
alloc_chrdev_region() -> to use dynamic allocation of major number
class_create() -> to create device class in sysfs
device_creat() -> to create device under /dev/
cdv_init() -> to initialize char device structure
cdev_add() -> to add my device structure in kernel
I have added read, write, open, release methods in code.
When I try to read device file under /dev/ my read method is called.
But when I try to write on /dev/ file using echo it gives error
"bash: /dev/scull: Permission denied"
I have checked permissions of file using ls -l, and I have permissions to read or write on this file.
This problem occurs for every device driver module I have written. It works well in on another machine.
I'm working on ubuntu 15.10, custom compiled kernel 4.3.0
the result of ls -l /dev/scull:
crw------- 1 root root 247, 0 Dec 30 18:06 /dev/scull
the exact command I used to open the file
$ sudo echo 54 > /dev/scull
the source code for the open implementation
ssize_t scull_write(struct file *filp, const char __user *buf, size_t count, loff_t *f_pos){
pr_alert("Device Written\n");
return 0;
}
Behavior I'm seeking here is, I should be able to see 'Device Written' in dmesg ouput?
I assume that you are normally not root on your bash shell. Then this command line
sudo echo 54 > /dev/scull
does not what you think. The command is executed in two steps:
The bash setups the output redirection, i.e., it tries to open /dev/scull with the current user privileges.
The command sudo echo 54 is executed whereas stdout is connected to the file.
As you have no write-permissions as non-root user, the first step fails and the bash reports
"bash: /dev/scull: Permission denied"
You must already be root to setup the output redirection. Thus execute
sudo -i
which gives you an interactive shell with root privileges. The you can execute
echo 54 > /dev/scull
within that root shell.
I know the thread is too old to answer but just in case if someone wants to know alternative method without switching to root user, here is the solution:
sudo bash -c 'echo "54" > /dev/my_dev'
I wanted to note that on your system only root (file owner) has read / write permissions. Your (normal) user account has not! So another (fast) solution would be to give all users read / write permissions.
Probably this is not the safest solution! Only do this in your test environment!
sudo chmod a+rw /dev/scull
But now you test your module with your user account (without sudo)
echo "hello, world!" > /dev/scull
cat < /dev/scull
You can do so while going root with the command
sudo su
and then going into the /dev folder and enter your command (to save data into /dev/scull).
cd /dev
echo 54 > scull
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.
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.
I wrote a small C utility called killSPR to kill the following processes on my RHEL box. The idea is for anyone who logs into this linux box to be able to use this utility to kill the below mentioned processes (which doesn't work - explained below).
cadmn#rhel /tmp > ps -eaf | grep -v grep | grep " SPR "
cadmn 5822 5821 99 17:19 ? 00:33:13 SPR 4 cadmn
cadmn 10466 10465 99 17:25 ? 00:26:34 SPR 4 cadmn
cadmn 13431 13430 99 17:32 ? 00:19:55 SPR 4 cadmn
cadmn 17320 17319 99 17:39 ? 00:13:04 SPR 4 cadmn
cadmn 20589 20588 99 16:50 ? 01:01:30 SPR 4 cadmn
cadmn 22084 22083 99 17:45 ? 00:06:34 SPR 4 cadmn
cadmn#rhel /tmp >
This utility is owned by the user cadmn (under which these processes run) and has the setuid flag set on it (shown below).
cadmn#rhel /tmp > ls -l killSPR
-rwsr-xr-x 1 cadmn cusers 9925 Dec 17 17:51 killSPR
cadmn#rhel /tmp >
The C code is given below:
/*
* Program Name: killSPR.c
* Description: A simple program that kills all SPR processes that
* run as user cadmn
*/
#include <stdio.h>
int main()
{
char *input;
printf("Before you proceed, find out under which ID I'm running. Hit enter when you are done...");
fgets(input, 2, stdin);
const char *killCmd = "kill -9 $(ps -eaf | grep -v grep | grep \" SPR \" | awk '{print $2}')";
system(killCmd);
return 0;
}
A user (pmn) different from cadmn tries to kill the above-mentioned processes with this utility and fails (shown below):
pmn#rhel /tmp > ./killSPR
Before you proceed, find out under which ID I'm running. Hit enter when you are done...
sh: line 0: kill: (5822) - Operation not permitted
sh: line 0: kill: (10466) - Operation not permitted
sh: line 0: kill: (13431) - Operation not permitted
sh: line 0: kill: (17320) - Operation not permitted
sh: line 0: kill: (20589) - Operation not permitted
sh: line 0: kill: (22084) - Operation not permitted
pmn#rhel /tmp >
While the user waits to hit enter above, the process killSPR is inspected and is seen to be running as the user cadmn (shown below) despite which killSPR is unable to terminate the processes.
cadmn#rhel /tmp > ps -eaf | grep -v grep | grep killSPR
cadmn 24851 22918 0 17:51 pts/36 00:00:00 ./killSPR
cadmn#rhel /tmp >
BTW, none of the main partitions have any nosuid on them
pmn#rhel /tmp > mount | grep nosuid
pmn#rhel /tmp >
The setuid flag on the executable doesn't seem to have the desired effect. What am I missing here? Have I misunderstood how setuid works?
First and foremost, setuid bit simply allows a script to set the uid. The script still needs to call setuid() or setreuid() to run in the the real uid or effective uid respectively. Without calling setuid() or setreuid(), the script will still run as the user who invoked the script.
Avoid system and exec as they drop privileges for security reason. You can use kill() to kill the processes.
Check These out.
http://linux.die.net/man/2/setuid
http://man7.org/linux/man-pages/man2/setreuid.2.html
http://man7.org/linux/man-pages/man2/kill.2.html
You should replace your system call with exec call. Manual for system say's it drops privileges when run from suid program.
The reason is explained in man system:
Do not use system() from a program with set-user-ID or set-group-ID
privileges, because strange values for some environment variables might
be used to subvert system integrity. Use the exec(3) family of func‐
tions instead, but not execlp(3) or execvp(3). system() will not, in
fact, work properly from programs with set-user-ID or set-group-ID
privileges on systems on which /bin/sh is bash version 2, since bash 2
drops privileges on startup. (Debian uses a modified bash which does
not do this when invoked as sh.)
If you replace system with exec you will need to be able to use shell syntax unless you call /bin/sh -c <shell command>, this is what is system actually doing.
Check out this link on making a shell script a daemon:
Best way to make a shell script daemon?
You might also want to google some 'linux script to service', I found a couple of links on this subject.
The idea is that you wrap a shell script that has some basic stuff in it that allows a user to control a program run as another user by calling a 'service' type script instead. For example, you could wrap up /usr/var/myservice/SPRkiller as a 'service' script that could then just be called as such from any user: service SPRkiller start, then SPRkiller would run, kill the appropriate services (assuming the SPR 'program' is run as a non-root user).
This is what it sounds like you are trying to achieve. Running a program (shell script/C program/whatever) carries the same user restrictions on it no matter what (except for escalation bugs/hacks).
On a side note, you seem to have a slight misunderstanding of user rights on Linux/Unix as well as what certain commands and functions do. If a user does not have permissions to do a certain action (like kill the process of another user), then calling setuid on the program you want to kill (or on kill itself) will have no effect because the user does not have permission to another users 'space' without super user rights. So even if you're in a shell script or a C program and called the same system command, you will get the same effect.
http://www.linux.com/learn/ is a great resource, and here's a link for file permissions
hope that helps
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