help with gcc for a newbie

[sk8skiJRH]

I'm extremely new to linux and have just installed the gcc that came with SUSE distro. It compiles my .c file fine. But when I type a.out to run the file, the shell says it doesn't recognize a.out? Am I missing a command or a configuration? Thanks a ton in advance!!

[TacKat]

Use ./a.out to run the file.

[sk8skiJRH]

Thanks a ton!

[Rüpel]

and to avoid future confusion, add 'current directory' (denoted by './') into your path-environment variable - maybe there's a .bashrc or .tcshrc-file in your home-dir.

[bwkaz]

Originally posted by Rüpel
and to avoid future confusion, add 'current directory' (denoted by './') into your path-environment variable - maybe there's a .bashrc or .tcshrc-file in your home-dir. Actually, unless your Linux box is single-user, with no remote logins possible, this might not be a good idea.

Suppose a malicious user decides they want root access -- so they create a little executable that changes their UID to zero (this makes them, effectively, root). They put it in /tmp, and call it ls. Maybe they're a bit smarter, and after it does its thing, it deletes itself and passes all its args off to the real /bin/ls, so it looks like nothing even happened.

So you, as root, go into /tmp and try to list the directory. Bingo! Mr. Malicious is now root, and the thing is, you probably don't have a clue, unless every file in /etc is immutable. (Edit: immutable is a flag you can set with some filesystems that tells the system that no one should be able to change that file, not even root. So you'd get an error when you ran ls, that /etc/passwd could not be changed. Probably.)

Of course, this only works if you put ./ in front of /bin in PATH. But there are still problems with putting it after /bin (say, if it's at the end of your path):

Suppose Mr. Malicious User knows that occasionally you mistype ls as sl (I actually do this on occasion). So he names his executable sl instead, except instead of calling /bin/ls, it just prints out the normal "bash: sl: command not found" message. All he has to do is wait for you to mistype ls, and again, he has root access.

I don't think typing two characters is that big of a deal to avoid this kind of security thing, especially since the shell will autocomplete for you -- if you type ./a and hit tab, it'll most likely fill in the rest of the filename. This is actually less typing than a.out...

[Rüpel]

hmm. sounds interesting, never thought of that. i don't really get the point, how someone can write a program, that gives himself UID 0 and the side-effects.

maybe i have a dirty little function ChangeMyUidToZero() - when i execute a program as a normal user and this function is called within, i'm able to edit (or whatever) /etc/passwd and things like that (from within the program)? did i get that right?

[Energon]

You can't change your uid unless you have the right permission to do so. So that nixes that idea... :)

Here's the code that shows it isn't possible:


#include <sys/types.h>
#include <unistd.h>

int main()
{
setuid(0);
while(1);
return 0;
}


If you compile and run, then do a ps aux while it's running, it won't change ids, but if you run it as root and have it set the id to your id, it will change it.

The problem is if you run as root or if the program is setuid root. Those cases give the process permission to do bad things. So what you do is hide an app called ls in roots home directory and when the foolish admin types ls to see what's in his directory, 'rm -rf /' is what he gets.

[bwkaz]

By "change UID to zero", I meant edit /etc/passwd, and change the UID field of their username's line to zero. The EUID (and real UID) of the process is already zero (because root, not you, executed the program), that's why the program can even change /etc/passwd.

Does that help at all?

[Rüpel]

hmm. so there's only danger if i'm running that evil-ls-clone when being logged in as root (which is hardly ever the case)?

one thing i still don't understand is:
or if the program is setuid root

[bwkaz]

Originally posted by Rüpel
hmm. so there's only danger if i'm running that evil-ls-clone when being logged in as root (which is hardly ever the case)?

one thing i still don't understand is:

or if the program is setuid rootPretty much. I would agree that it's a smaller risk than some others (like only ever logging in as root... ;) ), but it's fairly easy to eliminate.

Setuid is a bit in the permissions of files. If it's set on an executable, then anyone that can run the executable runs it as its owner. So if the setuid bit is set, and the executable's owner is root, then whenever it gets run, it gets run as root. No matter who runs it.

X is one of the better-known examples. Since it needs low-level access to your video hardware, it needs to "be" root a lot of the time. But only letting root run it is a bad idea, because most people want normal accounts to be able to use it. So most installations of X have root own it, and they set the setuid bit. So when Joe User runs it, the server itself is run as root. All the clients (GUI programs, plus the window manager) are still run as Joe User.

Of course, the X server is scrutinized for security issues hard and often. It might not be hard to make a Trojan X that has code in it to do what the evil part of our evil ls does (along with the rest of what X normally does) -- of course, you'd have to trick the sysadmin into installing it somehow.

[Rüpel]

got it. thx.