Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 0 down vote favorite

I've been looking into setuid vulnerabilities. Particularly, I am looking on OS X (10.5+) but other modern *nix distos apply as well. For example, I found a world writable suid file installed by a 3rd party app on my OS X box via find. According to standard practice, only critical files should be suid like chmod and passwd. My question is, how do I test this file for vulnerabilities beyond just turning it off? For example, I was able to vi the file itself and have it run a simple command but couldn't get it to chmod another user account. Does this simply mean that it was coded properly or is there a OS X function that helps secure suid vulns? Any resources, or corrections in my thoughts, would be excellent. If you know of a insecure 3rd party *nix apps or distros vulnerable to suid privilege escalation to learn on, that would be doubly excellent. Thanks.

share|improve this question
1  
I recommend you avoid messing around with setuid bits. Unless you are a guru, I think it's safest to just leave them the way the OS set them. Especially: don't set the setuid bit on any program yourself. This is a fragile area. Most OS's already set the setuid bits on pre-installed applications in a reasonable way, and if you try to manually set the setuid bit on additional programs yourself, you are likely to introduce security holes. For similar reasons, you should not set the setuid bit on your own programs. – D.W. Sep 7 '12 at 18:48

2 Answers

up vote 4 down vote

According to standard practice, only critical files

All executables you run are "critical", as they run with your UID and have all your permissions! They could do bad things to your files, that's "critical" to me. Executables run by root are even more "critical".

It is common, but incorrect to focus on SUID files when discussing possible security flaws of a Un*x system; all executables should be considered. There are just more ways to corrupt a SUID program.

According to standard practice, only critical files should be suid like chmod and passwd.

No, only executables specifically designed to run as SUID.

Writing SUID program is a whole topic, way too big to be appropriate for an answer here.

My question is, how do I test this file for vulnerabilities

In order to do a vulnerability assessment of a program, you have to first learn what purpose it serves, how and when it should be run.

My question is, how do I test this file for vulnerabilities beyond just turning it off?

You just don't "turn off" parts of your system just because you are afraid! A program is SUID for a reason; if you remove the SUID bit, the system might misbehave.

For example, I was able to vi the file itself and have it run a simple command but couldn't get it to chmod another user account.

A trusted program that can be modified by anybody is a security issue, even if it isn't SUID.

If you know of a insecure 3rd party *nix apps or distros vulnerable to suid privilege escalation to learn on, that would be doubly excellent.

There is a long and shameful history of vulnerabilities in SUID programs. Just searching for "exploit" or "vulnerability" and "suid" returns plenty of these.

share|improve this answer
1  
Thanks for your response. For the turning off of SUID bits, I was looking at the following link nsa.gov/ia/_files/factsheets/macosx_10_6_hardeningtips.pdf. A few of the processes, I don't use so I figure they were safe to turn off. – Richard Belisle Sep 7 '12 at 18:20
@RichardBelisle For every SUID that you turn off, there is a potentially useful functionality that is broken. "The following files should have their setuid or setgid bits disabled unless required." It can be very difficult for unexperienced users to determine what is required for what purpose. After changing a file permissions, you might observe that some functionality fail to work in an obvious way, or in a subtle way. – curiousguy Sep 7 '12 at 19:35
up vote 3 down vote

how do I test this file for vulnerabilities

You can never prove that any system is secure. That the file is setuid and writeable by all means by definition it is a vulnerability - it doesn't matter what the file currently does / currently contains.

I was able to vi the file itself

implies that it's a script rather than an executable - most shells have protections built into them to prevent running other scripts with the setuid identity.

But that the script is world writeable means that anyone could write some code, in say C, then overwwrite the setuid script with their own program which will run with setuid priviliege.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.