Jump to content
Masteries

PHPUnit vulnerability on 1.6 shops?

Recommended Posts

Are shops on 1.6 affected? I couldn't find any folder named "PHPUnit" in any of our modules so I presume we're safe?

Share this post


Link to post
Share on other sites

From what I read it should be fine, but check what version of the autoupgrade module do you have.

  • Like 2

Share this post


Link to post
Share on other sites

Shops PS 1.5., 1.6. and PS 1.7. are affected from the vulnerability XSAM_XADOO this means vulnerability in phpunit. For to make sure you are save, please delete all the sub-folders /phpunit/ in the folder /modules mentioned below:

Mainly the knowing modules possibly containing a security lack are:

/modules/autoupgrade/vendor/phpunit

/modules/ps_facetedsearch/vendor/phpunit - if exist, as newer module versions do not have this folder.

/modules/gamification/vendor/phpunit - if exist, as newer module versions do not have this folder.

and third development:

/modules/pscartabandonmentpro/vendor/phpunit

/modules/ps_checkout/vendor/phpunit

If you are on root server, then you can clean them via command line:

find . -type d -name "phpunit" -exec rm -rf {} \;

This command requires the relevant user rights.

Share this post


Link to post
Share on other sites
2 minutes ago, selectshop.at said:

Shops PS 1.5., 1.6. and PS 1.7. are affected from the vulnerability XSAM_XADOO this means vulnerability in phpunit. For to make sure you are save, please delete all the sub-folders /phpunit/ in the folder modules mentioned below:

Mainly the knowing modules possibly containing a security lack are:

/modules/autoupgrade/vendor/phpunit

/modules/ps_facetedsearch/vendor/phpunit - if exist, as newer module versions do not have this folder.

/modules/gamification/vendor/phpunit - if exist, as newer module versions do not have this folder.

and third development:

/modules/pscartabandonmentpro/vendor/phpunit

/modules/ps_checkout/vendor/phpunit

If you are on root server, then you can clean them via command line:


find . -type d -name "phpunit" -exec rm -rf {} \;

This command requires the relevant user rights.

1.6 only has autoupgrade but the rest of the modules are exclusive to 1.7 I believe. Fortunately, I couldn't find any vendor or phpunit directory in any of the modules. Our autoupgrade module version is older as well maybe that's why.

  • Like 1

Share this post


Link to post
Share on other sites

No. gamification module is also a part of the latest PS 1.6. Versions. Furthermore, the problem is the use of external libraries. PS 1.5. could also be affected. Also ps_facettedsearch is a module in PS 1.6. It depends which module version you are using, its possible to contain external libraries as well.

Share this post


Link to post
Share on other sites
2 minutes ago, selectshop.at said:

No. gamification module is also a part of the latest PS 1.6. Versions. Furthermore, the problem is the use of external libraries. PS 1.5. could also be affected.

Oh I see, well just checked it as well. No phpunit folder found. Thanks for providing the information!

Share this post


Link to post
Share on other sites

I found the folder :
 ../modules/gamification/vendor/bin/phpunit

should be also deleted ?
 

Share this post


Link to post
Share on other sites

I don't have phpunit folder but found this file in one of autoupgrade module subfolders: phpunit.xml.dist

Should it be deleted as well?

Share this post


Link to post
Share on other sites
5 hours ago, fiddlestix said:

I found and deleted the folder. Unsure what to do next though.

Nothing. It's done, if you have deleted all the folders I named before.

  • Like 1

Share this post


Link to post
Share on other sites
13 hours ago, dead_meme said:

I don't have phpunit folder but found this file in one of autoupgrade module subfolders: phpunit.xml.dist

Should it be deleted as well?

I have the folder "phpunit.xml" in the /www/modules/gamification.

should be also deleted ?

Share this post


Link to post
Share on other sites

No, it's not necessary. This XML file is only a configuration file and does not pose a threat.

Share this post


Link to post
Share on other sites

I'm using PS 1.6 and while there are no vendor or phpunit folders I do see a phpunit file and a phpunit.xml file in the advancedeucompliance module.  

The phpunit file contains this: 

#!/usr/bin/env sh

main_test_path=../../../tests
${main_test_path}/vendor/bin/phpunit -c .

which includes the "vendor" folder in the path but there's no vendor folder anywhere on the site.

The phpunit.xml file contains this:

<phpunit bootstrap="bootstrap.php">
    <testsuites>
        <testsuite name="Unit">
            <directory>Unit</directory>
        </testsuite>
        <testsuite name="Integration">
            <directory>Integration</directory>
        </testsuite>
    </testsuites>
</phpunit>

I'm assuming these phpunit files are not part of the vulnerability?

Share this post


Link to post
Share on other sites

You are right. The eval-stdin.php file in phpunit is the real problem.

Share this post


Link to post
Share on other sites

there is a "PhpUnit" folder in "/prestashop/vendor/symfony/symfony/src/Symfony/Bridge/" is it safe ? 

Share this post


Link to post
Share on other sites
3 minutes ago, ms_hassan said:

there is a "PhpUnit" folder in "/prestashop/vendor/symfony/symfony/src/Symfony/Bridge/" is it safe ? 

 

I wouldn't take the risk. You should remove any folder/directory that is named "PHPUnit".

Share this post


Link to post
Share on other sites
On 1/6/2020 at 7:26 AM, Masteries said:

Are shops on 1.6 affected? I couldn't find any folder named "PHPUnit" in any of our modules so I presume we're safe?

Yes, if phpunit not found in vulnerable places, it means you are safe  

you can find it by running below command at prestashop root 

find . -type d -name "phpunit" -exec rm -rf {} \;

But please follow prestashop instructions and keep your prestashop up to date 

Share this post


Link to post
Share on other sites
On 1/6/2020 at 2:00 PM, selectshop.at said:

Shops PS 1.5., 1.6. and PS 1.7. are affected from the vulnerability XSAM_XADOO this means vulnerability in phpunit. For to make sure you are save, please delete all the sub-folders /phpunit/ in the folder /modules mentioned below:

If you are on root server, then you can clean them via command line:


find . -type d -name "phpunit" -exec rm -rf {} \;

This command requires the relevant user rights.

I am sorry I disagree with the way you propose using straight such a command line, for many reasons, mainly risk of doing wrong :  

0) You should remind people to make backups first and check backup in second place. 

1) No one should ever perform a [

rm -rf

] without checking first what they are going to delete. For instance, running a [find] command without any [-exec] argument.

2) Using a [rm] with [-rf] is also the most destructive command ever, being performed with root account. Anybody could make a typo, for instance typing a forward "/" slash before the "\;" backslash. Furthermore, if the person reading this line was not able to find this command-line on his own, hazard is high that they could make any mistake in typing this. Last, anyone makes typos.

3) Following Unix principles, (one is that a program (command) should be doing one thing only), [find] is great to locate files, and result of this command should be passed to an [xargs] command that would print (and delete after checking).

4) I would rather advise to :

a) List folders to delete with a harmless command-line : [

find (your "modules" folder absolute pathname) -type d -name "phpunit"

]

 b) Delete them one by one with FTP client If FTP account has appropriate access rights,

c) If not possible, then remove folders one by one using [rm] command-line with absolute filepath using a shell script textfile that could be tested in a dry-run on a test site first before removing recursively on a production web site.

 

 

But people in a hurry could do this directly on the command-line 

(0) Do your backups and check them 

(1) as a dry-run, using a [find]  piped to an [xargs] command with an harmless [ls] command.

[

find Your_"modules"_folder_absolute_pathname -type d -name "phpunit" -print0|xargs -0 -I {} ls -al {}

]

for instance, for a server where "modules" folder is [ /www/htdocs/modules/ ]

find /www/htdocs/modules/ -type d -name "phpunit" -print0|xargs -0 -I {} ls -al {}

 

 

(2) Secondly, using a [find]  piped to an [xargs] command with a [rm -r] command.

[

find (your "modules" folder absolute pathname) -type d -name "phpunit" -print0|xargs -0 -I {} rm --recursive {}

]

 

(3) Check by using the command-line in (1) again to check if some folder are still there

 

(4) If some folders were not removed because of access rights, you can use the same command as 2), but adding the [--force] argument  

[

find (your "modules" folder absolute pathname) -type d -name "phpunit" -print0|xargs -0 -I {} rm --recursive --force {}

]

(Yes, I also recommend using long-names for arguments anytime you can - that also may save you from some typo someday 😉 and improve code readabilty & maintenance)

 

<!> Warning <!> If you don't understand what these commands do, or you got lost or bored before this line 😉  , you should NOT try to use them, and you would better find someone who does understand them.

 

But hey, I can figure that a lot of people are going to disagree with me.  🙂

 

Share this post


Link to post
Share on other sites
3 minutes ago, Phil.It said:

I am sorry I disagree with the way you propose using straight such a command line,

This is not my suggestion, but the official suggestion of Prestashop's core developers. It is an official suggestion ! Furthermore for those knowing how to use command lines, also know what they are doing with such command. For users without knowledge of command lines and/or root privileges they can follow the suggestion to delete the before named folders via FTP.

As server admin I cannot see any risk on the execution of the command line mentiioned before. You cannot do anything wrong. Perhaps you missed, that you should execute the commando inherit from the folder /modules. So you need to cd before to /modules and then execute the command from this directory. By changing the directory and executing the command with relevant user rights it does the same as your code.

On 1/6/2020 at 2:00 PM, selectshop.at said:

For to make sure you are save, please delete all the sub-folders /phpunit/ in the folder /modules mentioned below:

 

Share this post


Link to post
Share on other sites

I have a 1.6 shop that was hacked after i went thru all the steps in the bulletin. I didn't have any of these folders at all so i went about my business.

Anyway we just restored a backup and it's jacked bad. It has all kinds of different files uploaded to it now.

They even installed their own /modules/autoupgrade/vendor/phpunit folder.

I am restoring another backup now that doesn't have any of this in it at all that i can tell.

However they are getting into the site "some other way" than whats posted here.

Share this post


Link to post
Share on other sites

Again when the Critical Security Vulnerability came out my site was fine. I went thru everything and i only had the autoupgrade module installed out of the whole list.

Inside that folder i had nothing. Yet my site went down yesterday over this where they installed all kinds of crazy.php files.

In

public_html/

public_html/modules

Share this post


Link to post
Share on other sites

Hey dead thanks for replying. I did in fact miss the /autoupgrade/vendor/phpunit folder. When i manually checked them based on what i see in my backups. Live and learn i say! So i am in the process of doing another restore now. Thanks for you're support!

 

Edited by Billy (see edit history)

Share this post


Link to post
Share on other sites

Hey how do i check my version of phpunit & or upgrade it? Is this something that my hosting company would do at the server level? TIA

Share this post


Link to post
Share on other sites

You mean Your PHP version? Depending on Your server provider You could change it by Your self or by notifing hosting company. Do You log on server by cPanel or Direct Admin for example?

Share this post


Link to post
Share on other sites
34 minutes ago, Billy said:

No was specifically talking about phpunit version.

 https://phpunit.de/supported-versions.html

I seen somewhere that i should check what version i have. I will get my hosting provided to check for me. Thanks

You actually don't need to upgrade your version of PHPUnit, it's only used for development & testing purposes by Prestashop/third-party module developers. All you have to do is delete the ones found in any vendor folder. You could also upgrade your Prestashop version to the latest as well if you're worried.

The issue is fixed in PHPUnit 7.5.19 and 8.5.1. So we can presume all versions prior to those are affected.

Share this post


Link to post
Share on other sites
On 1/8/2020 at 8:30 AM, fiddlestix said:

I found and deleted the folder. Unsure what to do next though.

No need to do anything it's done

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More