Vesta: 0DAY vuln

[dreiggy]

Operating System (OS/VERSION):

Seems ALL

VestaCP Version:

ALL

Installed Software (what you got with the installer):

vestacp backup part

Steps to Reproduce:

https://pentest.blog/vesta-control-panel-second-order-remote-code-execution-0day-step-by-step-analysis/

[ScIT-Raphael]

There is a fix in our fork for this issue, maybe the devs of vesta would like to have a look: https://github.com/hestiacp/hestiacp/commit/1f56a42430dfdb446b76291519bf1a4d5edf624a

[devsrealm]

Anyone looking into this?

[Lupul]

There is a new thread on the Vesta forum regarding this issue, but still no update yet
https://forum.vestacp.com/viewtopic.php?f=10&t=19714

[dpeca]

Here is the fix -> https://github.com/serghey-rodin/vesta/commit/a5712542d7315f45abf6df275744889437393c30

@serghey-rodin must run build in order to push it on apt and rpm repo.

Before he do it, you can get latest code from github by running:
Updating VestaCP on CentOS from official github repo:

yum install -y git
cd /root
rm -rf /root/vesta
git clone https://github.com/serghey-rodin/vesta.git
yes | cp -rf /root/vesta/* /usr/local/vesta

Updating VestaCP on Debian/Ubuntu from official github repo:

apt install -y git
cd /root
rm -rf /root/vesta
git clone https://github.com/serghey-rodin/vesta.git
cp -rf /root/vesta/* /usr/local/vesta

And I must agree with @ScIT-Raphael , I advised the same thing before 2 years, conf parser function instead of eval is the right fix for all vulnerabilities of this type.

[Barmunksu]

maybe it's time to create an alternative RPM\APT repo with 0day hot fix? And update readme

[ScIT-Raphael]

@Barmunksu it would, but also all users would need to change the repository. The only realy save way is to push the deb/rpm packages to the current repository, which also includes an autoupdate function - but @serghey-rodin is the only one with access to it, hopefully he will react...

Otherwise, deb based systems (Ubuntu 16.04/18.04, Debian 8-10) could switch to our fork hestia (https://github.com/hestiacp/hestiacp) or use the patched apt repository of @dpeca (https://github.com/myvesta/vesta), which only supports Debian 10.

[Barmunksu]

it would, but also all users would need to change the repository.

New users will be safe. And those who really need it, will add a new repository. Just add an important note on the forum and here...

[ScIT-Raphael]

@Barmunksu I'm not in the position to decide this, also, as I already wrote, I doesnt have enough time to push and manage a second repo beside hestia.

[ahmiq]

@Barmunksu it would, but also all users would need to change the repository. The only realy save way is to push the deb/rpm packages to the current repository, which also includes an autoupdate function - but @serghey-rodin is the only one with access to it, hopefully he will react...

Otherwise, deb based systems (Ubuntu 16.04/18.04, Debian 8-10) could switch to our fork hestia (https://github.com/hestiacp/hestiacp) or use the patched apt repository of @dpeca (https://github.com/myvesta/vesta), which only supports Debian 10.

Can one directly swtich from the official to Hestia or Myvesta Fork without breaking anything? Perhaps a guide would be great for all users. Thanks

[ScIT-Raphael]

A switch to hestia needs a fresh install, but you can restore your vesta backups using the normal v-restore-user command.

For MyVesta, if you use debian10, it should be possible to "just" switch the repository, probaly @dpeca has more informations.

[Neustradamus]

@serghey-rodin: Any news about this vulnerability?

Remark: It is possible to move the vesta in a organization with devs?

We need to have changes in current Vesta...

I am ready to do it.

[Neustradamus]

@dpeca: It is solved?

[ScIT-Raphael]

They are solved since a long time on the github project, @dpeca has fixed them - but unfortunaly, he can't build the new packages. This can do, as far as I know, only one person, but he doesnt react to anything...

[dpeca]

@Neustradamus
Fixed on March 23 - https://github.com/serghey-rodin/vesta/issues/1984#issuecomment-602308134

[Neustradamus]

@dpeca: Sorry but it is good to recall when the ticket is closed and in the release!

It is very important to create a new release with this fix!

• https://github.com/serghey-rodin/vesta/releases

@serghey-rodin: It is possible to move this repository in an organization and improve it correctly?
The team work must not be stopped...

Currently, there is a big problem of support and security and the project is dead.

@dpeca, @ScIT-Raphael: I am ready to help at several points...

Who manage the official website and social networks?

[dpeca]

I think only @serghey-rodin has access to website and apt/rpm repos.

Fixes are built in HestiaCP and myVesta apt repo the same day we put it on github (March 23).

[asheroto]

+1 for adding and apt/rpm repo

Using Debian 9

[asheroto]

Before he do it, you can get latest code from github by running:
Updating VestaCP on CentOS from official github repo:

yum install -y git
cd /root
rm -rf /root/vesta
git clone https://github.com/serghey-rodin/vesta.git
yes | cp -rf /root/vesta/* /usr/local/vesta

Updating VestaCP on Debian/Ubuntu from official github repo:

apt install -y git
cd /root
rm -rf /root/vesta
git clone https://github.com/serghey-rodin/vesta.git
cp -rf /root/vesta/* /usr/local/vesta

And I must agree with @ScIT-Raphael , I advised the same thing before 2 years, conf parser function instead of eval is the right fix for all vulnerabilities of this type.

Followed your instructions for Debian (using Debian 9). Still showing version 0.9.8 release 26 after restart? Has the fix not been officially released?

[dpeca]

@asheroto

Followed your instructions for Debian (using Debian 9). Still showing version 0.9.8 release 26 after restart? Has the fix not been officially released?

if you get latest code from github, yes, you have all fixes.
the version number is still 26 because it will be altered when Serghey run the build.
but it's anyway just a versioning number.