Is Hestiacp secure from local attack?

Community Support General Questions
1

Vladimir is a security expert who has recently researched control panels and discovered several security vulnerabilities.

Unfortunately, Hestiacp was not included in his research.

The described security flaw is as follows: Suppose Vladimir has a website on a server and can upload PHP files. He can hack other users’ websites hosted on the same server.

This is quite serious as it allows one customer to hack other customers’ websites.

Below are his articles on this topic.

HestiaCP Admins/MODs, please review the articles and determine whether Hestiacp is susceptible to such vulnerabilities.

Thank you.

1 Like
2

Yes we where in the past it should now not possible…

3

Thank you for your confirmation.

4

Sadly, Hestia is also vulnerable to this type of issues.

2 Likes
5

Looking forward to your private bug reports to the team to improve Hestia.

1 Like
6

Yes, I already did that 6 weeks ago and it was verified, unfortunately there has been no activity since then…

3 Likes
7

Thanks Smitka, for your confirmation

8

Hello Mr. Smitka!

Thanks for your marvellous research and identification of this security flaw. Would you please be kind to confirm that the following is true:

Statement:
If we do not use PHP-FPM at the moment or deactivate it until the HestiaCP team offers a solution, then it should be fine.

Looks very logical be I want an answer from you.

This vulnerability is triggered only through a local access, where an user having access to the system can elevate rights and cause damages.

Statement:
So if there are no users, who have an access, then the HestiaCP panel is not vulnerable.

Again, I know that it should be fine. But I want an answer from you.

NB: I do not have any other users and user the panel all for myself.

9

If we do not use PHP-FPM at the moment or deactivate it until the HestiaCP team, then it should be fine.

Default install always uses PHP-FPM even with Apache2

This vulnerability is triggered only through a local access, where an user having access to the system can elevate rights and cause damages.

Yes local access is required via a vulnerability in a “3rd” party software (Wordpress, Drupal, Plugin, whatever) or via direct access…

You would not be able to execute commands root user or even access files under the admin user…

Only files of non admin users can be accessed…

So the main thing that needs to be prevented the access of the hestiamail user outside the scope (Roundcube / PHPmyadmin)

10

Hello Markus!

Thanks. Yes, I saw that this is no longer an option.

What Mr. Smitka found out is very serious. While the php-fpm makes is faster, no one wants such a huge vulnerability.

As a rescue solution it should be possible to offer a quick solution - as a patch - such that one can install only Nginx and Apache2 as a solution without php-fpm.

What do you think on this interim solution?

I was planning to test 1.9-alpha soon. In this version, one could give a possibility to simply install only one server i.e. Nginx.

What do you think?

11
  1. Yes, if you only use mod_php (not ideal), this type of vulnerability is not there. It’s not a problem of the PHP FPM itself, but of its improper configuration. Unfortunately I don’t know the details of Hestia internals, so I can’t judge the reason for this PHP configuration for hestiamail users. But it seems to me that there should be no major problem to convert the configuration of this FPM pool from TCP sockets to Unix sockets with the correct permissions.
  2. Yes, to exploit it, I need to be able to execute the code on one of the sites on the server - either on my own, because I have access, or by exploiting some vulnerability in WP etc… The impact is that I can read the source files of the neighboring sites and get, for example, the content of wp-config.php.
12

Hello Mr. Smitka!

Thanks for your answer. Appreciate it.

Well, in a way your above statement is difficult for me to grasp. So let me ask you more precise manner for my understanding.

Currently the HestiaCP uses unix sockets with listen.mode = 0660 in a general config file as follows:

chmod 0660 hestiamail:www-data /run/php/php8.3-fpm.dummy.sock

The HestiaCP uses unix sockets for each individual users for specific domain .com as follows:

chmod 0660 username:www-data /run/php/php8.3-fpm-domain.com.sock

In a nutshell, your research showed that the user having an access to php8.3-fpm-domain.com.sock (username:www-data) can elevate his rights at the socket level to hestiamail:www-data by using php8.3-fpm.dummy.sock.

Is my understanding of the reported vulnerability correct?

This has a logical conclusion that there are only three possibilities:

chmod 0600 hestiamail:www-data /run/php/php8.3-fpm.dummy.sock
chmod 0660 username:www-data /run/php/php8.3-fpm-domain.com.sock

I never tried or understood, if this works. However your statement on “improper configuration” indicitaes this way of solving the reported vulnerability that does not permit any write.

It still permits a read, though. But uploading your mini browser to implant the exploit will not longer be possible.

The core team of php-fpm launches a jail concept of using the sockets and seperate the use of php8.3-fpm.dummy.sock, which cannot be accessed by a php8.3-fpm-domain.com.sock.

So there is no read and write communication. It will simply be there for technical reasons.

But this variant does not exists.

Do not use php-fpm.

Is this correct understanding?

Currently, there isn’t any possibility to use php-fpm (until a jail concept is launched) because it will always have to maintain a read access over the (TCP/unix) socket.

13

I am aware that the problem is not visible at a glance and I purposely did not want to share the exact exploit instructions (I shared a working exploit with the hestia team).

Unfortunately, many people don’t know that a web user doesn’t need to have any rights to their PHP socket, only the user running the web server needs those. If this rule is not applied, vulnerabilities arise.

Using PHP-FPM is definitely good. It just needs to be set up correctly - for example never use TCP sockets on single server setup.

The unix socket permissions you show are part of another vulnerability that allows the user to change their php settings, allowing them to, for example, enable otherwise disabled system functions and thus use the server for crypto mining or implant code in RAM to reinfect the site.

14

Did you test with CyberPanel?

It seems there is no free panel to get safe from local attacks!?

15

Thanks @smitka for your valuable time and efforts on this open source project.

I’m sure this exploit is one of the toughest to patch and hestia devs are scratching their head to find a solution(i’m not an expert).

Otherwise, hestia team would have fixed it in no time as they are very active at dev work.

It will be great if @eris could mention something on the status of resolving this issue.

16

I guess it’s not easy to fix. Smitka reported this problem to many CPs such as HestiaCP, CloudPanel… but it’s still not fixed.

17

@webmasteroffers @eris
I think there should be a kind of association(at least a forum) of open source control panel developers, where they can co-ordinate with each other on issues affecting all control panels like this one instead of splitting into dev segments each trying to solve the same problem wasting valuable resources.

18

We currently have a patch for the issue in testing, we plan to ship out a secured version of hestia as soon as possible.

3 Likes
19

@smitka Please check if its working

1 Like