Hi,
thanks for the recent security fixes regarding potential CSRF attacks! I checked our mischief logs for relevant messages today and the only one I found was this:
Nov 24 19:33:24 2021 (117276) Form for user xxx@smail.uni-koeln.de submitted with CSRF token issued for xxx@smail.Uni-Koeln.de.
The only difference is in the case of the email address. I’m no expert on CSRF attacks, but to me it seems as though the comparison should perhaps disregard differences in case only?
Thanks, Sebastian
.:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:.
.:.Regionales Rechenzentrum (RRZK).:..:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.
Hello
Am 13.12.21 um 12:09 schrieb Sebastian Hagedorn:
Hi,
thanks for the recent security fixes regarding potential CSRF attacks! I checked our mischief logs for relevant messages today and the only one I found was this:
Nov 24 19:33:24 2021 (117276) Form for user xxx@smail.uni-koeln.de submitted with CSRF token issued for xxx@smail.Uni-Koeln.de.
The only difference is in the case of the email address. I’m no expert on CSRF attacks, but to me it seems as though the comparison should perhaps disregard differences in case only?
As local part of an email address can be case sensitive, this should only be case insensitive for the domain part.
Kind regards, Christian Mack
-- Christian Mack Mailinglisten-Administration Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung & Lehre 78457 Konstanz, Deutschland ++49 7531 88 4416
Mailman-admin writes:
Am 13.12.21 um 12:09 schrieb Sebastian Hagedorn:
Nov 24 19:33:24 2021 (117276) Form for user xxx@smail.uni-koeln.de submitted with CSRF token issued for xxx@smail.Uni-Koeln.de.
The only difference is in the case of the email address. I’m no expert on CSRF attacks, but to me it seems as though the comparison should perhaps disregard differences in case only?
As local part of an email address can be case sensitive,
This is true, but
this should only be case insensitive for the domain part.
this part depends on exactly how these addresses are generated. In fact, the definition of "equivalent" for the local part is entirely up to the site. If the site policy is to make local parts case insensitive, then the addresses are equivalent in that sense.
On the other hand, whether they should be equivalent for CSRF validation is another question. Since the CSRF validation is supposed to be entirely transparent to the user, I would (naively) expect that the strings representing the same address in the request should be identical. We'd need to figure out why the case of the address is changing, and whether that could be an attack.
Also, some providers equivalent many more local parts. For example, there is the "+" notation separating the real mailbox from an extension token, and IIRC, Google ignores punctuation in local parts.
So this is potentially very complicated.
Steve
On 12/13/21 10:02 AM, Stephen J. Turnbull wrote:
On the other hand, whether they should be equivalent for CSRF validation is another question. Since the CSRF validation is supposed to be entirely transparent to the user, I would (naively) expect that the strings representing the same address in the request should be identical. We'd need to figure out why the case of the address is changing, and whether that could be an attack.
I have reported this issue at https://bugs.launchpad.net/mailman/+bug/1954694, and I am fixing it. In this case, we are only trying to determine that the user posting the options form is the same user for whom the CSRF token was issued. While Mailman does keep track of case-preserved email addresses for mail delivery, a user is identified by lowercase email so comparing lowercase email is fine.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2021-12-13 at 13:02:22 UTC-0500 (Tue, 14 Dec 2021 03:02:22 +0900) Stephen J. Turnbull stephenjturnbull@gmail.com is rumored to have said:
Mailman-admin writes:
Am 13.12.21 um 12:09 schrieb Sebastian Hagedorn:
Nov 24 19:33:24 2021 (117276) Form for user xxx@smail.uni-koeln.de submitted with CSRF token issued for xxx@smail.Uni-Koeln.de.
The only difference is in the case of the email address. I’m no expert on CSRF attacks, but to me it seems as though the comparison should perhaps disregard differences in case only?
As local part of an email address can be case sensitive,
This is true, but
this should only be case insensitive for the domain part. [...] So this is potentially very complicated.
Case-squashing domain parts? Not complicated. Simple. The hardest part is handling IDN, which is not in fact all that hard.
The only utility in mixed-case domain names is for human readability and the non-standard trick that uses case preservation as a means of detecting DNS hijacking. The bottom line on that trick is that only DNS servers should care about preserving domain name case.
Also simple: NEVER try to interpret or canonicalize local-parts that exist in someone else's domain. You cannot programmatically determine whether 2 different local-parts are equivalent unless you run the delivery system for them.
-- Bill Cole bill@scconsult.com or billcole@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
On 12/13/21 10:36 AM, Bill Cole wrote:
Also simple: NEVER try to interpret or canonicalize local-parts that exist in someone else's domain. You cannot programmatically determine whether 2 different local-parts are equivalent unless you run the delivery system for them.
This is correct and Mailman does maintain case-preserved email addresses for delivery, but internally, Mailman 2.1 list members are lower-cased email addresses (It is not possible to have two list members whose addresses differ only in case), so comparing lower-cased email when trying to determine if two list member addresses are the same member is OK.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 13 Dec 2021, at 19:44, Mark Sapiro wrote:
On 12/13/21 10:36 AM, Bill Cole wrote:
Also simple: NEVER try to interpret or canonicalize local-parts that exist in someone else's domain. You cannot programmatically determine whether 2 different local-parts are equivalent unless you run the delivery system for them.
This is correct and Mailman does maintain case-preserved email addresses for delivery, but internally, Mailman 2.1 list members are lower-cased email addresses (It is not possible to have two list members whose addresses differ only in case), so comparing lower-cased email when trying to determine if two list member addresses are the same member is OK.
Thanks for the quick fix!
.:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:.
.:.Regionales Rechenzentrum (RRZK).:..:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.
Bill Cole writes:
So this is potentially very complicated.
Case-squashing domain parts? Not complicated. Simple.
This is true if you are talking about following the Internet's rules. I wasn't; I was talking about equivalencing identity tokens that happen to look like email addresses.
There is, of course, some constraint on Mailman's behavior in that it actually uses those tokens as email addresses to confirm identity by sending email to them.
Also simple: NEVER try to interpret or canonicalize local-parts that exist in someone else's domain.
As Mark points out, that horse left the barn decades ago.
In this case apparently that is "user-friendly" (it seems that only the domain differs in case), but if some site is in fact case insensitive for local parts, the CSRF check will throw a false positive in a situation similar to the OP, but where local parts differ in some way insignificant for that domain.
You cannot programmatically determine whether 2 different local-parts are equivalent unless you run the delivery system for them.
Yup. Which means making Mailman behave "nicely" from the user's point of view is complicated in the situation in the OP.
participants (5)
-
Bill Cole -
Mailman-admin -
Mark Sapiro -
Sebastian Hagedorn -
Stephen J. Turnbull