Deletion of ofc_upload_image.php Causes Failure of OpenX Upgrade

Last month it was disclosed that there was a vulnerability in the Video Ads plugin for OpenX. The vulnerability is contained in the ofc_upload_image.php file located in/www/admin/plugins/videoReport/lib/ofc2/ directory and is currently being exploited to cause ad servers to include malware on the banner pages they serve. The Video Ads plugin was first included with OpenX in version 2.8.4 and the version included with 2.8.5 and 2.8.6 also contained the vulnerability. The version including in OpenX 2.8.7 does not include the vulnerability, the ofc_upload_image.php file is empty.

In the Product Updates page listing for OpenX 2.8.7, in the OpenX admin interface,  it states:

If you recently upgraded to version 2.8.6, you can simply install an upgraded video ad plug-in available [here] or remove the following file: admin/plugins/videoReport/lib/ofc2/ofc_upload_image.php from your installation.

Others have also made the suggestion that should delete the file. You should not delete the file as this will cause future upgrades of OpenX to fail. Instead, if you are running version 2.8.6 and are not upgrading to version 2.8.7 you should delete the content of the file but not the file itself. If you are currently running version 2.8.5 or below you should upgrade to 2.8.7 as those versions contain other security vulnerabilities.

If you have not done an upgrade since deleting the file adding an empty file named ofc_upload_image.php in the /www/admin/plugins/videoReport/lib/ofc2/ directory will prevent a future upgrade from failing.

If you are currently doing an upgrade and are receiving a red box that says “One or more plugin files couln’t be located, check the install.log file for more information” after you enter the path on the page that says “Provide the path to your previous OpenX installation.” you need to add an empty file named ofc_upload_image.php in the /www/admin/plugins/videoReport/lib/ofc2/ directory and then reenter the path. If you are not sure what the path is you can find it in the configuration file. The path is listed in the webDir parameter, make sure to remove the /www/images from the end of the path listed in the parameter.

If you previously attempted the upgrade and now receive a message that says “Your OpenX database and file structure are both using the most recent version and therefore no upgrade is required at this time. Please click Continue to proceed to the OpenX administration panel.” when you tried to try to perform the upgrade again you have two options. For the first, you will need to change the value of the oa_version record, in the _application_variable table of the database used by OpenX , to version number of OpenX you are currently running and then you need to start the upgrade process again (including deleting the new installation and then uploading a new copy of it). For the second, you will need replace the old OpenX installation with the new one and then you will then need to manually reinstall the plugins. The plugin installation files can be found in the /etc/plugins directory of the OpenX download.

Minor leak, major headache

I find this bug interesting, because at first it looks like a relatively minor cross-origin leak. But with a bit of investigation, it has major consequence.

The bug is specific to Internet Explorer, and still seems unfixed (in stable versions) at the time of writing. I told Microsoft about it back in 2008. Therefore this disclosure is not an 0-day, but more like a 600-day.

The bug is pretty simple: IE supports a window.onerror callback which fires whenever a Javascript parse or runtime error occurs. Trouble is, it fires even if registers its own window.onerror handler and then uses <script src="">. We'll demonstrate the consequence of this later.

The bug has a very interesting history, which is worth briefly outlining here:
So why is this a serious bug? Well, Javascript error messages are usually pretty terse but in at least one case, cross-origin content is echoed back to the attacker: variable names. e.g. 'blah' is not defined.

So if the cross-origin text looks like a Javascript variable reference, then the attacker has a very useful leak!

Here is a proof-of-concept against Google Reader, which works by stealing cross-origin content which happens to be an anti-XSRF token:

As it happens, the Reader product deployed a change which detects the vulnerable User-Agent string (Internet Explorer) and uses a workaround. So the PoC is neutered. This is a shame because the PoC used to force your friend to subscribe to a goat-farming feed against their will. For now, you'll have to locate an alternate attack vector for this vulnerability -- do let me know what you find via a comment.

It's worth closing with some notes that this area is ripe for further research. There are a varied number of text structures which can be stolen (iteratively if necessary) with this trick:
  • a,b,c -- i.e. the CSV syntax
  • The b in a:b
  • a.b.c
  • The b in {a:b}
  • Expression constructs such as a/b/c
  • Constructs like the above, if wrapped in () or [] etc.
To experiment with what Javscript error message you might see with a given piece of cross-origin text, you can use:

(Only works in browsers with window.onerror, such as IE).

Please leave a comment if you have more constructs which can be stolen; or more examples of sites where stuff can be stolen from.

TA10-287A: Oracle Updates for Multiple Vulnerabilities

Original release date: October 14, 2010
Last revised: --
Source: US-CERT

Systems Affected

  • Oracle Database 11g Release 2, version 
  • Oracle Database 11g Release 1, version
  • Oracle Database 10g Release 2, versions and
  • Oracle Database 10g, Release 1, version
  • Oracle Fusion Middleware, 11gR1, versions and
  • Oracle Application Server, 10gR3, version
  • Oracle Application Server, 10gR2, version
  • Oracle BI Publisher, versions,, and
  • Oracle Identity Management 10g, versions and
  • Oracle E-Business Suite Release 12, versions 12.0.4, 12.0.5, 12.0.6, 12.1.1, and 12.1.2
  • Oracle E-Business Suite Release 11i, versions 11.5.10 and
  • Agile PLM, version
  • Oracle Transportation Management, versions 5.5, 6.0, and 6.1
  • PeopleSoft Enterprise CRM, FMS, HCM, and SCM (Supply Chain), versions 8.9, 9.0, and 9.1
  • PeopleSoft Enterprise EPM, Campus Solutions, versions 8.9, 9.0, and 9.1
  • PeopleSoft Enterprise PeopleTools, versions 8.49 and 8.50
  • Siebel Core, versions 7.7, 7.8, 8.0, and 8.1
  • Primavera P6 Enterprise Project Portfolio Management, versions and
  • Oracle Sun Product Suite
  • Oracle VM, version 2.2.1


The Oracle products and components listed above are affected by multiple vulnerabilities. The impacts of these vulnerabilities include remote execution of arbitrary code, information disclosure, and denial of service.

I. Description

The Oracle Critical Patch Update Advisory - October 2010 addresses 85 vulnerabilities in various Oracle products and components, including 31 vulnerabilities in Sun products. The Advisory provides information about affected components, access and authorization required for successful exploitation, and the impact from the vulnerabilities on data confidentiality, integrity, and availability.

Oracle has associated CVE identifiers with the vulnerabilities addressed in this Critical Patch Update. More detail about one of the vulnerabilities is available in US-CERT Vulnerability Note VU#174089.

The Oracle Siebel Suite Executive Summary section of the Oracle Advisory notes, "None of these vulnerabilities may be remotely exploitable without authentication, i.e., none may be exploited over a network without the need for a username and password." A system with the Siebel Option Pack for IE ActiveX control installed on it can be attacked remotely by an unauthenticated attacker by enticing the user to access a specially crafted HTML file (most likely a web site controlled by the attacker).

II. Impact

The impact of these vulnerabilities varies depending on the product, component, and configuration of the system. Potential consequences include the execution of arbitrary code or commands, information disclosure, and denial of service. Vulnerable components may be available to unauthenticated, remote attackers. An attacker who compromises an Oracle database may be able to access sensitive information.

III. Solution

Apply the appropriate patches or upgrade as specified in the Oracle Critical Patch Update Advisory - October 2010. Note that this document only lists newly corrected issues. Updates to patches for previously known issues are not listed.

IV. References

Feedback can be directed to US-CERT.

Produced 2010 by US-CERT, a government organization. Terms of use

Revision History

October 14, 2010: Initial release

The One Fairly Simple Step To Keep WordPress Secure

We have seen many guides that list many steps that are claimed that you need to take to secure WordPress. There are also companies out there that will charge hundreds of dollars to secure your WordPress installation. But the truth is that there is only one fairly simple step to secure WordPress, keep WordPress and any installed plugins updated. The developers of WordPress agree with us, in blog post about keeping WordPress secure they said:

There is only one real solution. The only thing that I can promise will keep your blog secure today and in the future is upgrading.

The upgrade process involves making a backup of the websites files and database, disabling plugins, and then performing the update of the WordPress installation. WordPress provides a helpful guide that detail the process. If you are currently running version 2.7 or above, WordPress includes an Automatic Update feature that takes care of the updating part of the upgrade for you. If you are running version 2.6.5 or below, you made need to make one or more incremental upgrades to avoid potential issues. If you need help upgrading, especially if you are currently running a very outdated version, we can perform the upgrade of WordPress for you.

Will This Protect You From All Hackings?

The simple answer is no. Many hackings occur because of the FTP credentials for the website have been compromised or through a hosting provider being hacked. Nothing you do to WordPress installation will prevent these from happening because they do not take advantage of a vulnerability in WordPress. You can find our suggestion on the steps the steps you need to take to prevent those types of hackings here.