Hacker News new | ask | show | jobs
by alexpls 875 days ago
For folks who wanna see what led to this exploit in a Rails codebase, here’s the commit where it’s fixed:

https://gitlab.com/gitlab-org/gitlab/-/commit/c571840ba2f0e9...

3 comments

This doesn't look like the actual fix but rather a follow-up refactor. I believe the fix is here: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...

    - recoverable.send_reset_password_instructions(to: email) if recoverable&.persisted?
    + recoverable.send_reset_password_instructions if recoverable&.persisted?
on GitHub, the fix would be adding a regex to ensure there was no list on the user supplied email.
and making send_reset_password_instructions get the email addresses itself from the "recoverable" object.
Oh yeah, good pickup thanks!

    # Concern that overrides the Devise methods
    # to send reset password instructions to any verified user email
    module RecoverableByAnyEmail
So it was a feature??

Anyway, in the fixed version it's still called RecoverableByAnyEmail. Do people not read the code around what they are changing??

It does say any email doesn't it? Not verified, any.
> "RecoverableByAnyEmail"

Added 8 months ago [1]. And then one month later:

> "password_reset_any_verified_email"

Was removed. 7 months ago [2], *note* __verified__ word here.

No blaming or conspiracy intended in this post, just listing links to relevant commits.

1 - https://gitlab.com/gitlab-org/gitlab/-/commit/94069d38c9cd63...

2 - https://gitlab.com/gitlab-org/gitlab/-/commit/a935d28f3decf8...

haha the first thing i would've caught in the initial PR was the file name... and the default setting of `confirmed: true`... seems like a big oversight or possibly an inside job (if im being conspiratorial)
as a non-rubiest, can you point to the error?
Ruby. I kid, but also I don't.

Initially a single email could be passed into the API/form call and they would look it up. If found they would send a recovery to that email but it was the email the user supplied not what was in the DB.

Oh, no problem we looked it up so they are the same!

But then the ability to look up accounts from a list of emails was added. If any email matches the account lookup would succeed. Then they sent the reset link to that same user supplied value but OH NOEHS IT'S AN ARRAY NOW AND SOME MIGHT NOT HAVE MATCHED ACCOUNT EMAILS!

So they ended up sending out reset links to a tainted list of emails.

Rails "concerns" are the worst IMHO anyway, but looks like they aren't using strong params here either which is even worse. Also someone thought it was more elegant to reuse the tainted value which is par for the RoR course.

This is actually a follow-up refactor, the fix is here: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...
Omg is this fix had to be this bloated?