Hi.
I have old version, v1.0.5.0
It seems the only documented vulnerabilities for Phoenix effects my version.
https://www.cvedetails.com/cve/CVE-2020-27975/
https://www.cvedetails.com/cve/CVE-2020-27976/
https://www.cvedetails.com/cve/CVE-2020-12058/
How can fix these?
Early version vulnerability info
-
Yahalimu
- Member
- Posts: 29
- Joined: Mon Oct 26, 2020 1:27 pm
- Phoenix Version: v1.0.5.0
- Has thanked: 4 times
- Been thanked: 1 time
Re: Early version vulnerability info
I found this info on one of them:
https://herolab.usd.de/security-advisor ... 2020-0026/
It needs admin access so this one's not really an issue for me.
https://herolab.usd.de/security-advisor ... 2020-0026/
It needs admin access so this one's not really an issue for me.
-
ecartz
- Core Team
- Posts: 3084
- Joined: Tue Nov 05, 2019 6:02 pm
- Phoenix Version:
- Has thanked: 4 times
- Been thanked: 208 times
Re: Early version vulnerability info
The last one: https://github.com/CE-PhoenixCart/Phoen ... 73bfc5fec8
The one that you posted as not being an issue just requires removing or otherwise validating the user input From address. E.g. changeto or simply add an E-Mail From.
The first one, you can just remove admin/define_language.php
Note that all three of these rely on you visiting your admin area and some hacker's site in the same browser. If you only view your admin area from a separate browser that you use for nothing else and don't view customer submitted content, none of these are an issue.
We also implemented CSRF protection in all forms to protect against this class of vulnerability. But I don't know a good way to port that back to 1.0.5.0. The easiest way to get that would be to update to the current version. A developer could backport it, but in general, I believe that it would be less work to simply update to the current version, even if that means that you have to update add-ons to keep your current functionality. I.e. I think that it would be easier to update your add-ons to 1.0.8.21 than to backport CSRF to every form on the site.
The SAMESITE setting might help here too. That would be relatively easy to backport. It would probably take a developer, as it requires understanding what the three options are and how to implement them. But it's a relatively modest amount of work.
The one that you posted as not being an issue just requires removing or otherwise validating the user input From address. E.g. change
Code: Select all
$mimemessage->send($customer_data- >get('name', $mail), $customer_data-
>get('email_address', $mail), '', $from, $subject);Code: Select all
$mimemessage->send($customer_data- >get('name', $mail), $customer_data-
>get('email_address', $mail), '', $from, $subject);The first one, you can just remove admin/define_language.php
Note that all three of these rely on you visiting your admin area and some hacker's site in the same browser. If you only view your admin area from a separate browser that you use for nothing else and don't view customer submitted content, none of these are an issue.
We also implemented CSRF protection in all forms to protect against this class of vulnerability. But I don't know a good way to port that back to 1.0.5.0. The easiest way to get that would be to update to the current version. A developer could backport it, but in general, I believe that it would be less work to simply update to the current version, even if that means that you have to update add-ons to keep your current functionality. I.e. I think that it would be easier to update your add-ons to 1.0.8.21 than to backport CSRF to every form on the site.
The SAMESITE setting might help here too. That would be relatively easy to backport. It would probably take a developer, as it requires understanding what the three options are and how to implement them. But it's a relatively modest amount of work.