Ryan Kelly
2016-05-11 00:04:37 UTC
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-***@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:
"***@mozilla.com\x00\***@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:
"***@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
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-***@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:
"***@mozilla.com\x00\***@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:
"***@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