It's probably best to compare the 4.1.12  upstream version and make sure it
follows whatever they do there. That in theory has been tested. I'm
surprised there was a database update skipped.

And yes the security bug was around having comments too long. I forget the
exact attack method but it was overfilling the field somehow.

 - Craig


On Tue, Aug 16, 2016 at 6:22 PM Brian May <[email protected]> wrote:

> Markus Koschany <[email protected]> writes:
>
> > I also tried to fix CVE-2015-8834 for Wheezy by backporting
> > changeset/32387 but the database upgrade failed, at least I could not
> > log back into the admin backend again. Did you notice a similar issue
> > for Jessie?
>
> I just had a look at this issue. Not sure I understand why the database
> upgrade failed, however I think I see bigger problem.
>
> Part of the patch changes the db_version:
>
> -$wp_db_version = 30133;
> +$wp_db_version = 30135;
>
> It puts in a new migration after:
>
>         if ( $wp_current_db_version < 29630 )
>                 upgrade_400();
>
> The exact addition is:
>
>         if ( $wp_current_db_version < 30135 )
>                 upgrade_415();
>
> It looks like this upgrade_415() checks all stored comments, and deletes
> entries where the comment length is too long. It would appear that mysql
> doesn't enforce the maximum length when writing the comment, and somehow
> this causes a security issue when we later read it back (not sure I
> really understand this).
>
> In Wheezy the db version is:
>
> $wp_db_version = 24448;
>
> In wheezy the latest migration is:
>
>         if ( $wp_current_db_version < 22422 )
>                 upgrade_350();
>
> This means a number of db upgrades are not in the wheezy version that
> are assumed to exist by the patch. We can't just apply the patch as is
> by itself, because this will upgrade the wp_db_version to 30135, and
> will mean upgrades from Jessie to newer versions will not work as we
> have skipped the required migrations.
>
> It is possible we could upgrade the version to 24449 and use 24448 to
> trigger the migration, however not really comfortable doing this in case
> that number is already used upstream somewhere.
>
> Any comments?
> --
> Brian May <[email protected]>
>

Reply via email to