security notice: insufficient data validation in persona.org verifier

[Ryan Kelly]

Hi All,


We recently found and fixed a data validation issue with the hosted
BrowserID verifier running on persona.org. It was accepting assertions
for email addresses containing special characters such as newlines or
null bytes. Under very specific conditions, this may have allowed
malicious users to trigger a string-handling bug in the relying website
and claim ownership of an email address they did not control.

More details below, but I want to highlight two key points up front:

- A security issue was only present for sites that did not properly
handle unexpected characters in the email address returned from the
verifier. We have identified one specific instance of this, in
sites using certain configurations of mod_authnz_persona.

- If you’re using the verifier at https://verifier.login.persona.org,
no action is required. We have already deployed a fix to reject
assertions with malformed email addresses.


The persona.org service will be decommissioned later this year, but
until that process is complete we will continue to respond quickly if
security issues are identified, and to communicate transparently about
what happened and how it might affect you.

If you have any questions or concerns about how this issue may have
affected you, please send them to the public list:

dev-id...@lists.mozilla.org

Or to me directly if not suitable for public discussion.

More details below.


Thanks,

Ryan




What was the problem?
=====================

The BrowserID verifier at https://verifier.login.persona.org was
performing only limited validation on the data contained in identity
assertions. A malicious user could construct a properly-signed and
valid assertion for an email address containing null bytes, newlines, or
other special characters:

When a website using persona submitted such an assertion to the
verifier, it would receive back a successful verification response and
an email address string containing these special characters. If the
site then failed to properly handle the special characters, it might
misinterpret the email address and allow impersonation of other users.

We discovered an instance of this problem in the mod_authnz_persona
Apache module [1] that is used at Mozilla to restrict access to several
internal sites. This module is written in C, and hence was handling the
email address as a null-terminated string. If presented with an
assertion for an email address containing a null byte, such as:

"rfk...@mozilla.com\x00\n...@mockmyid.com"

Then mod_authnz_persona would truncate the string at that byte and
misinterpret it as the email address of an authorized user, such as:

"rfk...@mozilla.com"

More details are available in the associated bugzilla ticket [2].

It is possible that problems with handling special characters could have
caused similar behavior for other websites that rely on persona, but we
are not aware of other instances of this vulnerability in practice.


How and when was it fixed?
==========================

We added additional email address validation to the verifier code. It
now applies the same validation rules that are used in the front-end
account management component of persona.org, and will reject assertions
that contain any invalid characters in the email address. This prevents
relying websites from receiving malformed email addresses containing
characters that might trigger string-handling bugs.

The problem was initially discovered in March by a Mozilla employee, and
the fix described above was deployed to production within 3 hours of
discovery. Since then we have been auditing our internal systems to
check for similar vulnerabilities before disclosing the issue publicly.
No similar vulnerabilities have been found.


What do I need to do?
=====================

If you are using the verifier at https://verifier.login.persona.org as
recommended by our integration docs, nothing. We have deployed
additional validation rules that will prevent your application from
receiving malformed email address.

If you are verifying assertions locally, or using any other means of
verifying assertions, you should check whether malformed email addresses
are being accepted, and fix the code to explicitly reject them.


What sites have been affected?
==============================

This issue only affected sites that do not properly handle special
characters in the email address returned by the verifier, for example by
treating null bytes as a string terminator, or by storing the address in
a database that truncates unexpected characters.

We have confirmed one specific instance of this problem in practice: if
you were using mod_authnz_persona with either the "Require valid-user"
or "Require user" directive, then you were exposed to a user
impersonation vulnerability. The “Require persona-idp” directive does
not appear to have been vulnerable.

We have no evidence of this issue being actively exploited, but cannot
rule it out. For privacy reasons we do not log the email addresses
passing through the hosted verifier, and so cannot perform a historical
audit.

If you feel that your website may have been susceptible to this issue
due to problems handling special characters, you should audit your
system to check for suspicious email addresses. Given the nature of the
problem, any attempts to exploit this issue are likely to have contained
multiple “@” symbols in the email address. The presence of such emails
in your database or logs may indicate an attempt to exploit this issue.

If you do find such emails, please reach out to us via private email for
further assessment and advice.


[1] https://github.com/mozilla/mod_authnz_persona
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1253795

[Michael Kelly]

Is PyBrowserID[1] affected? I'm guessing not since you didn't mention it and you maintain it, but I just wanted to be sure. :P

- Mike Kelly

[1] https://github.com/mozilla/PyBrowserID

> _______________________________________________
> Persona-notices mailing list
> Persona...@mozilla.org
> https://mail.mozilla.org/listinfo/persona-notices
>

[Ryan Kelly]

On 11/05/2016 16:08, Michael Kelly wrote:
> Is PyBrowserID[1] affected? I'm guessing not since you didn't mention it and you maintain it, but I just wanted to be sure. :P

Thanks Michael, good point. In its default configuration it uses the
remote verifier and so should be fixed by the deployment there with no
code changes.

For completeness I've changes its local verification code to perform the
same email validation checks, and released version 0.11.0:

https://pypi.python.org/pypi/PyBrowserID/0.11.0


Cheers,

Ryan

[Michael Kelly]

Cool, thanks for the fix. I meant to specifically ask about the local
verification, since django-browserid uses PyBrowserID for to power it's
local verification. I'm fairly sure django-browserid can handle emails
with null bytes or newlines or whatever, but are you sure that
PyBrowserID was handling them well beforehand?

If not, then everyone doing local verification with django-browserid
will need to upgrade PyBrowserID.

- Mike Kelly

[Ryan Kelly]

(I'm dropping persona-notices from the discussion as it's not really
designed for a back-and-forth like this)

On 12/05/2016 05:49, Michael Kelly wrote:
> Cool, thanks for the fix. I meant to specifically ask about the local
> verification, since django-browserid uses PyBrowserID for to power it's
> local verification. I'm fairly sure django-browserid can handle emails
> with null bytes or newlines or whatever, but are you sure that
> PyBrowserID was handling them well beforehand?
>
> If not, then everyone doing local verification with django-browserid
> will need to upgrade PyBrowserID.

It's likely that previous versions of PyBrowserID had the same problem,
i.e. would accept assertions for emails with null bytes, newlines etc
and happily pass them back to the calling application.

In isolation this wouldn't have caused any bugs thanks to python's solid
string handling.

But if you were, say, writing the email addresses into MySQL and didn't
have strict mode enabled, you may have been vulnerable to truncating
behaviour in the same way that mod_authnz_persona was.

I'd recommend anyone using the local verifier in PyBrowserID upgrade to
the latest version, simply from an abundance of caution.


Cheers,

Ryan

[David Berlin]

Yes, the issue has been fixed. Thank you...