Author: any word on how much GitHub paid out for discovering this vulnerability? Also, how simple was it to create a unicode-based email address on one of the large providers?
Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'
31–40 of 231 posts
Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'
#32The examples in the initial "quick example" are backwards, no?
It's `'ß'.toUpperCase()` that is `"SS"`, not `'ß'.toLowerCase() === 'ss'`. As the later chart makes clear. Same with turkish ı.
Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'
#33Earlier quoted context omitted.
> stripped of dots and other inert punctuation The period thing is a Gmail feature, not a standard. some.email@mydomain and someemail@mydomain most certainly do not deliver to the same mailbox.
> some.email@mydomain and someemail@mydomain most certainly do not deliver to the same mailbox. That's why we keep your verified mailbox address for sending mail; but there's no good reason to consider them different for the purpose of identity.
...and only one in 50,000 e-mail addresses contain the string "rq5", therefore we strip that string from addresses...
A false postive in these identity checks is likely to be less destructive than a false negative. But I still don't get the point of making up all sorts of rules not in the standard. I have seen both + as well as meaningful dots in e-mail adresses in the wild.
Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'
#34Earlier quoted context omitted.
Senders don't get to dictate how a recipient encodes their addresses. RFC 822: The local-part of an addr-spec in a mailbox specification (i.e., the host's name for the mailbox) is understood to be whatever the receiving mail protocol server allows.
I am well aware of that, but I'm comfortable requiring that new customers don't register an account with an email address foolishly designed to resemble another customer's email address in this particular way. We don't throw away their specified mailbox address, we just don't accept registrations which look suspiciously similar, or intended to cause confusion. I repeat, this has absolutely nothing to do with the mail…
You can't decide for yourself what the semantics of someone else's address do or do not mean.
Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'
#35Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Email_address#Internationaliza... Turkish emails are not supported in the first place. Internationalization examples[edit] The example addresses below would not be handled by RFC 5322 based servers, but are permitted by RFC 6530. Servers compliant with this will be able to handle these: Latin alphabet with diacritics: Pelé@example.com Greek alphabet: δοκιμή@παράδειγμα.δοκιμή Traditional…
RFC 6530 doesn't mention those character sets explicitly. It proposes allowing all Unicode characters, apart from some control characters. It is true that the RFC recommends mailbox providers take normalization into account. A mailbox provider that allows i and dotless-i addresses to be routed to different mailboxes is careless, if not actually uncompliant. I don't know if any popular provider does this: I'm guessing…
Turkish characters are not part of RFC 6530.
There are no email addresses with Turkish characters at all. They all use Latin characters.
It just does not exist - yet at least.
Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'
#36I love Unicode, but I'm more and more coming to the conclusion that strings are evil and should be treated as opaque byte arrays, whose only available operation is rendering into a bounded area. I now see any other string operation as code smell.
It's scary how much of our infrastructure relies on strings, given how few guarantees string operations actually give. Take files names, for example. Two visually identical file names may map to different files (because confusables[1]), or two different names map to the same file (because normalization[2]), or the ".jpg" at the end may not actually be the extension (because right-to-left override[3]), not to mention names with newlines or backspaces in them, and inconsistencies between operating systems.
I would go as far as blaming our overreliance on strings for all the injection attacks we see (XSS, SQL, command, etc).
[1] https://unicode.org/cldr/utility/confusables.jsp
[2] https://developer.apple.com/library/archive/qa/qa1173/_index...
[3] https://krebsonsecurity.com/2011/09/right-to-left-override-a...
Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'
#37Earlier quoted context omitted.
> stripped of dots and other inert punctuation The period thing is a Gmail feature, not a standard. some.email@mydomain and someemail@mydomain most certainly do not deliver to the same mailbox.
> some.email@mydomain and someemail@mydomain most certainly do not deliver to the same mailbox. That's why we keep your verified mailbox address for sending mail; but there's no good reason to consider them different for the purpose of identity.
> That's why we keep your verified mailbox address for sending mail; but there's no good reason to consider them different for the purpose of identity.
Both of Microsoft's own identity services (AAD and Live ID, and by extension O365 and Outlook.com) recognize (and allow creation of) microcolonel@example.com, micro.colonel@example.com, and mic.rocolonel@example.com as distinct identities/email addresses.
What you're saying is that once the first of (microcolonel|micro.colonel|mic.rocolonel)@example.com registers at github, the other two will no longer be able to do so, but will instead receive a confusing 'you already have an account' error, (hopefully) without being able to receive password reset emails.
Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'
#38What is so fascinating about security is that the same problems keep popping up again once in a while - I remember the Turkish i issues being a big problem in early mid 2000s during all the security pushes that went through software engineering world. Then we kinda forgot about them, and now it keeps coming up again.
The best a researcher can do is go back 20+ years and look for security issue that occurred back then. Most likely you'll find very similar things now again.
Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'
#39Unicode actually has an uppercase ß though I don't understand why.
Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'
#40Earlier quoted context omitted.
I am well aware of that, but I'm comfortable requiring that new customers don't register an account with an email address foolishly designed to resemble another customer's email address in this particular way. We don't throw away their specified mailbox address, we just don't accept registrations which look suspiciously similar, or intended to cause confusion. I repeat, this has absolutely nothing to do with the mail…
You can't decide for yourself what the semantics of someone else's address do or do not mean.
Yes they can! It's their prerogative to allow people to sign up or not with any email address, full stop.
It might make them bad netizens and you may not like it. But the spec doesn't compel any behavior. It's just a way to communicate technical ideas and ideals.