big issue on the mysql by default of directadmin

i was able to correct this on the mysql 4.x version by adding that to the my.cnf file.

however on the new mysql 5.x, i am unable to locate the my.cnf file in my system.

could someone help me?

i know i can just edit this on init.d but i prefer the standard approach.
 
I seriously don't know how you guys have your servers set up, but I have verified once again, using mySQL's LOAD DATA LOCAL INFILE function from a PHP script, that I cannot gain access to /usr/local/directadmin/conf/mysql.conf. I have also once again verified, using the same script, that I can access /etc/passwd.

Since the LOCAL option uses the mySQL client (as opposed to server) to access the filesystem, I would check to see how you have PHP configured. Are you using PHP's built in mySQL support, or the mySQL client library that 'ships' with mySQL? What user and group is your web server running as?

-Swift
 
i use mysql4.1.21 + apache 1.3.x + php4 CGI + php5 CGI

ON CENTOS 4.X
maybe its working just on centos..

http://www.rapidenet.info/phpinfo.php

and the mysql is compile by default of directadmin..

and its working too into PHP-4 CLI and PHP-5 CLI
not just php CGI..

if you cannot access to this file.. maybe its because you dont understand how.. because all servers directadmin i have tried.. its working !!

( sorry again for my english )

and i going to stop to continu about this..
i just repeat, on a serveur with a normal setup its working !

have a nice day
 
Last edited:
I understand exactly how, which is why I confirmed that the mysql client can successfully read /etc/passwd using the same script (your script!)

What you don't seem to understand is the *nix permissions system. If the permissions of the DA conf/ directory are set to only allow the "diradmin" user read access to the file, then only someone with root priviledges, or the "diradmin" user can access the file. If your web server or mysql client has root priviledges, then that's the problem. Why not fix your security problem, instead of disabling mySQL functionality?

-Swift
 
the permission of this file is ok..

[root@box14 ~]# ls -lnh /usr/local/directadmin/conf/mysql.conf
-r-------- 1 101 101 30 Feb 23 2007 /usr/local/directadmin/conf/mysql.conf
[root@box14 ~]#


and i can read this by mysql ...

and the mysqld server run into the mysql user..
not root..

i really understand what is the *nix permissions system

.. by a shell user command , i'm not able to read this file..
the permission is really correct..

so?
:)
 
Last edited:
I don't know why you saw the need to hide the user and group associated with "101". For all I know it could be mysql:mysql!!

In any event, it's the mySQL client, not the server, that you are concerned with in using "LOAD DATA LOCAL". If your web server is running in it's own user space, and you have correctly complied PHP against the mySQL client library on your system, I can't see any problem.

To make sure the mysql user can't access the file, try issuing the LOAD command from the CLI mysql client.

e.g.
Code: 
#su mysql
mysql -u mytestuser -p
mysql> use mytestdb;
mysql> LOAD DATA LOCAL INFILE "/usr/local/directadmin/conf/mysql.conf" INTO TABLE TEST;
ERROR 13 (HY000): File '/usr/local/directadmin/conf/mysql.conf' not found (Errcode: 13)
mysql> LOAD DATA LOCAL INFILE "/etc/passwd" INTO TABLE TEST;                    Query OK, 138 rows affected (0.01 sec)
Records: 2138  Deleted: 0  Skipped: 0  Warnings: 0

Error 13 means "Permission denied". Suprise, suprise!

-Swift
 
[root@box14 ~]# ll /usr/local/directadmin/conf/mysql.conf
-r-------- 1 diradmin diradmin 30 Feb 23 2007 /usr/local/directadmin/conf/mysql.conf
[root@box14 ~]#
 
mysql> use test
Database changed
mysql> LOAD DATA LOCAL INFILE "/usr/local/directadmin/conf/mysql.conf" INTO TABLE membres;
Query OK, 2 rows affected, 6 warnings (0.00 sec)
Records: 2 Deleted: 0 Skipped: 0 Warnings: 6


strange because the file permission of mysql.conf is ok
and i can read this on many servers of directadmin..

and mysql run on the mysql user..
and we use the setup of mysql of directadmin give to all servers..

do you use centos 4.x ?
 
we suppose to have the same package setup of directadmin...

what do you think about this ?
and i repeat i can make this action on many servers of directadmin..and its working..

do you use centos 4.4 or 4.5 ?
 
duke, i tested this on centos 4.x and centos 5, they all have this problem.

could it be just the centos branch that have this problem?



and swift, can you check your mysql configuration? maybe you already have load-local file setting to 0.

btw, im doing all my testing from default directadmin build packages. so i have not modified anything. which means, directadmin is the one that needs to correct this problem. not the users(like me).
 
but he said he can read /etc/passwd, so the command for him is active..

but he cannot read the /usr/local/directadmin/conf/mysql.conf ..
so its strange...

for me its working on many servers...
weird
 
hey swift, try to create this file as dbexploit.php

***update: script has been deleted to prevent rogue hackers***

can you tell us what happens?

and which OS are you on?
 
Last edited:
"but he said he can read /etc/passwd, so the command for him is active..
but he cannot read the /usr/local/directadmin/conf/mysql.conf .."

i think he is just doing file_get_contents(); that can read any public viewable file.

but if he were to use the mysql script below to do it he would probably not. /usr/local/directadmin/conf/mysql.conf is not a public viewable file, so he won't be able to see that with file_get_cont... function.

but if he used the mysql query script, he would see the /usr/local/directadmin/conf/mysql.conf content it seems.

and i noticed that if you do this from mysql shell, this exploit doesn't work.
it only seem to work when it run as a php script.
 
Last edited:
im just surprised this is not receiving any type of urgent fix status.
i think this has to be one of the biggest directadmin exploit to date! :eek:
 
yea me too

because we host over 6000 websites and i manage over 80 servers with default setup of directadmin and one client have called us with one da_admin password...

the person its a good one... he have explain to me how he did..

with this exploit anybody can delete all databases with the da_admin password..
some servers here have 900 websites on 1 server ..its crazy..

i have always all backups but i can search 3 month how the hacker delete all databases before to find its with mysql with LOAD DATA LOCAL INFILE

im surprised dont see other members here to comment this post
because i repeat its working on a normal setup of directadmin on centos 4.x

at this date, i think is maybe CENTOS the problem..
we need other admin here to confirm this subject

in french i can explain more better,
in english no.. its why i have difficulty to explain this BIG problem.. i dont like that..
but im not stupid and i know its not our fault ( problem ) and im lucky the client dont have make problem to us with that.. i try each day to be more secure and one client call me with my da_admin password for sql.. its make no sense.. and not serious.. and im expert in files permissions.. not normal...

the user lkbryant , seem to understand what i try to explain,
about LOAD DATA LOCAL INFILE with mysql if its really working for him..

I CAN BET , GIVE ME ANY WEBHOSTING ON A NORMAL SETUP OF DIRECTADMIN ON CENTOS 4.X / MYSQL 4.1.X WITH PHP4 OR PHP5, i give you your da_admin password root for sql..and can delete all sql !

i have test already on 5 other hosting company web with directadmin..
( they all using centos 4.x )

so sorry to flood this subject on this forum.. but please think at it..
i love directadmin but... this need to be serious... its can be make lost many money to web company

i wait a reply from JOHN of someone admin of directadmin..about this.. please
for myself its fixed..with disable this function, but make no sense by default its working...
 
Last edited:
i think this is a very serious issue too.
maybe it is so serious, directadmin is keeping quiet about it.

even if directadmin posts a fix for this, only 30% or so da users will be able to patch the fix in time, unless they have auto-update enabled for directadmin(if it exists)

database is the most valuable aspect of any type of web hosting business. even more important than source files in my opinion.

i think peoples do not realize the amount of harm this exploit can be. i am going to edit out the script i pasted earlier, to save some disaster scenario.

i suggest you do the same duke. we don't want rogue hackers affecting every directadmin web hosting companies out there. that will make DirectAdmin look really bad once the news is publicly posted on the internet. like digg for example. that will also make all of us who run web hosting business on DirectAdmin look bad, since they'd think it is not safe to use.

hopefully DA already has a patch on the way.

i expect it to be ready by this week.
 
Last edited:
Are you guys running your mysql client as root? (not the server, the client). Because if the client is calling the read-in, then obviously it will have access to everything.

Run "mysql" as an end user without root acesss, and he probably won't have root access.

I was not able to duplicate the issue when running as a non-root user.
I was able to duplciate it when running as root.

Obviously, this means .. don't give your Users root ssh access if you don't want them to read in misc. files through obfuscated means.... basically, if they have root in the first place, they can read whatever they want.

This does not appear to be any security issue.
If they have root, they have root and the mysql client mysql will act accordingly.
For all normal cases (you guys), your users won't have root access, thus this is a non issue.
The mysqld server runs as the "mysql" user, thus has no way of reading anything like the mysql.conf.

John
 
Hi DA,
you are right.

This IS a non-issue, it didnt work for regular user's account.

Thank god.

I feel pretty stupid now. LOL
 
Last edited:
You must log in or register to reply here.
Back
Top