safePath, JFTP Layer and chroot in ftp

[rsd]

Hello,

Just installed 2.0.24 in a Joomla 2.5.14.

I am having the safePath issue a lot of people had.

I do have JFTP layer on.

The ftp server does a chroot in the user's HOME.
So:

Code Select Expand

  /home/user/public_html
is actually
/public_html from inside the ftp layer.

That said, if I specify a path with a full path related to the fs root, I get some:

JFTP:mkdir and JFTP:chown errors.

e.g. /home/user/vmfiles

If I add path relative to the users home like: /vmfiles
I get no JFTP error (as expected),
But when virtuemart tries to access it from PHP fs, it does not find the folders/files.
I get

Warning, the Safe Path is not accessible (does not exist or no permission)

So virtuemart is not taking into account the chroot factor of a ftp layer system, as Joomla does.
It uses the ftp_root config option to do this.


If this is not the problem, please give me some advice.

Raul

[Maxim Pishnyak]

So virtuemart is not taking into account the chroot factor of a ftp layer system, as Joomla does.
It uses the ftp_root config option to do this.

So for example you could use Joomla configuration.php outside web site root, am I right?

[rsd]

So virtuemart is not taking into account the chroot factor of a ftp layer system, as Joomla does.
It uses the ftp_root config option to do this.

So for example you could use Joomla configuration.php outside web site root, am I right?

Not sure where are you going.
This is unrelated.

Anyways, the answer to your question is yes.


I am not sure if you understand the issue exatcly.

PHP (e.g. apache) can see the whole file system (or what is enforced by open_basedir, etc).

And FTP (and then JFTP) is limited to what it is restricted.

For instance you may have:

USER HOME = /home/joe
JOOMLA HOME = /home/joe/public_html/joomla

That said, PHP will always see/work on /home/joe/public_html/joomla

When using JFTP you might have 2 cases:

A.
The first and less used is to have a ftp account without chroot.
In this case:

The JOOMLA HOME from the FTP is the same: /home/joe/public_html/joomla
so, ftp_root config variable will be /home/joe/public_html/joomla to reflec this.

B.
In this case, mostly used, ftp is chrooted to the user's home dir /home/joe.
So for the ftp /home/joe/public_html/joomla is actually /public_html/joomla and the ftp_root config will reflact this.



That said virtumart should be smart about it. And it isn't yet.

A simple way to solve this is:

1. See the Joomla instalation path from the php perspective: e.g. /home/joe/public_html/joomla
2. See that JFTP Layer is in use and look at the ftp_root data: /public_html/joomla
3. Compare both and get the missing prefix from the ftp_root, which would be /home/joe/.  =~ s/$full_path/$ftp_root/;
4. This missing prefix is probaly the chroot from ftp server.
5. So every other operation regarding JFTP outside the Joomla tree (or WEBROOT) should deduct this prefix so that the ftp layer gets the right path.

This is very simple once understood.

If this still a mess to understand or get it done, maybe it is simpler to just not use JFTP at all regarding this safePath stuff.  (let php/apache acess directly).

[jenkinhill]

I see what you are saying here, but with so few people using the FTP layer it would be redundant code in the majority of cases. And with JFTP configuration being removed from the J3.5 installer, only being flagged up if required where the config file cannot be saved, even fewer people will turn it on.

Personally I have never needed JFTP or even turned it on.

[rsd]

I see what you are saying here, but with so few people using the FTP layer it would be redundant code in the majority of cases. And with JFTP configuration being removed from the J3.5 installer, only being flagged up if required where the config file cannot be saved, even fewer people will turn it on.

Personally I have never needed JFTP or even turned it on.

Sad to read it.  This is still J! 2.5 right?


Having a FTP layer was a simple great way to improve security.  Even on no-shared hosts (as J! is not the only thing installed).
Remembering that it is used for write access.  For fast write access there is always a tmp and cache folder.

Modification/intrusion directly in the Joomla files can only occur if the ftp password is stored directly in the config files.

Finally the argument of having apache(or another web server) running as the user is bad.
You get an exclusive user to be run as, but loses performance during fork()s, clone() and uses a lot more memory than without it.
In the end you will end up running a reverse proxy to gain some performance back.


So, with all that said.  It s a pitty to see a E-Commerce component like Virtuemart not supoprting it.


And yes, for as for a security point of view there should nothing else running on the server besides the store, virtuemart could be elagant enough to state it, complementing that in this case (nothing else on the server) a jftp layer is unsupported.

-rsd

[jenkinhill]

Sam Moffatt made an interesting comment about JFTP last year:

The risk of the FTP layer is that the password is stored in a web
accessible location by design (encrypting it doesn't necessarily solve
the problem because you still need to make the key available to the
web application that is already reading from your file system). That
means that anyone can read it and then if the FTP is open to the web
(which often in these sorts of shared hosts is also the case) it
permits anyone to read or write the file system which becomes an
attack vector. If you have a CPanel instance and you use the same
credentials for CPanel (which if you're on a cheap shared host that
won't let you create alternate FTP accounts may be reality) then the
attacker also now has access to all of your CPanel and can potentially
view information there and also manage information there.

https://groups.google.com/forum/#!topic/joomla-dev-cms/MMMTpCXadAc

[rsd]

Sam Moffatt made an interesting comment about JFTP last year:

The risk of the FTP layer is that the password is stored in a web
accessible location by design (encrypting it doesn't necessarily solve
the problem because you still need to make the key available to the
web application that is already reading from your file system). That
means that anyone can read it and then if the FTP is open to the web
(which often in these sorts of shared hosts is also the case) it
permits anyone to read or write the file system which becomes an
attack vector. If you have a CPanel instance and you use the same
credentials for CPanel (which if you're on a cheap shared host that
won't let you create alternate FTP accounts may be reality) then the
attacker also now has access to all of your CPanel and can potentially
view information there and also manage information there.

https://groups.google.com/forum/#!topic/joomla-dev-cms/MMMTpCXadAc

Not quite true.
If you comment the $ftp_pass from the configuration.php file, Joomla will as for the credentials and will never be stored on text.


Unfortunately, most of the issues they try to deal are about users who cant chown the files.

I update the security benefits of JFTP here: https://groups.google.com/forum/?hl=en-GB#!topic/joomla-dev-cms/_IgNdnDhnGI

Anyways, it would be nice to see Virtuemart use it, if enable.   
As you said it wont go away, just be hidden from the installation.

Right now, it still a bug.  Installing it in a clean Joomla 2.5 with JFTP on, will raise issues on the installation. 
If it wont be supported, VM should state it, right?

-rsd

[jenkinhill]

When I said " And with JFTP configuration being removed from the J3.5 installer, only being flagged up if required where the config file cannot be saved, even fewer people will turn it on. " I was talking about J3.5's own installer. The JFTP configuration will only be shown it installation fails due to ownership rules. As this is likely to be far less common with J3.5 owing to more critical host conditions. Already there is talk of removing it entirely from J4, which I guess is about 3 years away.