Boost boost_print_r() doesn't support UTF-8 [#2113293]

Steps to reproduce:

Enable boost debug mode
Create a URL alias with and UTF-8 character in it (I had ™)
Open that page
Boost tries to log the entire global $_boost variable to watchdog calling boost_print_r()
As a result write to the watchdog will fail with a fatal error. As this code is being called after drupal_deliver_html_page() execution, Drupal sends an error page after the normal: in browser you see your normal page and then error page one after other

Comment	File	Size	Author
#7	Recorder bug_lemberg.co_.uk_labs.png	138.29 KB	Taran2L
#4	boost-fixed_utf8_support_in_boost_print_r-2113293-4.patch	640 bytes	Taran2L
#4
#3	boost-fixed_utf8_support_in_boost_print_r-2113293-3.patch	688 bytes	Taran2L
#3

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Anonymous (not verified) CreditAttribution: Anonymous commented 16 October 2013 at 15:56

Assigned:

Unassigned

Just a quick check, is anything ever written to the cache for this URL ? as the error may be caused by the filename and the filesystem not working with UTF-8 characters.

Comment #2

Taran2L

Ukrainian

Lviv

CreditAttribution: Taran2L commented 16 October 2013 at 15:58

Will provide a patch shortly.

File	Size
boost-fixed_utf8_support_in_boost_print_r-2113293-3.patch	688 bytes

Comment #4

Taran2L

Ukrainian

Lviv

CreditAttribution: Taran2L commented 16 October 2013 at 16:06

Status:

Active

» Needs review

File	Size
boost-fixed_utf8_support_in_boost_print_r-2113293-4.patch	640 bytes

Version #2 (I like it more)

This function is being used only for watchdog entries. So, could be rewritten in the following way.

Comment #5

Taran2L

Ukrainian

Lviv

CreditAttribution: Taran2L commented 16 October 2013 at 16:09

Boost fails on debug. And the issue is related to debugging. I'm not sure if the file is being written to the filesystem. But, it's not the case.

If you would like, I can provide screenshot and backtrace log.

Comment #6

Anonymous (not verified) CreditAttribution: Anonymous commented 16 October 2013 at 20:04

Sorry didn't understand the first sentence of that last post, whether the cache file is written to the system is much more of an issue (and whether rewrite rules pick it up), than a watchdog error.

Comment #7

Taran2L

Ukrainian

Lviv

CreditAttribution: Taran2L commented 17 October 2013 at 16:04

File	Size
Recorder bug_lemberg.co_.uk_labs.png	138.29 KB

Drupal crashes trying write debug message to a watchdog; result is:

See attached image.

Why ?

Because when debug is on, boost writes a watchdog entry after main page has been delivered:

boost.module, lines 1422-1428

  // Call original function
  drupal_deliver_html_page($page_callback_result);

  // Last possible place to send a watchdog message without a shutdown function.
  if (variable_get('boost_message_debug', BOOST_MESSAGE_DEBUG) && $_boost['args'][0] != 'admin') {
    watchdog('boost', boost_print_r($_boost), array(), WATCHDOG_DEBUG);
  }

And boost_print_r() has an error (see original code):

function boost_print_r($data) {
  return str_replace('    ', '&nbsp;&nbsp;&nbsp;&nbsp;', nl2br(htmlentities(print_r($data, TRUE))));
}

htmlentities() isn't binary safe (doesn't work with utf-8 characters). It fails, because my url contains trademark

Attached patch fixes this.

Comment #8

Anonymous (not verified) CreditAttribution: Anonymous commented 17 October 2013 at 16:13

The problem with the patch is that it could open up an XSS exploit by allowing < > tags through, have you considered

htmlentities ( string $string [, int $flags = ENT_COMPAT | ENT_HTML401 [, string $encoding = 'UTF-8' [, bool $double_encode = true ]]] )

and using the PHP documentation.

Note: Any other character sets are not recognized. The default encoding will be used instead and a warning will be emitted.

which is probably the source of the error. I'm also much more concerned as to whether the URL translation results in a cacheable file.

Comment #9

Taran2L

Ukrainian

Lviv

CreditAttribution: Taran2L commented 26 December 2013 at 17:05

So, I've done some testing. Discard patch #4. It's could be exploited.

However, patch #3 fixes the problem.

Patch uses check_plain() Drupal built-in filtering function, which uses PHP htmlspecialchars().

Basically speaking htmspecialchars() is a more strict version of the htmlentities().

Patch #3 doesn't allow any tags/special characters/etc

Comment #10

Taran2L

Ukrainian

Lviv

CreditAttribution: Taran2L commented 26 December 2013 at 17:10

How to reproduce:

1. Enable & configure boost
2. Enable boost debug
3. Create a page with an alias page™
4. Go to this page as an anonymous user. Scroll to the bottom of the page to see an error
5. Apply patch in #3 and fix it