Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

eng.getwisdom.io

Post reply on HN
Print view View original

151–160 of 231 posts

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#151

Post by keyP »

Keverw wrote: post #99

Reminds me of a issue Spotify had too with unicodes and usernames. https://labs.spotify.com/2013/06/18/creative-usernames/ I had someone tell me that programming isn't real work before, and this is yet another example of all the small little details going into building things that most people don't really think about day to day. I haven't had to work with login code in a while, but might at some point. I know some sy…

> I had someone tell me that programming isn't real work before

Haha, I don't even understand what metrics the person was using to consider something "work". A pilot sits throughout the flight but I think it's fair to say their working...

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#152

Post by 2038AD »

founderling wrote: post #138
BoppreH wrote: post #36

I 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…

opaque byte arrays, only available operation is rendering into a bounded area Goodbye web then. Because the whole request you get from a client is nothing but strings. So when you run an onlineshop and a customer orders "7" screwdrivers - then you are screwed. Because what does an "opaque byte array" of "opaque byte arrays" cost? How much shipping will that be? But at least you have a brand new customer: Henry@gmail.…

>But at least you have a brand new customer: Henry@gmail.com. Since you do not lowercase the email and do not recognise him as henry@gmail.com which he used in his last order

You may not like it but this is fully standards-compliant behaviour. RFC 5321 states:

>The local-part of a mailbox MUST BE treated as case sensitive

I'm not saying this is a good behaviour and the RFC also discourages exploiting it further.

There are more ways an email address can be equivalent though :-). Since we know it's gmail in this case we know the email address is both case insensitive and dots don't matter. Comments are also allowed in email addresses (in both the local part and the domain part). Here's a couple examples from RFC 2822:

  pete(his account)@silly.test(his host)
  c@(Chris's host.)public.example
[0] https://tools.ietf.org/html/rfc5321

[1] https://support.google.com/mail/answer/7436150

[2] https://www.ietf.org/rfc/rfc2822.html#appendix-A.5

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#153

Post by gingerlime »

thaumasiotes wrote: post #149
BoppreH wrote: post #36

I 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…

I want to note a separate issue of defensive coding that comes up in the writeup: > GitHub's forgot password feature could be compromised because the system lowercased the provided email address and compared it to the email address stored in the user database. If there was a match, GitHub would send the reset password link to the email address provided by the attacker The logical flow is: 1. Get the email address fro…

Yes, you're absolutely right. The real bug was sending to the "wrong" matching email. But this is what makes this bug so hard to find. You're looking at "equal" strings, so why should it make a difference if you pick A or A if A === A ? :)

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#154

Post by tialaramex »

RyanCavanaugh wrote: post #67
_jal wrote: post #61

Earlier quoted context omitted.

Sure, and meanwhile if there are collisions without periods on that domain (randy@somewhere, r.andy@somewhere and rand.y@somewhere, for instance), only one of them gets an account. In the absence of being able to count on specs, I guess the user should expect a race?

The fact that we just now found out that this is the case, yet would be completely unable to find anyone complaining about it except in hypothetical terms, tells you exactly how important it is.

This stuff just causes your business to mysteriously have low customer satisfaction. You're doing 95% as well as the successful business but for 5% of your customers these "unimportant" problems make it awful to deal with you and they stay away and tell others.

Most of them can't specifically point to the problem, their impression is just that your services don't work properly. They're right.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#155

Post by giancarlostoro »

BoppreH wrote: post #36

I 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…

I usually store files inside UUID sub directories with UUID names. Then keep the original name saved elsewhere in a db to avoid filename collision.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#156

Post by Accacin »

qwerty456127 wrote: post #147
iraldir wrote: post #135

Earlier quoted context omitted.

Counterpoint: A lot of people in China are as familiar with the latin alphabet as you are with the Cyrillic alphabet: Source: https://newrepublic.com/article/117608/chinese-number-websit...

I've once seen a Chinese girl texting on a bus stop. She used the ordinary US-looking on-screen keyboard but Chinese hieroglyphs were appearing in the message window as she typed.

Yeah my wife uses this input method too, as I do if writing Mandarin. It's basically typing the pinyin for the characters. However, nearly everyone else in her family uses the type of input where you type 'strokes' of the characters to filter down the character you want to input.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#157

Post by thaumasiotes »

gingerlime wrote: post #153
thaumasiotes wrote: post #149

Earlier quoted context omitted.

I want to note a separate issue of defensive coding that comes up in the writeup: > GitHub's forgot password feature could be compromised because the system lowercased the provided email address and compared it to the email address stored in the user database. If there was a match, GitHub would send the reset password link to the email address provided by the attacker The logical flow is: 1. Get the email address fro…

Yes, you're absolutely right. The real bug was sending to the "wrong" matching email. But this is what makes this bug so hard to find. You're looking at "equal" strings, so why should it make a difference if you pick A or A if A === A ? :)

Hard to find, but it's the kind of thing that will hopefully come up in code review. Consider this pseudocode with helpful pseudo-hungarian notation:

    username = request.post_params('username')
    evil_email = request.post_params('email_address')
    user = get_user_by_name(username)
    
    good_email = user.email_address
    if good_email != evil_email:
        # Hackers!
    else:
        reset_password(user.id, evil_email) # it's fine; it's the same as user.email_address
You can see the problem in the call to reset_password. Sure, it's the same as user.email_address, but if you just used user.email_address you'd be doing the right thing and you wouldn't need the comment about "don't worry; it's fine".

Then you start to wonder if that line shouldn't look more like

    reset_password(user)
and from a security perspective, it should. (I assume the reason Github allows the code to specify the email address in the first place is that an account may be associated with multiple addresses.)

If it makes no difference which email address you pick, why not pick the one that represents doing something safe instead of the one that represents doing something dangerous?

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#158

Post by simion314 »

BoppreH wrote: post #36

I 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…

But why non english users should be forced to name their files with english characters, libraries and code that work with files should always use tests with unicode in file names.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#159

Post by MattConfluence »

The linked post is titled "Hacking GitHub with Unicode's dotless 'i'.", but this submission is in title case "Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'". I think this is a bad title change, because an uppercase I is supposed to be dotless, whereas the lowercase i used by the author's title is not.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#160

Post by reportgunner »

I haven't finished reading the article, but isn't the problem here that they are sending the e-mail to the address provided by the user rather than sending it to the e-mail stored in the database ?

I fail to see any added value in sending a reset link to an e-mail entered by the user (while that e-mail is already in the database).

Is it because the e-mails are stored hashed ?

Post reply on HN