Facebook Twitter Gplus LinkedIn RSS

Sunday, May 7, 2017

Openstack Cinder Volume Delete (slow) Juno/Kilo/Liberty HACK


There is a bug in openstack Liberty and below where even if you set the config to not zero out volumes upon deletion, it ignores those configuration directives and still zero's out  the volume to properly wipe them for security reason's.

Now if you don't care about that because you are doing dev work and need quick deleting volumes you can use the below command to fix the cinder volume driver on the cinder server.

sed -i "s/default='zero'/default='none'/" /usr/lib/python2.7/site-packages/cinder/volume/driver.py

After executing the above command on your cinder server, restart the cinder services

WARNING: Please keep in mine the above is not secure and should not be used in production.

Thursday, March 24, 2016

VyOS Site to Site IPSEC VPN - Openstack Tenant


Summary: 

 I am putting this post together to help others out there that are trying to create a site to site VPN tunnel between different Openstack regions OR even Cloud Providers (Openstack). The VyOS configuration portions can be leveraged for those trying to setup AWS VPC to VPC IPSEC tunnels as well. Everything I have posted in here can be found on the internet, but the information wasn't all in once easy to find place.

 Requirements: 

  • openstack >= Icehouse/Juno
  • Neutron
    • allowed address pairs
    • floating IP's
    • ability to create and update your private network and subnet settings
    • cli tools installed and can run commands in your tenant space
  • VyOS 1.1.7 from here VyOS Image
  • above VyOS converted to a qcow image and uploaded into glance (if I receive enough requests I can post either the instructions or a working image)


Example Diagram:


Openstack Project setup:

Go ahead and create your network, subnet and router similar to the above diagram if you haven't done so already.

Next launch an instance using the image you have already created and uploaded into glance, if people are having a lot of trouble doing this, I will see if I can add the instructions to this post on how to do this. If people are concerned about HA setups, I can look to add that later as well, it isn't difficult to do.


We now need to create a security group that will allow the correct traffic to and through this VM so the VPN will work, please modify to fit your needs, this is NOT a secure setup and will allow all traffic from both sides of the VPN to traverse. Replace <VYOS2_FIP>/CIDR with the appropriate value for your setup.

Security Group Setup: using neutron cli 
neutron security-group-create vyos-dc1
neutron security-group-rule-create --direction ingress --ethertype ipv4 --protocol tcp --port-range-min 1 --port-range-max 65535 --remote-ip-prefix <LOCAL_SUBNET_2>/<CIDR> vyos-dc1
neutron security-group-rule-create --direction ingress --ethertype ipv4 --protocol udp --port-range-min 1 --port-range-max 65535 --remote-ip-prefix <LOCAL_SUBNET_2>/<CIDR> vyos-dc1
neutron security-group-rule-create --direction ingress --ethertype ipv4 --protocol tcp --port-range-min 1 --port-range-max 65535 --remote-ip-prefix <LOCAL_SUBNET_1>/<CIDR> vyos-dc1
neutron security-group-rule-create --direction ingress --ethertype ipv4 --protocol udp --port-range-min 1 --port-range-max 65535 --remote-ip-prefix <LOCAL_SUBNET_1>/<CIDR> vyos-dc1
neutron security-group-rule-create --direction ingress --ethertype ipv4 --protocol tcp --port-range-min 1 --port-range-max 65535 --remote-ip-prefix <VYOS2_FIP>/<CIDR> vyos-dc1
neutron security-group-rule-create --direction ingress --ethertype ipv4 --protocol udp --port-range-min 1 --port-range-max 65535 --remote-ip-prefix <VYOS2_FIP>/<CIDR> vyos-dc1
neutron security-group-rule-create --direction ingress --ethertype ipv4 --protocol icmp --remote-ip-prefix 0.0.0.0/0 vyos-dc1

Setup: VyOS Region1

You will need to use the console access from horizon in order to run the below commands to get ssh working and DHCP cannot be used as the VyOS doesn't seem to support that with IPSEC tunnels,  it doesn't seem to be able to determine the IP, see references at the bottom.

VyOS Server 1; Horizon Console Access
configure
set interfaces ethernet eth0 address <LOCAL_VYOS1_IP>/<CIDR>
set service ssh port '22'
set protocols static route 0.0.0.0/0 next-hop <LOCAL_NETWORK_GATEWAY> distance '1'
set protocols static route <LOCAL_SUBNET_2>/<CIDR> next-hop <VYOS2_FIP>
commit
save

SSH to the VyOS server in order to configure it and run the below configuration commands to setup the IPSEC tunnel

VyOS Server 1 Config: SSH access
configure
set vpn ipsec esp-group office-srv-esp compression 'disable'
set vpn ipsec esp-group office-srv-esp lifetime '1800'
set vpn ipsec esp-group office-srv-esp mode 'tunnel'
set vpn ipsec esp-group office-srv-esp pfs 'enable'
set vpn ipsec esp-group office-srv-esp proposal 1 encryption 'aes256'
set vpn ipsec esp-group office-srv-esp proposal 1 hash 'sha1'
set vpn ipsec ike-group office-srv-ike ikev2-reauth 'no'
set vpn ipsec ike-group office-srv-ike key-exchange 'ikev1'
set vpn ipsec ike-group office-srv-ike lifetime '3600'
set vpn ipsec ike-group office-srv-ike proposal 1 encryption 'aes256'
set vpn ipsec ike-group office-srv-ike proposal 1 hash 'sha1'
set vpn ipsec ike-group office-srv-ike dead-peer-detection action 'restart'
set vpn ipsec ike-group office-srv-ike dead-peer-detection interval '30'
set vpn ipsec ike-group office-srv-ike dead-peer-detection timeout '30'
set vpn ipsec auto-update '60'
set vpn ipsec ipsec-interfaces interface 'eth0'
set vpn ipsec site-to-site peer <VYOS2_FIP> authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer <VYOS2_FIP> authentication pre-shared-secret '<CHANGEME>'
set vpn ipsec site-to-site peer <VYOS2_FIP> ike-group 'office-srv-ike'
set vpn ipsec site-to-site peer <VYOS2_FIP> local-address '<LOCAL_VYOS1_IP>'
set vpn ipsec site-to-site peer <VYOS2_FIP> authentication remote-id '<LOCAL_VYOS2_IP>'
set vpn ipsec site-to-site peer <VYOS2_FIP> tunnel 0 allow-nat-networks 'disable'
set vpn ipsec site-to-site peer <VYOS2_FIP> tunnel 0 allow-public-networks 'disable'
set vpn ipsec site-to-site peer <VYOS2_FIP> tunnel 0 esp-group 'office-srv-esp'
set vpn ipsec site-to-site peer <VYOS2_FIP> tunnel 0 local prefix '<LOCAL_SUBNET_1>/<CIDR>'
set vpn ipsec site-to-site peer <VYOS2_FIP> tunnel 0 remote prefix '<LOCAL_SUBNET_2>/<CIDR>'
commit
save

Openstack Region 1 CLI Commands:

Allowed Address Pairs is required to allow traffic to flow over the neutron port, it works in conjunction with OpenVswitch, also if you were to leverage a VIP (pacemaker or keepalived) this would be required to assign multiple IP's to a single port.

First we need to obtain the neutron port ID for the instance we need to update.

Command: using neutron cli
neutron post-list |grep <LOCAL_VYOS1_IP>


Output:
| 536ca7a9-6569-41a9-ad44-8e33d8519472 |      | fa:16:3e:e2:b3:6a | {"subnet_id": "56b874bd-488b-4fd1-a419-c62d26d84ca8", "ip_address": "<LOCAL_VYOS1_IP"} |

The first section between the two pipes | | highlighted in yellow is the neutron port ID we are looking for.

Update port command: using neutron cli
neutron port-update <port-id> --allowed-address-pairs type=dict list=true ip_address=<LOCAL_SUBNET_2>


We now need to update the subnet settings in order to automatically insert routes for the other network over the VPN setup, this will be added through dhcp.  We need the subnet_id in order to rung the update you can either grab the subnet ID from the command above which is the GUID following "subnet_id", or run the command below.


Subnet List: neutron cli
neutron subnet-list |grep <LOCAL_SUBNET_1>

Subnet Update: neutron cli
neutron subnet-update <LOCAL_SUBNET_1_ID> --host_routes type=dict list=true destination=<LOCAL_SUBNET_2>/<CIDR>,nexthop=<LOCAL_VYOS1_IP>



Region 2 Setup:

You can for the most part replicate the above in the other project/data center, changing the IP's and networks for the new site, but I have replicated it below for completeness

If not then as we started above for configuring the Openstack project we must do the same here, if there isn't one already create your network, subnet and router similar to the above diagram.

Next launch an instance using the image you have already created and uploaded into glance.

Then create a security group as we did for the first region, again please modify to fit your needs, this is NOT a secure setup and will allow all traffic from both sides of the VPN to traverse. Replace <VYOS1_FIP>/CIDR with the appropriate value for your setup.

Security Group Setup: using neutron cli 
neutron security-group-create vyos-dc2
neutron security-group-rule-create --direction ingress --ethertype ipv4 --protocol tcp --port-range-min 1 --port-range-max 65535 --remote-ip-prefix <LOCAL_SUBNET_2>/<CIDR> vyos-dc2
neutron security-group-rule-create --direction ingress --ethertype ipv4 --protocol udp --port-range-min 1 --port-range-max 65535 --remote-ip-prefix <LOCAL_SUBNET_2>/<CIDR> vyos-dc2
neutron security-group-rule-create --direction ingress --ethertype ipv4 --protocol tcp --port-range-min 1 --port-range-max 65535 --remote-ip-prefix <LOCAL_SUBNET_1>/<CIDR> vyos-dc2
neutron security-group-rule-create --direction ingress --ethertype ipv4 --protocol udp --port-range-min 1 --port-range-max 65535 --remote-ip-prefix <LOCAL_SUBNET_1>/<CIDR> vyos-dc2
neutron security-group-rule-create --direction ingress --ethertype ipv4 --protocol tcp --port-range-min 1 --port-range-max 65535 --remote-ip-prefix <VYOS1_FIP>/<CIDR> vyos-dc2
neutron security-group-rule-create --direction ingress --ethertype ipv4 --protocol udp --port-range-min 1 --port-range-max 65535 --remote-ip-prefix <VYOS1_FIP>/<CIDR> vyos-dc2
neutron security-group-rule-create --direction ingress --ethertype ipv4 --protocol icmp --remote-ip-prefix 0.0.0.0/0 vyos-dc2



VyOS Server 2 (Region 2)

Like above with VyOS server 1 we need to start configuring the server, firstly we will set up the address on the eth0 interface (adjust for your interface)

VyOS Server 2; Horizon Console Access
configure
set interfaces ethernet eth0 address <LOCAL_VYOS2_IP>/<CIDR>
set service ssh port '22'
set protocols static route 0.0.0.0/0 next-hop <LOCAL_NETWORK_GATEWAY> distance '1'
set protocols static route <LOCAL_SUBNET_1>/<CIDR> next-hop <VYOS1_FIP>
commit
save

SSH to the VyOS server in order to configure it and run the below configuration commands to setup the IPSEC tunnel

VYOS Server 2 Config:
set vpn ipsec esp-group office-srv-esp compression 'disable'
set vpn ipsec esp-group office-srv-esp lifetime '1800'
set vpn ipsec esp-group office-srv-esp mode 'tunnel'
set vpn ipsec esp-group office-srv-esp pfs 'enable'
set vpn ipsec esp-group office-srv-esp proposal 1 encryption 'aes256'
set vpn ipsec esp-group office-srv-esp proposal 1 hash 'sha1'
set vpn ipsec ike-group office-srv-ike ikev2-reauth 'no'
set vpn ipsec ike-group office-srv-ike key-exchange 'ikev1'
set vpn ipsec ike-group office-srv-ike lifetime '3600'
set vpn ipsec ike-group office-srv-ike proposal 1 encryption 'aes256'
set vpn ipsec ike-group office-srv-ike proposal 1 hash 'sha1'
set vpn ipsec ike-group office-srv-ike dead-peer-detection action 'restart'
set vpn ipsec ike-group office-srv-ike dead-peer-detection interval '30'
set vpn ipsec ike-group office-srv-ike dead-peer-detection timeout '30'
set vpn ipsec auto-update '60'
set vpn ipsec ipsec-interfaces interface 'eth0'
set vpn ipsec site-to-site peer <VYOS1_FIP> authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer <VYOS1_FIP> authentication pre-shared-secret '<CHANGEME>'
set vpn ipsec site-to-site peer <VYOS1_FIP> ike-group 'office-srv-ike'
set vpn ipsec site-to-site peer <VYOS1_FIP> local-address '<LOCAL_VYOS2_IP>'
set vpn ipsec site-to-site peer <VYOS1_FIP> authentication remote-id '<LOCAL_VYOS1_IP>'
set vpn ipsec site-to-site peer <VYOS1_FIP> tunnel 0 allow-nat-networks 'disable'
set vpn ipsec site-to-site peer <VYOS1_FIP> tunnel 0 allow-public-networks 'disable'
set vpn ipsec site-to-site peer <VYOS1_FIP> tunnel 0 esp-group 'office-srv-esp'
set vpn ipsec site-to-site peer <VYOS1_FIP> tunnel 0 local prefix '<LOCAL_SUBNET_2>/<CIDR>'
set vpn ipsec site-to-site peer <VYOS1_FIP> tunnel 0 remote prefix '<LOCAL_SUBNET_1>/<CIDR>'
commit
save 

Openstack Region 2 Commands:
neutron post-list |grep <LOCAL_VYOS1_IP>

Output:
| 778675b7-a0fc-4c18-b350-89fa888d9f83 |      | fa:16:3e:fa:2d:a5 | {"subnet_id": "2f485fbf-b17b-4915-be10-8c4c4a32a9ec", "ip_address": "<LOCAL_VYOS2_IP>"} |

The first section between the two pipes | | highlighted in yellow is the neutron port ID we are looking for

Update port command: using neutron cli
neutron port-update <port-id> --allowed-address-pairs type=dict list=true ip_address=<LOCAL_SUBNET_2>


We now need to update the subnet settings in order to automatically insert routes for the other network over the VPN setup, this will be added through dhcp.  We need the subnet_id in order to rung the update you can either grab the subnet ID from the command above which is the GUID following "subnet_id", or run the command below


Subnet List: neutron cli
neutron subnet-list |grep <LOCAL_SUBNET_2>

Subnet Update: neutron cli
neutron subnet-update <LOCAL_SUBNET_2_ID> --host_routes type=dict list=true destination=<LOCAL_SUBNET_1>/<CIDR>,nexthop=<LOCAL_VYOS2_IP>

We should reset the connection on each side to make sure we have a good connection setup

VyOS Server 2: ssh as vyos user
reset vpn ipsec-peer <VYOS1_FIP>

VyOS Server 1: ssh as vyos user
reset vpn ipsec-peer <VYOS2_FIP>



Testing:


Run the below on each VyOS server to see if the first phase is up (first line only)


vyos@vyos:~$ sh vpn ike sa
Peer ID / IP                            Local ID / IP
------------                            -------------
<VYOS1_FIP>                            <LOCAL_VYOS1_IP>

    State  Encrypt  Hash    D-H Grp  NAT-T  A-Time  L-Time
    -----  -------  ----    -------  -----  ------  ------
    up     aes256   sha1    5        no     1289    3600

The state shows up so far so good..

Next run the below on each VyOS server (first line only)

vyos@vyos:~$ sh vpn ipsec sa

Peer ID / IP                            Local ID / IP
------------                            -------------
<VYOS1_FIP>                             <LOCAL_VYOS1_IP>

    Tunnel  State  Bytes Out/In   Encrypt  Hash    NAT-T  A-Time  L-Time  Proto
    ------  -----  -------------  -------  ----    -----  ------  ------  -----
    0       up     78.7K/78.9K    aes256   sha1    no     711     1800    all

As you see the above the tunnel should show as up on each side

Lastly you should be able to ping each sides local interface, if all passes, launch a new instance on each side and test trying to ping one another (assuming you allow ICMP on your security groups for the newly created VM's)

References:

VyOS ipsec vpn site to site setup: http://vyos.net/wiki/User_Guide#Site-to-Site
VyOS Forum troubleshooting connectivity: http://forum.vyos.net/showthread.php?tid=26520
VyOS Tunnel dropping serverfault: http://serverfault.com/questions/586399/vyatta-vpn-ipsec-tunnel-random-dropouts

Contributor: Carlos Pimentel twitter: @DJC_live

Saturday, January 10, 2015

OS::Nova::ServerGroup Backport to Icehouse Completed!!

[Update]

Summary:

I had been waiting for quite some time for OS::Nova::ServerGroup Heat resource feature to be released, unfortunately due to circumstances beyond my control I can't upgrade to Juno and have to stay supporting Icehouse.

I tried to get our IaaS provider to do the backport and ran into the usual, "it will take X long to do this and we aren't even sure if it is possible." I took it upon myself to investigate (given ServerGroups are already supported in the Nova Icehouse release) as it should be fairly trivial since the heat team did all of the work in adding the resource to Juno.

As I expected it was fairly trivial and I was able to accomplish this while watching the Toronto Raptors game..

Proof below

Pre-Requisites:
- Openstack AIO Icehouse or DevStack
- still running the novaclient v 2.17.0 which is the released version for icehouse
- obviously Openstack Heat installed

Version of packages installed:


Template used for test:



Stack Create:



Voila OS::Nova::ServerGroup:




What's next ? well I am going to try and see if I can get this into as patch release of Icehouse, so I wont be publishing the backport here, I have done much more testing then the above, including in an openstack cluster of 30+ compute nodes & controllers and everything is working and distributing across all of the compute nodes nicely. I have not run the openstack unit tests yet. I will update this post soon!!


[Update]

So after conferring with colleagues they do no believe that it would be accepted by the community as a candidate for a patch because of the novaclient changes, so I will post a link to the patch here shortly. One simple option would be to upgrade to the latest novaclient on your openstack heat nodes and make a minor change to two files which I will post as well.






Monday, April 28, 2014

CRITICAL glance [-] ValueError: Tables "migrate_version" have non utf8 collation, please make sure all tables are CHARSET=utf8


Ubuntu 14.04 - Openstack ICEHOUSE release

During the installation of Glance I ran into what seems to be a common problem with this release (supposedly fixed as well) in this release, which is when you run the below command to initialize the database for glance:

# su -s /bin/sh -c "glance-manage db_sync" glance

You receive the below output error.

CRITICAL glance [-] ValueError: Tables "migrate_version" have non utf8 collation, please make sure all tables are CHARSET=utf8

In order to resolve this one (assuming you have access to the mysql database directly) run the commands below.

# mysql -u root -p glance
mysql> alter table migrate_version convert to character set utf8 collate utf8_unicode_ci;
mysql> flush privileges;
mysql> quit
#

You should now be able to run the command below successfully to create the database for glance.

# su -s /bin/sh -c "glance-manage db_sync" glance


Bug ID: https://bugs.launchpad.net/glance/+bug/1279000

Tuesday, March 25, 2014

Openstack Havana ceilometer-alarm-notifier & ceilometer-alarm-evaluator services


The Ubuntu CloudArchive packages, do not create the required ceilometer-alarm-notifier & ceilometer-alarm-evaluator services, which makes using ceilometer somewhat more of a metrics collector than an actual monitoring service without these
I created a bug about this some time ago, it seems the package does not create the upstart services as it should, typically Openstack would say this is the problem of the packager owner in this case ubuntu.

Bug here: https://bugs.launchpad.net/cloud-archive/+bug/1267307
You have to create the upstart services manually.
this might not be the proper way to do it, but it works
Change directory to /etc/init and create the missing conf files 
# cd /etc/init
# vim ceilometer-alarm-evaluator.conf
copy and past the below in the code block
 description "ceilometer-alarm-evaluator"  
 author "Bruce Martins"  
 start on runlevel [2345]  
 stop on runlelvel [!2345]  
 chdir /var/run  
 pre-start script  
     mkdir -p /var/run/ceilometer  
     chown ceilometer:ceilometer /var/run/ceilometer  
     mkdir -p /var/lock/ceilometer  
     chown ceilometer:ceilometer /var/lock/ceilometer  
 end script  
 exec start-stop-daemon --start --chuid ceilometer --exec /usr/bin/ceilometer-alarm-evaluator  
save and then create the second file
#vim ceilometer-alarm-notifier.conf
 description "ceilometer-alarm-evaluator"  
 author "Bruce Martins"  
 start on runlevel [2345]  
 stop on runlelvel [!2345]  
 chdir /var/run  
 pre-start script  
     mkdir -p /var/run/ceilometer  
     chown ceilometer:ceilometer /var/run/ceilometer  
     mkdir -p /var/lock/ceilometer  
     chown ceilometer:ceilometer /var/lock/ceilometer  
 end script  
 exec start-stop-daemon --start --chuid ceilometer --exec /usr/bin/ceilometer-alarm-notifier  
save and exit
change the the init.d directiory
# cd /etc/init.d
create the symbolic links
# ln -s /lib/init/upstart-job ceilometer-alarm-notifier
# ln -s /lib/init/upstart-job ceilometer-alarm-evaluator
then start the services
# service ceilometer-alarm-notifier start
# service ceilometer-alarm-evaluator start

That should resolve the missing services required for ceilometer until fixed in a later patch

Thursday, October 31, 2013

Openstack Havana OpenVSwitch wont start (Ubuntu 12.04LTS)


Intro: I thought I would try to share this with others that may run into the same issues I did with openvswitch installation and where adding bridge interfaces would hang and not actually create the bridge interface on the machine.

Symptoms:
# ovs-vsctl add-br br-int
running the above command would just hang, hitting control-c would end with a warning/error and if you ran that command again it would say that the interface already existed.
# ovs-vsctl show
would show that the interface br-int was created, but running the command that openstack runs to check if the interface exists.
# ip -o link show br-int
returns:
Device "br-int" does not exist.
upon checking the openvswitch-switch service it was no started and had the below log entries in the neutron log
/var/log/neutron/openvswitch-agent.log
Stderr: 'Device "br-int" does not exist.\n'
2013-10-29 13:34:49.759 12968 CRITICAL neutron [-]
Command: ['ip', '-o', 'link', 'show', 'br-int']
Exit code: 1
Stdout: ''
Running a few other checks below help to determine that the openvswitch kernel module isn't loading (I found here on launchpad)
# depmod
# modprobe openvswitch_mod
module not found
FIX: I then was able to find another article on launchpad that solved my particular issue by installing another package link
# apt-get install openvswitch-datapath-dkms
The above will go through and compile the module in, once completed everything should start working and we can test that by running the commands below
# ovs-vsctl add-br br-int
# ovs-vsctl show
04fd431f-06dd-4686-ade5-e3cbd59f63b6
    Bridge br-int
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port "tap2a0a5bb8-b4"
            tag: 1
            Interface "tap2a0a5bb8-b4"
        Port "tapdd47ef99-9b"
            tag: 1
            Interface "tapdd47ef99-9b"
                type: internal
        Port br-int
            Interface br-int
                type: internal
    Bridge br-tun
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port br-tun
            Interface br-tun
                type: internal
    ovs_version: "1.10.2"
I will look for a better/proper fix for this assuming there is one and change this post, or update it if anyone has a better suggestion.

Friday, July 6, 2012

Magento / Zend Framework Vulnerability


There is a serious or critical vulnerability in the Zend Framework which Magento relies heavily on. For those of you not familiar with Magento it is both and Open Source and Enterprise E-commerce platform. Those utilizing Magento's XMLRPC API's will be vulnerable to the Zend Platform XML RPC package vulnerability.

Magento has released a bulletin http://www.magentocommerce.com/blog/comments/important-security-update-zend-platform-vulnerability which advises all of it's users to apply a patch which was released yesterday by Magento which is 10 Days after the release by ZEND http://devzone.zend.com/2397/zend-framework-1-11-12-released/

Why am I writing about a disclosure that is 11 days old ? well Magento is a heavily used product out there and those using it may not be aware an official patch was released yesterday by the company. I also believe we should freely share what is found and help users out there mitigate the risks.

Disclosure:

Credit for discovering the vulnerability goes to the team at SEC Consult Vulnerability Lab Johannes Greil and Kestutis Gudinavicius

Proof of Concept: 
Credit SEC Consult Vulnerability Lab https://www.sec-consult.com/files/20120626-0_zend_framework_xxe_injection.txt

Magento :

POST /index.php/api/xmlrpc HTTP/1.1
Host: $host

<?xml version="1.0"?>
 <!DOCTYPE foo [  
  <!ELEMENT methodName ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<methodCall>
  <methodName>&xxe;</methodName> 
</methodCall> 


Example using SOAPUI request


As you can see above i was able to retrieve the "/etc/passwd" file from the system using a call to the XMLRPC API on Magento.

Solution:

Patch your systems immediately!!!

Magento has made the patches available (above link) in their solution section for both the community and Enterprise Editions as of yesterday. You can do this live with little impact to your site. If you are using cache just make sure to flush that or restart your apache server

How do I know if I have already fallen victim to this vulnerability ?
This will be tough to tell, if you do not use the XMLRPC Magento API look for POST requests to the API per the below in your access logs


192.168.23.1 - - [06/Jul/2012:16:25:52 -0400] "POST /index.php/api/xmlrpc HTTP/1.1" 200 722 "-" "Jakarta Commons-HttpClient/3.1"

What if I cannot patch this right now and want to protect myself even though I am not using the Magento XMLRPC API ?

Well you have two options one is to follow Magento's workaround below

Workaround (taken from the magento blog post)

If the patch cannot be applied immediately, the following instructions can be followed to temporarily disable the RPC functionality that contains the vulnerability. Please be advised, any integrations that rely on the XMLRPC API functionality will no longer work after this workaround is implemented.
  • 1. On the Magento web server, navigate to the www-root where Magento app files are stored.
  • 2. In the wwwroot, navigate to /app/code/core/Mage/Api/controllers.
  • 3. Open XmlrpcController.php for editing.
  • 4. Comment out or delete the body of the method: public indexAction()
  • 5. Save the changes

Optional Workaround
Deny access to the XMLRPC API URI either via apache (rewrite/LocationMatch) or if you are using ModSecurity use that.

URI: /index.php/api/xmlrpc

References:
http://devzone.zend.com/2397/zend-framework-1-11-12-released/
http://www.magentocommerce.com/blog/comments/important-security-update-zend-platform-vulnerability
https://www.sec-consult.com/files/20120626-0_zend_framework_xxe_injection.txt

Special Thanks to @thronic for bringing this vulnerability to my attention today, great PHP developer if you are looking for one.

 
© Bruce Martins
All rights reserved
Bloggerized by Free Blogger Templates
Instruction by Blog Teacher