Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Security vulnerability: DoS infinite loop bug found in TagFilter
The TagFilter class found in a number of CubicleSoft products is one of the most powerful tag parsing classes out there that has the proven ability to handle some of the ugliest HTML out there.  Under the hood, it gets most of its critical functionality from its streaming state engine.  Unfortunately, any TagFilter instance prior to today's release is vulnerable to a Denial of Service attack whereby the state engine can be tricked into entering an infinite loop by submitting bad input.  Generally, PHP itself will kill the process after a while, but not without consuming 1 core of CPU in the process.  An attacker can remotely exploit this to perform a complete Denial of Service attack against the system with as little as two bytes of input.

The Ultimate Web Scraper Toolkit is of special note today since it includes TagFilter and boasts about TagFilter being able to filter evil user input as a replacement for HTML Purifier.  When used in such a context, malicious users can easily trigger the vulnerability.

All users of TagFilter, especially those using the class to sanitize inputs, are encouraged to upgrade to the latest release as soon as possible.  Since this is core to TagFilter, any untrusted user input OR utilizing the streaming capabilities and submitting partial input can trigger the vulnerability.

What follows is a brief technical breakdown of the vulnerability and affected CubicleSoft products.

Example input:  </

The state engine recognizes the first character as the start of a tag.  The '/' is recognized as the start of a closing tag.  Since this is the end of the input stream, the tag name becomes the empty string.  Then the code attempts to find either the start of a new tag, the end of the current tag, the start of a key, or the start of a string.  Since this is the end of the input, the state does not change and the loop begins again.

Partial stream input can also accidentally trigger the vulnerability.  For example, parsing a large HTML file in chunks as it comes across the network.

The patch released today checks to see if the state has NOT changed after each inner loop.  If it hasn't changed, then the end of the input was reached before anything was detected and a rogue start tag is assumed.  The state is forced into a sensible "exit" state and the loop drops out.


Directly affected CubicleSoft products:
  • Ultimate Web Scraper Toolkit (UWST)
  • Ultimate E-mail Toolkit (UET)

The Ultimate Web Scraper Toolkit is the more severe of the two products due to TagFilter's prominent placement as a HTML Purifier replacement.

The Ultimate E-mail Toolkit only uses TagFilter to convert HTML to plain text so the problems presented are significantly lessened.  If users can get past defenses that generate the HTML in the first place to write their own HTML AND be able to control the last bytes of their HTML before it is handed off to TagFilter, then that can trigger the vulnerability, but that is more of an issue of the author who wrote the code to generate the e-mail than with TagFilter itself (i.e. the author's code doesn't properly sanitize user input).

Indirectly affected CubicleSoft products as a result of using the above:
  • Automated nightly CubicleSoft PHP library collection repositories (UWST, UET)
  • Barebones SSO Server (UET, UWST)

Note that SSO clients are unaffected and only SSO server admins can trigger the vulnerability in the SSO server side of things from the admin interface.  In other words, even though SSO server is affected, the impact is negligible.

The following is a list of indirectly affected CubicleSoft products that probably don't have any issues even though the TagFilter class is included:
  • Cloud Backup (UET - HTML e-mail isn't used so TagFilter is spurious)
  • Cloud Storage Server + extensions (UWST - TagFilter isn't used anywhere, just spurious inclusion)
  • Status Tracker (UET - HTML e-mail isn't used so TagFilter is spurious)
  • DigitalOcean SDK + CLI (UWST - TagFilter isn't used anywhere, just spurious inclusion)

CubicleSoft aims to make its software vulnerability-free and generally meets that objective. Today's announcement is, of course, a bit of a setback in those goals.  It should be noted that this is the only major security vulnerability that CubicleSoft has produced in the last decade across several hundred thousand lines of hardened application and library code. State engines are a little more difficult to write than other types of software and HTML tag parsing presents a number of interesting challenges.

This security vulnerability was discovered by accident in a production environment where TagFilter had already been in use for over a year without incident.  The rest of TagFilter, which includes a second state engine for parsing CSS3 selectors, and the SMTP class' e-mail address parsing state engine were evaluated for additional related vulnerabilities but none were found.
Author of Barebones CMS

If you found my reply to be helpful, be sure to donate!
All funding goes toward future product development.

Forum Jump:

Users browsing this thread: 1 Guest(s)
© CubicleSoft