DirectAdmin <=1.33.1 0day exploit

[tillo]

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 (http://www.directadmin.com/forum/showpost.php?p=143980&postcount=8), 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.

[Twintone]

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.

[DirectAdmin Support]

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

[tillo]

I agree. I'll send you an email with the related vulnerability I've discovered.

[hostpc.com]

Hello,
Bottom line, make sure you have your /etc/shadow chmod to 600, as everyone should already.
John

FYI - All 160 of our servers show

-r-------- 1 root root 1683 Mar 24 23:29 /etc/shadow

Not chmod 600 on stock installs - that looks like chmod 400

[DirectAdmin Support]

err. yes, sorry 400 ;)

John

[hostpc.com]

err. yes, sorry 400 ;)

John

Thats ok, you're just checking to make sure we're paying attention, aintcha? :)

LOL

[jackc]

there isn't an "ln" function in PHP right?

[Dravu]

there isn't an "ln" function in PHP right?
Nope. In the instructions, it is said you require SSH access which is where the ln command comes into play. Here is PHP's symlink function:
http://us.php.net/symlink

[DirectAdmin Support]

Hello,

I've found a few areas that I was able to improve in the checks for the ownership reset and have included them in the latest release of DA (1.33.2).
They're listed here:
http://www.directadmin.com/features.php?id=953

John

[Peter Laws]

-rw-r----- 1 root shadow 1295 2009-03-03 00:50 shadow
-rw------- 1 root root 1233 2009-01-27 12:58 shadow-
is this 400? hmmm

[scsi]

640
&
600

http://store.redhat.com/docs/manuals/linux/RHL-7-Manual/getting-started-guide/s1-navigating-chmodnum.html

[floyd]

is this 400? hmmm


FYI - All 160 of our servers show

-r-------- 1 root root 1683 Mar 24 23:29 /etc/shadow

Not chmod 600 on stock installs - that looks like chmod 400

400 is -r--------

[tillo]

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

[floyd]

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.

[scsi]

As long as the everyone group cannot read the file there should be no problems.

[tillo]

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.

[floyd]

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.

[hostpc.com]

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

[tillo]

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 :)

[floyd]

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

I don't mess with sticky's much so I have not bothered remembering those. I have no idea what this is ("g+s,+t").

However I do know all the permissions we normally use. I only have to remember 3: 1,2,4 Everything is derived from those 3.

And I don't have to remember the syntax of the command. I don't have to worry about = and , and +.

What is easier for an average beginner? I don't know. I have not done a study. For me, as a beginner, learning the numbers was easier. Both styles existed at the time I was a beginner. The numbers were way easier for me to comprehend. Not everybody is the same.

Its way off topic now.

[nobaloney]

I use both. And I understand tillo's point. But when people post directory snippets which use combinations of rwx--x--x and so forth, then certainly I have no problem with answering that way.

Jeff