Mezzanine 1.4.6 security release

[Stephen McDonald]

Hi all,

I've just pushed Mezzanine 1.4.6 to pypi. This release contains a security fix for a XSS vulnerability in Mezzanine's built-in comments. The XSS issue applies to Mezzanine 1.3 through to 1.4.5, so if you're using an earlier version of Mezzanine, or have Disqus comments configured and are not using the built-in comments, your project won't be affected. If you're using the built-in comments with Mezzanine 1.3 or greater, you should either upgrade immediately or apply the instructions given below, which will allow you to correct the issue without having to upgrade.

Details of the issue:

In Mezzanine 1.3 (released Dec 26, 2012) we added the COMMENT_FILTER setting, which allows you to define a function that comment text will pass through before being rendered, in order to support different comment formats. This function gets used in the comment_filter template tag, which is always called in the comments template. When the COMMENT_FILTER setting isn't defined, which would be the common case, the comment_filter template tag will fall back to running the comment text through Django's urlize and linebreaksbr filters. The problem is that when this is done in Python code inside the comment_filter template tag, eg `linebreaksbr(urlize(text))`, the same escaping behaviour isn't achieved as when using these filters in a template, eg `{{ text|urlize|linebreaksbr }}`, and the comment text ends up not being escaped. The fix for this in Python code looks like: `linebreaksbr(urlize(comment_text, autoescape=True), autoescape=True)`, where we need to use the arg `autoescape=True` explicitly.

Fixing the issue:

This is fixed in 1.4.6, so if you're able to upgrade that's the best approach. Fortunately you can also fix this issue without upgrading, by putting the following code directly into your project's settings.py module:

def my_comment_filter(comment_text):

    from django.template.defaultfilters import linebreaksbr, urlize

    return linebreaksbr(urlize(comment_text, autoescape=True), autoescape=True)

COMMENT_FILTER = my_comment_filter

Thanks to Gur for reporting this issue. Just a reminder that if you come across a potential security problem, or think you might have but aren't entirely sure, please email secu...@jupo.org which is a private address. Reporting security issues privately allows for the issue to be correctly identified and resolved before being made public. It also allows anyone with a production site in place to apply any upgrades/fixes required, before the issue is made public. If you have a production site running Mezzanine, please subscribe to the private security mailing list, so that you can receive notice of these issues in advance: https://groups.google.com/group/mezzanine-security

The 1.4.6 release also contains a handful of minor fixes and changes:

- Fix for projects that don't define the AUTHENTICATION_BACKENDS setting

- More meaningful exception messages when dynamic imports fail

- Fix in fabfile for deploying new projects without a static directory

- Handful of fixes in older migrations, allowing all migrations to be run from the start with new projects

- Fix for Django's redirects app when used with multiple sites in a single project

- Fix missing CSRF tokens for new sessions in cached pages

- New setting ACCOUNTS_APPROVAL_REQUIRED which allows for public accounts to require manual approval for activation

- Fix in thumbnail template tag for palette mode images

- blog_recent_posts template tag now includes post authors loaded from db

- Fix for default values defined for checkbox fields in forms builder

- Better admin export filtering options for multiple choice fields in forms builder

- Fix for STATIC_URL values using absolute paths without protocol defined (eg ://foo.com)

- Fix for zip imports in galleries app for zipfiles containing files with paths

- Added default wsgi.py script to project template

- Blog post date urlpatterns can now be configured with the new BLOG_URLS_DATE_FORMAT settings (replaces BLOG_URLS_USE_DATE setting)

- Front-end live editing can be disabled with the new INLINE_EDITING_ENABLED setting

- Fixes for overriding titles and descriptions when subclassing blog RSS feed classes

Lastly, the behaviour for admin editable settings has changed slightly which is worth describing in a bit of detail. Previously there had been much confusion with admin editable settings which had also been given an explicit value in a project's settings.py module. The value given in setting.py would only serve as a default value, with the admin editable setting taking precedence over it when given a value, which would occur the first time the settings form was saved in the admin, even if the setting's value had not been changed. To avoid this confusion, defining a value for an admin editable setting in your project's settings.py module will now mark the setting as no longer editable, so it won't appear in the admin settings form and the value defined in settings.py will always be used. Before upgrading to 1.4.6, it's worth verifying any admin editable settings in your project's settings.py module.

Apologies for wrapping up all these changes along with an important security fix. Fortunately these issues are few and far between in Mezzanine (this is the second in over three years), which unfortunately means we don't yet have a good process in place for releasing isolated security fixes. The awkward decision to bundle everything in a single release for now, was made only due to the ease at which this particular issue can be resolved by adding the few lines mentioned above to your project's settings.py module. 

Cheers,

Steve

--
Stephen McDonald
http://jupo.org

[Sachin Shende]

Hi Steve,

Many many thanks for all the hard work and for the release. 

Best wishes,

Sachin

[Jesus Anaya]

Is necessary use "python manage.py migrate" for update from 1.4.3 to 1.4.6 ? ... because i used "python manage.py createdb --noinput", but this only mark all migration as fake, true?

[Ken Bolton]

Hi Jesus,

I have not been following development on master closely, so I do not know what migrations may have been added. If you dive into the database, the south_migrationhistory table will show you the last migrations you ran. I believe you can safely delete the last batch of migrations in your database, which should have been created when you ran your createdb. Just to be safe, make a backup first! After that, you can run `python manage.py migrate --all`.

ken

--
You received this message because you are subscribed to the Google Groups "Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jesus Anaya Orozco]

Thank you !!! 

You received this message because you are subscribed to a topic in the Google Groups "Mezzanine Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mezzanine-users/LVfTStpAOTg/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to mezzanine-use...@googlegroups.com.