mafields

In reviewing our webserver logs after patching to 3.6.1, we noticed a successful attempt to perform a password reset against a site administrator on one of our sites. The specific details were slightly different than the successful attacks prior to the 3.6.1 patch being applied.

According to our logs, a password reset was requested and then successfully used 15 seconds later, and we have audit logs from Google that indicate the mail was never opened, so it’s not a case of a compromised mail account. Also interestingly, although the mail headers indicate that the mail was sent via Post-SMTP, there’s no record of it in the mail log, unlike the previous attacks we’ve seen.

This seems to imply there is an additional vulnerability, which may be skipping the mail log and somehow exposing the message to an attacker via some other means.

I’ve intentionally omitted specific details of the attack, but feel free to contact me for specifics if you’d like to follow up.
—
Matt Fields
Office of Information Technology
NC State University

It looks like there is an infinite loop problem with the latest version.

The wp:tribe/event-links block calls googleCalendarLink, which gets the contents of the post, which calls do_block, which executes the wp:tribe/event-links block, which calls googleCalendarLink, etc, etc, etc.

It looks like this was attempted to be fixed via the call to remove_filter, which prevents the blocks from executing during googleCalendarLink, but it’s called after the calendar link is fetched, so the infinite loop happens anyway.

Moving “remove_filter( ‘the_content’, ‘do_blocks’, 9 );” in src/views/blocks/event-links.php up to just after the very first if statement fixes the issue for me.

I had to revert as well, for the same reason. 3.2.0 works fine.

It looks like in 3.2.1 the following change was made:
/wp-content/plugins/stream/connectors/class-connector-settings.php
– line 718

Before:
$changed_options[] = array(
‘label’ => $this->get_field_label( $option ),
‘option’ => $option,
‘context’ => $context,
// Prevent fatal error when saving option as array
‘old_value’ => (string) maybe_serialize( $old_value ),
‘value’ => (string) maybe_serialize( $value ),
);

After:
$changed_options[] = array(
‘label’ => $this->get_field_label( $option ),
‘option’ => $option,
‘context’ => $context,
‘old_value’ => (string) $old_value,
‘value’ => (string) $value,
);

This means that any array or object results in a fatal error when it is cast to a string unless it is an object with a __toString method.

Reverting this change should fix the error.
Eagerly awaiting this patch.