MRatWork Forum by Mustafa Ramadhan

Sawo Project - Kloxo-MR Discussions => Kloxo-MR Releases => Topic started by: MRatWork on 2014-01-30, 09:02:39

Title: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-01-30, 09:02:39
At this moment, many report related to Kloxo Official security issue. Read http://www.webhostingtalk.com/showthread.php?t=1344003 about it.

Fortunely, Kloxo-MR no affect for this issue.

But, another security issue (code from Kloxo Official) still exist in Kloxo-MR.

Fixing for this issue are:
1. Add sanity '../' in filemanager
2. Cron task only enable for 'admin'

Please update Kloxo-MR to 2014013001. Update is very importance for Kloxo-MR as share-hosting (many clients inside).
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-30, 09:59:59
They found more exploits.  What to do about hardlink protection?

This is all very big problem.

cron is not able to be used by clients?  I thought we could run cron under their username?
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: bluearrow on 2014-01-30, 10:02:57
Can't we update Kloxo_MR from Update Home because 2 of my VPS shows

Current Version:   6.5.0.f-2014011001
Latest Version:   6.5.0.f-2014011001

and

Current Version:   6.5.0.f-2013102801
Latest Version:   6.5.0.f-2013102801


and There's no update button ..
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-30, 10:05:22
Use SSH:
yum clean all;yum update;sh /script/cleanup
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-01-30, 10:11:39
They found more exploits.  What to do about hardlink protection?

This is all very big problem.

cron is not able to be used by clients?  I thought we could run cron under their username?

Hardlinks only affect if client able access to ssh and with this capability they can create php file inside /usr/local/lxcenter/kloxo/httpdocs. Without this capability, client able to running php and or perl via browser and or command-line.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: lupetalo on 2014-01-30, 10:38:21
Quote
<php
symlink('/etc', '/home/user/etc');
?>
No ssh needed
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: lupetalo on 2014-01-30, 10:39:47
How to disable file manager?
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-30, 10:56:29
Yes, tested and confirmed filemanager is MAJOR exploit.  It runs as root!

Mustafa, follow steps to create a disaster!

Login panel as a client (test).  Filemanager, create new file.
exploit.php
Code: [Select]
<php
symlink('/etc', '/home/test/etc');
?>

Execute script in browser.  domain.com/exploit.php

KloxoMR filemanager, under test client/user 'etc' directory appears, click it takes me to real /etc/ directory.  Using filemanager I can now edit/delete ANY file in /etc directory.

NO SSH required.  This can be recreated with any file or directory!  THIS IS A MAJOR DISASTER WAITING TO HAPPEN!

Mustafa, all efforts must be made NOW to make filemanager run as client/user logged into KloxoMR NOT ROOT, this is a must!
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: lupetalo on 2014-01-30, 11:10:00
Quick fix, how to disable filemanager, for now i stopped kloxo...
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: lupetalo on 2014-01-30, 11:12:30
i guess that php commands can be desabled, ln and symlink.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-30, 11:22:56
Then you just use a perl script, or a Ruby app.  The problem is two fold.  Number one, we need to get filemanager to run as user/client.  Second, if not admin, DO NOT DISPLAY symbolic/hardlink directories.  No reason for a normal client to hardlink a directory.

Suggestion, for now, in filemanager disable showing ANY symbolic/hardlinks unless admin

Mustafa, please work on this without delay, we are all vulnerable! !!!
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-01-30, 11:26:06
@chrisf,

Are you sure about it?.

Let say, I have /home/admin/domain.com and then from filemanager I create exploit.php.

If I run 'http://domain.com/exploit.php' and then inside /home/admin already exist /etc symlink?.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-01-30, 11:30:55
I found error when running 'http://domain.com/exploit.php':
Code: [Select]
Warning: symlink() [function.symlink]: open_basedir restriction in effect. File(/etc) is not within the allowed path(s):
(/home/admin/:/tmp/:/usr/share/pear/:/var/lib/php/session/:/home/kloxo/httpd/script/:/home/kloxo/httpd/disable/)
in /home/admin/next.potissima.com/exploit.php on line 6

with modified exploit.php:
Code: [Select]
<?php

error_reporting
(E_ALL);
ini_set('display_errors'1);

symlink('/etc''/home/admin/etc');

?>
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-30, 11:42:39
Yes, I too found that error, I had originally ran it from command-line and the php-fpm openbase dir was not in effect.  But, try this.

Filemanager, cgi-bin, create new file
exploit.pl
Code: [Select]
#!/usr/bin/perl -w

symlink("/etc", "/home/admin/etc");

Execute from browser,  follow above steps, exploit is realized.

And not so sure it is easy to not display hardlinks, possibly symlimks...

MOST IMPORTANT, remove root from filemanager.

Also, trick for quick fix, only display files owned by that user/client.  ;)
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-01-30, 11:45:59
@chrisf.

Who's able to access ssh?. You and who?.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-30, 11:47:22
No one, but I have done all this through filemanager.  That perl script will run via browser if in cgi-bin of client
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-30, 11:50:45
Quickest fix Mustafa is to display only files owned by client/user.  If admin,  under server filemanager,  display all files.

And sanity check permission editor, only change permissions if owned by client, unless admin.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-01-30, 11:54:01
No one, but I have done all this through filemanager.  That perl script will run via browser if in cgi-bin of client
So, you access via 'http://domain.com/cgi-bin/exploit.pl'?. Also 'http://domain.com/exploit.php'?
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-30, 11:55:43
cgi-bin yes.  Php no, open base dir error.

My solution above would not be so hard to implement.  Peace of mind, and would stop fooling around.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-01-30, 12:13:58
FYI, I am using 'hiawatha-proxy'. So, are you using the same?.

Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-30, 12:32:51
Nginx-proxy.

Mustafa, we waste too much time back and forth - I support KloxoMR,  I have been around prior to the tragedy of Ligesh and Kloxo being open source.  I am trying to help.  I am good at what I do.  I do not know everything, and look to others when need be.  You have saved me before, and I have figured out things for you.

My suggestion to you is this, so you don't have to rewrite entire file manager.

1. Display only files owned by the client logged in.
2. Sanity check permission editor to only allow changes from owner
3. Sanity check any file being saved, must be owner.

if logged in as admin, under server file manager, allow all files and all changes (no restrictions).

It is 6am in US, been awake all night with this, please consider my suggestions, they would not be so hard to code.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-01-30, 12:41:35
I didn't have problem with filemanager. If login via 'admin', create new file already with 'admin' as owner. If login via 'tester', create new file already with 'tester' as owner.

So, I think filemanager work running after update to 6.5.1.a-2014013001.

For php, using open_basedir (declare in php-fpm config for php-fpm) make strict directory access for php. Still investigate the same function (open_basedir) for perl.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-30, 12:47:35
You are missing the point, yes creating a file saves it as owner.  But becauae file manager uses root, it can change permission, delete, any file.  If a user finds a way to get it to display sensitive directories, by exploit or however, file manager is dangerous.

It is not all right.  You should consider my solution.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-01-30, 13:07:32
Access filemanager:

1. 'Admin > server > filemanager' --> save always as 'root'
2. 'Admin > filemanager' --> save always 'admin'
3. 'Admin > Clients > [Tester] > filemanager --> save always 'tester'.
4. 'Tester > filemanager --> save always 'tester'.

All accesses always change permissions.

So, what's a problem is?.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-01-30, 13:15:52
And what's the reason sanity for 'ownership'?.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: lupetalo on 2014-01-30, 16:57:38
Quote
And what's the reason sanity for 'ownership'?.
And what is the reason for not listening to chrisf and making file manager NOT run ad root....
Yet again you dont listen to others and not accepting help, but blindly yelling that everything works...
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-01-30, 17:38:55
Quote
And what's the reason sanity for 'ownership'?.
And what is the reason for not listening to chrisf and making file manager NOT run ad root....
Yet again you dont listen to others and not accepting help, but blindly yelling that everything works...
No reason to sanity for 'ownership'. Better concentration to how to limiting php/perl access to certain directories only.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-30, 21:17:22
I agree, we need to chroot or jail users in their home directories.

You are misunderstanding me.  PM me login for a tester client and using file manager I will shut the server down. 

The sanity check stops any unknown exploit.  You are missing the entire idea of security, sanitation, and stopping exploits prior to happening.  File manager can access any file, because it runs as root.

There is no need to debate this, you should fix this immediately.   My sanity checks, they stop unknown exploits and bring KloxoMR admins peace of mind.

As of right now, ANY KloxoMR installation can be destroyed.  Think about that.  I am very disappointed you would rather say no then to implement security measures.

I have a server with 30 clients.   They are not secure, and that bothers me!
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: Spacedust on 2014-01-30, 22:07:01
The same goes to shell access. If you have mc installed then you will be able to go outside users directory !
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: insanity on 2014-01-30, 22:12:04
Yes, because all users are under apache group. If you create symlink in home/domain/symlink-folder and point it to home/domain2/some-folder you will be able to edit all files.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-31, 00:56:38
THIS IS GETTING WORSE!  The entire KloxoMR panel now runs under root.  The guys from R911 tore through KloxoMR in seconds.

Are you working on this Mustafa?
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-31, 03:27:48
For those using KloxoMR for shared, can you implement this for apache and proxies?

http://www.linux-faqs.info/apache/running-apache-in-chroot-jail (http://www.linux-faqs.info/apache/running-apache-in-chroot-jail)

This would mitigate file system attacks, scripts would be unable to access below /home/
This would also prevent a perl script from putting a file in /usr/local/lxlabs/kloxo/httpdocs, stopping a local root escalation through IP:7778. 

This is a good solution to start.  More work needed.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-31, 07:23:14
Mustafa have you reviewed the chroot jail for Apache?
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: farrow on 2014-01-31, 11:32:18
For those using KloxoMR for shared, can you implement this for apache and proxies?

http://www.linux-faqs.info/apache/running-apache-in-chroot-jail (http://www.linux-faqs.info/apache/running-apache-in-chroot-jail)

This would mitigate file system attacks, scripts would be unable to access below /home/
This would also prevent a perl script from putting a file in /usr/local/lxlabs/kloxo/httpdocs, stopping a local root escalation through IP:7778. 

This is a good solution to start.  More work needed.

WOW, Your like a kid.
Anything that doesn't go your way you throw your rattle out of your pram.
Your making posts all the time, YOU NEVER LEAVE THE GUY ALONE.
I would rather wait and take advice from Mustafa than listen to you. Personally I don't think you know much only know how to bitch and use Google.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: skr on 2014-01-31, 11:33:27
Hi,

Please advice me How to update to 6.5.0.f/6.5.1.a Kloxo-Mr in SSH.I have no idea about it

Thanks
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-01-31, 11:58:50
Run 'yum clean all; yum update; sh /script/cleanup'.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-31, 18:45:41
@Farrow, this is not a forum for idiotic chit chat, and personal attacks, pm me if you got something to say to me.

You and most of the users of KloxoMR really don't understand just how easy it was for a security consulting business, R911, to make KloxoMR worthless in seconds.

I take this VERY seriously, because I have clients who rely on me to keep their information/sites online and safe.  I TAKE THIS VERY. SERIOUS.

And as far as me blindly following Mustafa, even though he is a great system integrator, it is my opinion he doesn't take security as serious as he should.  Ever heard of the name Ligesh?  Great programmer, brilliant man.  Google that @Farrow.

So Mustafa, what you think about chroot jail Apache?  Perl exploit would have no effect.  What you think?

Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: farrow on 2014-01-31, 18:59:45
@Farrow, this is not a forum for idiotic chit chat, and personal attacks, pm me if you got something to say to me.

You and most of the users of KloxoMR really don't understand just how easy it was for a security consulting business, R911, to make KloxoMR worthless in seconds.

I take this VERY seriously, because I have clients who rely on me to keep their information/sites online and safe.  I TAKE THIS VERY. SERIOUS.

And as far as me blindly following Mustafa, even though he is a great system integrator, it is my opinion he doesn't take security as serious as he should.  Ever heard of the name Ligesh?  Great programmer, brilliant man.  Google that @Farrow.

So Mustafa, what you think about chroot jail Apache?  Perl exploit would have no effect.  What you think?

I'm sorry if you think it was a personal attack, it wasn't, I just think your advice is second hand.
A quick question, you say you take it serious but are you using kloxoMR for your clients? even when you know it has security issues.   
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-31, 19:25:30
@Farrow, pm sent.  I already stated, if you want to debate or question me, do it in pm.  This post is about making KloxoMR more secure.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: befree22 on 2014-01-31, 19:52:20
You are missing the point, yes creating a file saves it as owner.  But becauae file manager uses root, it can change permission, delete, any file.  If a user finds a way to get it to display sensitive directories, by exploit or however, file manager is dangerous.

It is not all right.  You should consider my solution.

This is EXACTLY how my sites were hacked. The wp-config.php file was BLANK because the criminal hacker REMOVED all code from this critical file. I reported this "root" user bug but Mustafa doesn't care about security or applying intelligent suggestions. This is why I'm researching Webmin because security is the MOST important aspect of any website.

If he wants KloxoMR to succeed, he needs to work with a good development team and beta testers who actively work to secure KloxoMR.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-01-31, 20:12:29
@befree22,

Your issue not related to 'root user'. In this 'root user' issue related to php52s/hiawatha running in 'root user' (already fixed).

Your issue related to 'open_basedir'. Without limiting access by 'open_basedir', it make (for example) execute 'include_once("/home/user1/domain1.com/file1.php")' in php file inside '/home/user2/domain2.com'. This issue also already fixed where include_once only possible no more higher than '/home/user2'.

That it.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-31, 20:30:11
Why no response about Apache chroot jail?  This is good security measure don't you think?
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-01-31, 20:32:14
Why no response about Apache chroot jail?  This is good security measure don't you think?
I am still think this method needed. If apache using chroot and then what about other webserver (nginx/lighttpd/hiawatha)?.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-01-31, 20:38:00
proxy should be protected by this since perl is interpreted by Apache.  I am not sure.  This is why I ask you :)

think of Apache jailed chroot for shared hosting, others for personal hosting.  if proxy works, then most shared hosting would want Apache backend for .htaccess and mod_rewrite.  I think it is a win win situation.

This would stop ALL file system attacks by clients.  I am researching, doesn't seem too hard to implement.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: matt on 2014-02-01, 12:26:20
Is the problem still exist? My server got suspended due to kloxo installation  :o . See this:

Quote
Due to a recent SQL injection attack on Kloxo, It is no longer allowed on our network. Your container has been suspended for security reasons.

Any help?
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-02-01, 14:46:18
Is the problem still exist? My server got suspended due to kloxo installation  :o . See this:

Quote
Due to a recent SQL injection attack on Kloxo, It is no longer allowed on our network. Your container has been suspended for security reasons.

Any help?

Kloxo-MR doesn't have this issue!. It's only for Kloxo official 6.1.12!.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: Spacedust on 2014-02-01, 19:48:07
Yeah. That's why we should change the name.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: pats on 2014-02-14, 08:48:15
Is the problem still exist? My server got suspended due to kloxo installation  :o . See this:

Any help?

Two of my providers sent email about Kloxo - remove or it'll be suspended.
I replied to them that i'm using Kloxo-MR.
They replied then its OK :)
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: henry on 2014-02-16, 15:16:09
Yeah. That's why we should change the name.

I suggest MRamin. Sound pretty good  :)
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: Spacedust on 2014-02-17, 18:26:45
MRadmin ;)
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: vpsbox on 2014-03-02, 16:12:38
cpanel got same problems from almost 3 years... https://forums.cpanel.net/f185/solutions-handling-symlink-attacks-202242.html (thread is strated in 2011)

 so what is their recomended solutions list was updated las year https://forums.cpanel.net/f185/solutions-handling-symlink-attacks-202242-p23.html#post1397221

 SymLinksIfOwnerMatch is not enough
http://docs.cpanel.net/twiki/bin/view/EasyApache/Apache/SymlinkPatch

first was cloud linux and cage fs which is not a free solution, next best they introduce experimental chrooting with mod ruid2 last summer  (still experimental still  usable things not working)
 
Next is recompiling Centos kernel and include GRSec kernel patch (never done that before i saw tha there are instruction i how to forge but now for GRSEC must read 2 manuals )

not so recomended but working to some extend pach from blue host in easy apache (never saw it )

and pach from http://layer1.rack911.com/before_apache_make

https://forums.cpanel.net/f185/solutions-handling-symlink-attacks-202242-p4.html#post996441

get apache sorce apply pach compile

not sure if the pach i usable with nginx proxy

hope will be usable for the forum
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-03-02, 16:23:02
Mustafa please investigate Apache patch, what you think?

R911 is security best, consider please.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-03-02, 16:25:42
@vpsbox,

Read http://www.apache.org/dist/httpd/CHANGES_2.2. Look like symlink issue already fix since 2.2.17.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: chrisf on 2014-03-02, 16:31:18
I think the patch simply turned ifOwner on by default.  You integrated that on last security upgrade server wide correct? ;)
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-03-02, 16:38:47
Kloxo-MR use most application from other repo. Example, php branch series from ius, httpd from centalt.

Only certain applications created by MRatWork if other resource only have too old version or no other repos serve certain applications.
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: vpsbox on 2014-03-03, 00:11:34
@vpsbox,

Read http://www.apache.org/dist/httpd/CHANGES_2.2. Look like symlink issue already fix since 2.2.17.

Yes but at cpanel forums they install rack911 plugin until 2.2.24 cause got problems and then blue host pach was included in easyapache

it is still available from options menu even for  for  2.4.7 apache and think kloxo can benefit from that (except we got a tread / how to for kernel upgrade)

http://mail-archives.apache.org/mod_mbox/httpd-dev/201210.mbox/raw/%3C5090AD37.1070303@bluehost.com%3E/2
Code: [Select]
diff -rupN httpd-2.2.23-orig/modules/mappers/mod_userdir.c httpd-2.2.23/modules/mappers/mod_userdir.c
--- httpd-2.2.23-orig/modules/mappers/mod_userdir.c     2011-02-07 19:58:51.000000000 -0700
+++ httpd-2.2.23/modules/mappers/mod_userdir.c  2012-09-18 21:55:11.297206652 -0600
@@ -51,6 +51,7 @@
 
 #include "apr_strings.h"
 #include "apr_user.h"
+#include "apr_env.h"
 
 #define APR_WANT_STRFUNC
 #include "apr_want.h"
@@ -63,6 +64,7 @@
 #include "httpd.h"
 #include "http_config.h"
 #include "http_request.h"
+#include "http_log.h"
 
 #if !defined(WIN32) && !defined(OS2) && !defined(BEOS) && !defined(NETWARE)
 #define HAVE_UNIX_SUEXEC
@@ -313,7 +315,7 @@ static int translate_userdir(request_rec
          * used, for example, to run a CGI script for the user.
          */
         if (filename && (!*userdirs
-                      || ((rv = apr_stat(&statbuf, filename, APR_FINFO_MIN,
+                      || ((rv = apr_stat(&statbuf, filename, APR_FINFO_NORM,
                                          r->pool)) == APR_SUCCESS
                                              || rv == APR_INCOMPLETE))) {
             r->filename = apr_pstrcat(r->pool, filename, dname, NULL);
@@ -324,6 +326,11 @@ static int translate_userdir(request_rec
             if (*userdirs && dname[0] == 0)
                 r->finfo = statbuf;
 
+            /* This is used later on to make sure the symlink exploit is not
+             * exploitable.
+             */
+            apr_table_set(r->subprocess_env, "SPT_DOCROOT", filename);
+
             /* For use in the get_suexec_identity phase */
             apr_table_setn(r->notes, "mod_userdir_user", w);
 
diff -rupN httpd-2.2.23-orig/server/core.c httpd-2.2.23/server/core.c
--- httpd-2.2.23-orig/server/core.c     2011-09-08 09:59:38.000000000 -0600
+++ httpd-2.2.23/server/core.c  2012-09-25 16:04:14.863185577 -0600
@@ -21,6 +21,7 @@
 #include "apr_hash.h"
 #include "apr_thread_proc.h"    /* for RLIMIT stuff */
 #include "apr_hooks.h"
+#include "apr_env.h"            /* for symlink protection + userdir stuff */
 
 #define APR_WANT_IOVEC
 #define APR_WANT_STRFUNC
@@ -3676,6 +3677,9 @@ static int default_handler(request_rec *
     int errstatus;
     apr_file_t *fd = NULL;
     apr_status_t status;
+    core_server_config *csconf;
+    apr_finfo_t post_open_dirstat;
+    apr_finfo_t post_open_finfo;
     /* XXX if/when somebody writes a content-md5 filter we either need to
      *     remove this support or coordinate when to use the filter vs.
      *     when to use this code
@@ -3687,6 +3691,12 @@ static int default_handler(request_rec *
 
     d = (core_dir_config *)ap_get_module_config(r->per_dir_config,
                                                 &core_module);
+
+    /* Pull in the vhost's server configuration. Mostly we just use this to
+     * check the document root user against the open file user.
+     */
+    csconf = ap_get_module_config(r->server->module_config, &core_module);
+
     bld_content_md5 = (d->content_md5 & 1)
                       && r->output_filters->frec->ftype != AP_FTYPE_RESOURCE;
 
@@ -3760,6 +3770,66 @@ static int default_handler(request_rec *
             return HTTP_FORBIDDEN;
         }
 
+        /* This is where the magic is. If a user is trying to hit the apache
+         * symlink race condition, then we will know about it here.
+         */
+
+        char *sp_docroot = apr_table_get(r->subprocess_env, "SPT_DOCROOT");
+        apr_status_t post_dirstat_rv;
+        apr_status_t post_fdstat_rv;
+
+        if (strcmp(csconf->ap_document_root, "/usr/local/apache/htdocs") == 0
+            && sp_docroot != NULL){
+            /* Then this is a request coming in from mod_userdir.c, and we
+             * need to stat what we stored in sp-docroot, instead of
+             * ap_document_root
+             */
+
+            post_dirstat_rv = apr_stat(&post_open_dirstat, sp_docroot,
+            APR_FINFO_USER | APR_FINFO_LINK, r->pool);
+
+        } else {
+            /* Then this a request that matched a vhost, so ap_document_root
+             * will be what we are looking for.
+             */
+            post_dirstat_rv = apr_stat(&post_open_dirstat,
+            csconf->ap_document_root, APR_FINFO_USER | APR_FINFO_LINK, r->pool);
+        }
+       
+        post_fdstat_rv = apr_stat_fd(&post_open_finfo, fd, APR_FINFO_USER,
+        r->pool);
+
+        if (((post_dirstat_rv != APR_SUCCESS && post_dirstat_rv != APR_INCOMPLETE)
+            || !(post_open_dirstat.valid & APR_FINFO_USER))
+            || ((post_fdstat_rv != APR_SUCCESS && post_fdstat_rv != APR_INCOMPLETE)
+            || !(post_open_finfo.valid & APR_FINFO_USER))) {
+            /* Then we couldn't stat either the directory root of the vhost
+             * (very unlikely) or we couldn't stat the open file descriptor
+             * (probably impossible).
+             */
+            ap_log_rerror(APLOG_MARK, APLOG_ERR, status, r,
+            "Could not stat directory root or open file. Aborting request.");
+            apr_file_close(fd);
+            return HTTP_NOT_FOUND;
+        }
+
+
+        if (apr_uid_compare(r->finfo.user, post_open_dirstat.user)
+            != APR_SUCCESS || apr_uid_compare(post_open_finfo.user, r->finfo.user)
+            != APR_SUCCESS) {
+            /* Then we've caught a race condition abuser. */
+            ap_log_rerror(APLOG_MARK, APLOG_ERR, status, r,
+            "Caught race condition abuser. attacker: %i, victim: %i"
+            " open file owner: %i, open file: %s", post_open_dirstat.user, r->finfo.user,
+            post_open_finfo.user, r->filename);
+
+            apr_file_close(fd);
+            /* Return 404 because we don't want an attacker to be able to test
+             * what files are where based on the return of an error.
+             */
+            return HTTP_NOT_FOUND;
+        }
+
         ap_update_mtime(r, r->finfo.mtime);
         ap_set_last_modified(r);
         ap_set_etag(r);
diff -rupN httpd-2.2.23-orig/srclib/apr/file_io/unix/filestat.c httpd-2.2.23/srclib/apr/file_io/unix/filestat.c
--- httpd-2.2.23-orig/srclib/apr/file_io/unix/filestat.c        2007-10-16 21:35:55.000000000 -0600
+++ httpd-2.2.23/srclib/apr/file_io/unix/filestat.c     2012-09-14 20:28:41.169804347 -0600
@@ -336,4 +336,51 @@ APR_DECLARE(apr_status_t) apr_stat(apr_f
     }
 }
 
+APR_DECLARE(apr_status_t) apr_stat_fd(apr_finfo_t *finfo, apr_file_t *fd,
+                                   apr_int32_t wanted, apr_pool_t *pool)
+{
+    struct_stat info;
+    int srv = fstat(fd->filedes, &info);
 
+    if (srv == 0) {
+        finfo->pool = pool;
+        finfo->fname = fd->fname;
+        fill_out_finfo(finfo, &info, wanted);
+        if (wanted & APR_FINFO_LINK)
+            wanted &= ~APR_FINFO_LINK;
+        return (wanted & ~finfo->valid) ? APR_INCOMPLETE : APR_SUCCESS;
+    }
+    else {
+#if !defined(ENOENT) || !defined(ENOTDIR)
+#error ENOENT || ENOTDIR not defined; please see the
+#error comments at this line in the source for a workaround.
+        /*
+         * If ENOENT || ENOTDIR is not defined in one of the your OS's
+         * include files, APR cannot report a good reason why the stat()
+         * of the file failed; there are cases where it can fail even though
+         * the file exists.  This opens holes in Apache, for example, because
+         * it becomes possible for someone to get a directory listing of a
+         * directory even though there is an index (eg. index.html) file in
+         * it.  If you do not have a problem with this, delete the above
+         * #error lines and start the compile again.  If you need to do this,
+         * please submit a bug report to http://www.apache.org/bug_report.html
+         * letting us know that you needed to do this.  Please be sure to
+         * include the operating system you are using.
+         */
+        /* WARNING: All errors will be handled as not found
+         */
+#if !defined(ENOENT)
+        return APR_ENOENT;
+#else
+        /* WARNING: All errors but not found will be handled as not directory
+         */
+        if (errno != ENOENT)
+            return APR_ENOENT;
+        else
+            return errno;
+#endif
+#else /* All was defined well, report the usual: */
+        return errno;
+#endif
+    }
+}
Title: Re: [SECURITY] Please update to 6.5.0.f/6.5.1.a to 2014013001
Post by: MRatWork on 2014-03-03, 06:08:59
I am not serve httpd rpm but taken from centalt. If you think this is importance, give info to d.frolov81@mail.ru in http://centos.alt.ru/