Whatsapp/ Telegram: under construction Live Chat Submit Ticket   Login

WooCommerce Plug-in Cross-Site Scripting Vulnerability

WooCommerce is an open source e-commerce plugin for WordPress. It is designed for small to large-sized online merchants using WordPress. According to WooCommerce, the plugin now powers over 30% of all online stores running WordPress with over one million downloads.

FortiGuard Labs discovered another Cross-Site Scripting (XSS) vulnerability in WooCommerce. FortiGuard disclosed a different XSS vulnerability in WooCommerce earlier this year, leading Fortinet’s Chris Dawson to ask if it was time to worry about WordPress. As he pointed out,

More often than not, though, plugins don’t get updated simply because WordPress lends itself to a “set it and forget it” mentality. Get everything working, install the extra bits you need, and go on about running your business, not worrying about your website. This ease of use and overall reliability is fantastic for WordPress users, but the false sense of security it creates is a recipe for disaster.

This new vulnerability is caused due to insufficiently sanitizing user-supplied inputs in the product sale price. It could allow remote attackers to launch an XSS attack to gather a user’s sensitive information for further attack, redirect a victim’s browser to malicious website, etc.

Analysis
When submitting a product information update request, vulnerable versions of WooCommerce don’t sanitize the value of product sale price on the server side so that the injected code is also included in the product web page. It can be exploited to attack innocent users visiting the tampered product web page. Any user with edit or higher permission could exploit this vulnerability.

In our proof of concept, we were able to craft a request that, when sent to WordPress WooCommerce, generated a new page and sent it back to the browser. The new web page contains the injected code that can be automatically executed in the browser.

Mitigation
WooCommerce version 2.4.8 and before should upgrade to the latest version of WooCommerce. Networks and users who have deployed Fortinet IPS are automatically protected from this vulnerability by IPS Signature: WordPress.WooCommerce.Plugin.Product.Price.XSS.

Thanks to Fortinet’s FortiGuard Labs for discovering this vulnerability.

cPanel 11.52 on LXC

cPanel 11.52 on LXC

Today, I’ve installed cPanel 11.52 on LXC. LXC knowns as Linux Containers certainly are a lightweight virtualization technology. They are more quite like an enhanced chroot instead of full virtualization like Qemu or VMware, they do not emulate hardware and share the same operating system kernel on a host. Linux-vserver and OpenVZ are two pre-existing, independently developed implementations of containers-like functionality for Linux.

Vastspace has no plan to launch LXC any time soon in spite of the benefits and performance gain over OpenVZ. In case you want to try it out yourself, this is the recommendation from cPanel.

To run cPanel & WHM inside an LXC container, cPanel strongly recommend that you use the following settings:

Host

We strongly recommend that you use Red Hat® Enterprise Linux (RHEL) 7, CloudLinux™ 7, or CentOS 7 as your LXC host. This ensures the best compatibility with cPanel & WHM. While other Linux distributions may work, they require that the system administrator performs additional steps, which we do not support.

Guest

We strongly recommend that your LXC containers use CentOS, RHEL, or CloudLinux 6 as the guest. A CentOS, RHEL, or CloudLinux 7 installation requires additional steps to use it as the guest.

Privileged vs unprivileged containers

cPanel & WHM functions in both privileged and unprivileged containers. We strongly recommend that you run cPanel & WHM in a privileged container, because it expects unrestricted access to the system.

The following limitations are inherent to an unprivileged container:

  • The host operating system treats the root user as a non-root user.
  • You cannot raise the hard limit of a process if you previously lowered it. This action could cause EasyApache 3 to fail.
  • Subtle behavior differences may occur.

Required changes for CentOS 7, RHEL 7, or CloudLinux 7

You must make the following configuration changes to run cPanel & WHM inside an LXC container:

  1. After you create the LXC container, change the lxc.include line in the lxc.conf file to the following line:
    lxc.include = /usr/share/lxc/config/fedora.common.conf
  2. Edit the lxc.conf file to drop setfcap and setpcap capabilities. To do this, comment the following lines:
    1
    2
    # lxc.cap.drop = setpcap
    # lxc.cap.drop = setfcap
  3. If your system uses AppArmor, you must uncomment the following line in the lxc.conf file:
    lxc.aa_profile = unconfined

 

cpanel on Linux Container  - 2015 11 16 15 08 29 - cPanel 11.52 on LXC