Using a stolen password, Mallory managed to log into an important server running Linux. The account was a very limited account, but Mallory knew how to cause trouble with it. Mallory installed and ran a trivial program with very odd behavior. Learn what a race condition is and why it can cause security problems.
Know How To Prevent Race Conditions
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Nice article I like it alot…. wish we had some more on OSNews :-D.
Yes great article, nice in-depth information.
Excellent article. There are more security articles and a security book at http://www.dwheeler.com/secure-programs . I think learning those things is inevitable to write immaculate programs (if there is such thing
)
in-depth but still easy to understand. great job.
This is more flexible, but there’s a danger: if those processes and threads share any resources, they may be able to interfere with each other. In fact, a vulnerability to race conditions is one of the more common vulnerabilities in software, and on Unix-like systems, the directories /tmp and /var/tmp are often misused in a way that opens up race conditions.
Therefore set both /var and /tmp noexec in fstab.?
Settings /var and /tmp to noexec won’t help. The attacker can still create links there to important files and be able to read/replace/delete them eventually.
I have been setting them (on Slackware) from a file named: /etc/profile.d/tmp.sh for a while now… Looking like this:
#!/bin/sh
if [ ! -d “$HOME/tmp” ]; then
rm -rf “$HOME/tmp”
mkdir -p “$HOME/tmp”
fi
chown “$USER” “$HOME/tmp”
chmod 0700 “$HOME/tmp”
TMPDIR=”$HOME/tmp”
TMP=”$TMPDIR”
export TMPDIR TMP
——————-
RedHat / SuSE users might want to have a look into the pam-tmpdir module. BTW this seems to be a hot topic, as i read about some exploits to commen utilities not long ago …
Why not enforce user local ~/tmp folders? It just seems to me that a global tmp scheme is the real problem here. Plus, whatever storage is needed by an app being run by userX should be using the space allocated specifically for userX. So having a ~/tmp folder makes much more sense. Anyone else understand why Unix, which is supposed to be so secure, has a global tmp?
Anyone else understand why Unix, which is supposed to be so secure, has a global tmp?
I don’t think Unix is intrinsically secure. Evidence the simplistic permission set, running daemons as root, lack of stackguard, and world readable password files. Security has been tacked on to unix over the years (which ameliorates some of the above). IMHO, something like OpenVMS was created with security in mind.
The ‘Why Open Source’ article linked at the bottom is worth reading also.
You’d need to do this via PAM, during the login
process before UID is changed:
1. clone(CLONE_NEWNS) to split the namespace
2. create a /tmp/someuser directory (if missing)
3. mount –bind /tmp/someuser /tmp
The user will see an empty /tmp directory.
You could use ~/tmp or /realtmp/someuser if desired,
like so:
mount –bind /home/someuser/tmp /tmp
Unix was never intended to be secure. Whoever thinks that Unix was built from the ground up to be secure really needs to study their history. Unix was originally developed in a research context. Hell, in the original releases there wasn’t even a password with the logins. The only reason for even having usernames was for convenience (homedirs). Even after it ventured out from Bell Labs, it was largely used in an acedemic context where a very limited set of trusted users had access to the machine. Security is very much so something tacked on to Unix systems after the fact. This is, in fact, one of the biggest things confronting larger adoptance of *nix systems. More powerful ACLs on everything is certainly the solution that looks to be the one coming to the forefront to fix many of the core issues with flexibility and specificity of security measures.
“Settings /var and /tmp to noexec won’t help. The attacker can still create links there to important files and be able to read/replace/delete them eventually.”
I don’t see how, since tmp directories have sticky bits. ie: You can’t mess with a file you didn’t create.
“Evidence the simplistic permission set”,
That’s what ACLs are for.
“running daemons as root”
Most daemons should not be running as root. And if they are, it usually indicates the system administrator doesn’t have a clue.
“and world readable password files.”
Virtually no modern UNIX system stores the password in a world readable file. What you see in there is just a placeholder. The real password is stored in a shadow file which is not readable by anyone except root.
How many times have I warned you about race conditions when sliding between dimensions?!
– Professor Maximillian Arturo
There’s a really simple solution: Don’t separate designation from authorization!
Now, if only the people making kernels and operating systems would get a clue… (well, there are a few ones who do, but most don’t).
> Settings /var and /tmp to noexec won’t help. The attacker
> can still create links there to important files and be able
> to read/replace/delete them eventually.
There’s some truth about this, at least for the old Linux 2.4:
$ cc hello.c -o hello
$ /lib/ld-linux.so.2 /tmp/hello
Hello World
Fortunately though you’d not encounter this if you’re using a 2.6 kernel. This is what you’ll see on a 2.6 kernel:
$ cc hello.c -o hello
$ /lib/ld-linux.so.2 /tmp/hello
/tmp/hello: error while loading shared libraries: /tmp/hello: failed
to map segment from shared object: Operation not permitted
However, this can be circumvented yet again when you
try to analyse this snip in linux/mm/mmap.c
if ((prot & PROT_EXEC) &&
(file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
return -EPERM;
So this can still be circumvented if you create special binaries that have the executable flags removed from the segments read by the kernel – and unfortunately this still works with the latest Linux kernel.
I’m not sure though if this same technique can work on the other Unix-based operating systems (of coure with some alterations to code). At the very least though, this can be prove a deterrent to crackers. If you’ll need more security (at the expense of functionality unfortunately) you can try out the secure versions of your Unix-based OS (as by default Unix-based systems employ discretionary access control).
Cool.Unfortunately SuSE linux doesn’t have a trusted branch,
like for instance debian has.$ /lib/ld-linux.so2 /tmp/hello didn’t work though.I got a file/directory not found error.Although /lib/ld-linux.so2 exists.
/lib/ld-linux.so2 is a dynamic linked library right?