DirectAdmin <=1.33.1 0day exploit

tillo

Verified User
Joined
Oct 28, 2007
Messages
862
Location
Switzerland
I just noticed a 0day exploit for DirectAdmin on milw0rm (http://www.milw0rm.com/exploits/8286).

For anyone concerned about its security, make sure none of your untrusted users have SSH access and block any process-launching function in PHP (read for example this post, important functions are "passthru, proc_nice, shell_exec, symlink, system, exec, popen, proc_open") until a DA update is available.

EDIT: I just tried various ways to make that exploit work without succeeding (even using "?action=resetowner" on the file and "?action=resetowner&method=recursive" on the containing directory), I guess it's a false alarm. Anyway, I believe it's better to wait for an official confirmation.

EDIT2: it is working for any file owned by apache (user or group), it is not a direct security risk but it may be: consider that every public_html directory has GID=apache.
 
Last edited:
Just saw this via Milw0rm as well. Running some tests to see what we come up with. Good to see others are on top of it.
 
Hello,

Can you clarify your EDIT 2 for "any files owned by apache"?
If it's just where if you link to a world readable file, you can see the file through a link? If so, that's about the same effect as looking at the file directly, so wouldn't be of concern. That just falls onto linux security concepts and isn't really anything to do with DA itself, I wouldn't be worried there. If it's something else, please specify, possibly tell me via email support@.

I have also tested this claim and have not been able to duplciate any issues with it. It appears false as far as I can tell as well. The only way you could see the shadow is if your /etc/shadow is chmod to 644.. again, in which case you can see the /etc/shadow directly anyway, so it really doesn't accomplish anything.

Also, for anyone concerned, the /etc/shadow contains the 1 way encrypted passwords, they can't be decrypted. Knowing the crypt does not mean you know the passwords, it simply means you can check if a password is correct, essentially the same effect as trying to login as the user repeatedly with "fail" until you get it right. Bottom line, make sure you have your /etc/shadow chmod to 600, as everyone should already.

Just a side note that if you ever find any issues, please *tell us* via email so we can fix them. If you simply post it to the forum, we're not going to know about it first as we don't scour the forums regularly. You're welcome to post it to the forum to let people know, but prefereably after it's actually confirmed as an issue (to prevent unjustified panic) and we've had a chance to resolve the issue if it is one, as fixes are not always instant to implement and release. Luckily, this seems to be a false alarm as far as we can tell, so isn't a huge issue in this case. I learnt of this from another client who stumbled across it. We cannot fix something we don't know about.

John
 
It depends on the distribution.
For example, on a Gentoo: -rw------- 1 root root xxxx 2009-xx-xx xx:xx /etc/shadow
On a Debian: -rw-r----- 1 root shadow xxxx 2009-xx-xx xx:xx /etc/shadow
 
I thought the question was is -rw-r----- or -rw------- 400. Answer is no. 400 is -r-------- on any distribution.

Maybe I misunderstood the question.
 
As long as the everyone group cannot read the file there should be no problems.
 
In a related matter, IMHO people should stop referring at file system permission with their octal digits, at least in guides. Most people don't have the slightest idea of how those are composed.
Of course it's faster to say "chmod 664 your file", but this way few people really understand what they are doing. Instead, saying "chmod ug=rw,o=r your file", everyone understands they are making the file readable and writeable for user and group, and only readable for others.
Furthermore, the "new" syntax allows for adding or removing a permission, while the "old" one must specify everything. Like "chmod u+s file" instead of "chmod 4??? file" for the suid bit.
 
chmod ug=rw,o=r

Means nothing to me. I have already memorized the numbers. To me this explains more:

1 = execute
2 = write
4 = read

For me this makes more sense. The longer the command the more confused I get.
 
Means nothing to me. I have already memorized the numbers. To me this explains more:

1 = execute
2 = write
4 = read

For me this makes more sense. The longer the command the more confused I get.


Exactly. It's all a matter of preference - octals are the industry "standard". There's a bunch of "free" calculators that help you determine chmod values, for instance: http://www.hostpc.com/chmodcalc.php
 
Why would someone need a calculator to understand permissions?
Of course it's better to use octals for people that already know them; what I'm saying here is that it is not user friendly, therefore people new to *nix have one more thing to learn. That's why I specified "at least in guides".

@floyd: tell me what is the octal value of sgid+sticky ("g+s,+t"), without looking the man :)
 
Back
Top