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

Race conditions on Facebook, DigitalOcean and others (fixed)

josipfranjkovic.blogspot.com

Post reply on HN
Print view View original

31–40 of 90 posts

Re: Race conditions on Facebook, DigitalOcean and others (fixed)

#31

Post by ejcx »

jdubs wrote: post #28
monksy wrote: post #12

Earlier quoted context omitted.

BTW: I just subscribed to LastPass a few days ago. I'm pretty happy with the service.

LastPass is awesome but I hate their website login process! It bothers me to no extreme that if I type in my email address with a wrong username, it pops back with, "Invalid password" while typing in a obviously random email, it pops back with a "Unknown email address. Would you like to create an account now?." I worry that a malicious attacker could finger the service for potential victims.

Username enumeration is a valid concern. Requests on the login form (and some other places) are throtted. If you get too many emails wrong you will start only getting errors.

Re: Race conditions on Facebook, DigitalOcean and others (fixed)

#32

Post by innocenat »

jdubs wrote: post #28
monksy wrote: post #12

Earlier quoted context omitted.

BTW: I just subscribed to LastPass a few days ago. I'm pretty happy with the service.

LastPass is awesome but I hate their website login process! It bothers me to no extreme that if I type in my email address with a wrong username, it pops back with, "Invalid password" while typing in a obviously random email, it pops back with a "Unknown email address. Would you like to create an account now?." I worry that a malicious attacker could finger the service for potential victims.

It is already normally possible to test whether email address is registered by trying to register with that email address. Unless that process is secured too, it doesn't really make much sense to not pop up Unknown email address error.

Re: Race conditions on Facebook, DigitalOcean and others (fixed)

#33

Post by ekimekim »

numair wrote: post #5

I would be really interested to know how various forms of this bug are resolved. This seems like a problem that, on its surface, seems easy to fix, but isn't. Especially if you've designed your architecture for real-time-ness and global redundancy. Google's servers with atomic clocks come to mind...

cynical answer: I've seen alot of races get "fixed" by adding a sleep() or similar

less cynical answer: Commonly you already have some kind of means to handle races - locking, transactions, some other variety of extra check - and the fix for newly discovered races is "oh, I didn't realise that could happen. add lock"

Re: Race conditions on Facebook, DigitalOcean and others (fixed)

#34

Post by pilif »

andersonmvd wrote: post #4

More interesting than the bounty itself is to understand which defense works best at scale and the nitty gritty details of those kind of attacks. Intuitively I think that we just need to avoid inconsistencies between the Time of Check (TOC) and Time of Use (TOU), so veryfing the existence of a discount coupon while inserting it in one query should do the trick (INSERT INTO coupons (...) Values (...) WHERE NOT EXISTS…

In many databases, your suggested "where not exists" sub query might not actually protect you but just make the possible window to hit the race much smaller. What happens is that your database would evaluate the subquery, the rest of the where, commit another transaction and then finally run the insert part of your query.

There are no guarantees in the SQL standard that queries with subqueries should be atomic.

The only truly safe way to protect yourself is to fix the schema in a way that you can make use of unique indexes. Those are guaranteed to be unique no matter what.

Re: Race conditions on Facebook, DigitalOcean and others (fixed)

#35

Post by Gigablah »

yesmade wrote: post #26
Gigablah wrote: post #19

Earlier quoted context omitted.

Instead of questioning why others are getting so much, question why you're getting so little.

chill out man. you are turning this into something personal. it was only a comment at the amount he got for cheating the review system. even the OP said he wasn't expecting that much. stop jumping into the hate wagon everybody

I wasn't judging you, haha. I'm just saying, it makes more strategic sense in general to bring yourself up to the level of others (however inflated) rather than bring others down to yours.

Re: Race conditions on Facebook, DigitalOcean and others (fixed)

#36

Post by d_luaz »

reagan83 wrote: post #29
d_luaz wrote: post #20

No bounty for bug report? Should at least have a nominal fee of $100 (else no one would bother to report it).

The economics of bug bounty programs could lead to misaligned incentives. Because the overhead cost to validate and communicate around bug reports isn't zero, the % of non-bugs submitted could become imbalanced because it is free to submit. In most systems the reward is zero, so you can infer if a person has taken the time to submit a bug report it is because he/she is invested in seeing it fixed. Context: I work at…

So the best solution is not to have a reward? Or not to have a publicized reward? Or don't depend on the public on bug hunting? Or just hope on goodwill?

Re: Race conditions on Facebook, DigitalOcean and others (fixed)

#37

Post by pwman »

innocenat wrote: post #32
jdubs wrote: post #28

Earlier quoted context omitted.

LastPass is awesome but I hate their website login process! It bothers me to no extreme that if I type in my email address with a wrong username, it pops back with, "Invalid password" while typing in a obviously random email, it pops back with a "Unknown email address. Would you like to create an account now?." I worry that a malicious attacker could finger the service for potential victims.

It is already normally possible to test whether email address is registered by trying to register with that email address. Unless that process is secured too, it doesn't really make much sense to not pop up Unknown email address error.

Correct -- It's a pet peeve of mine when login processes obscure this saying invalid password when the sign up process doesn't -- if you're going to tell people usernames aren't available then you shouldn't be avoiding it on the login screen.

Re: Race conditions on Facebook, DigitalOcean and others (fixed)

#38

Post by nmjohn »

reagan83 wrote: post #29
d_luaz wrote: post #20

No bounty for bug report? Should at least have a nominal fee of $100 (else no one would bother to report it).

The economics of bug bounty programs could lead to misaligned incentives. Because the overhead cost to validate and communicate around bug reports isn't zero, the % of non-bugs submitted could become imbalanced because it is free to submit. In most systems the reward is zero, so you can infer if a person has taken the time to submit a bug report it is because he/she is invested in seeing it fixed. Context: I work at…

So when I find a bug in say Paypal which allows complete account takeover and could sell it to an organized hacker group for say $100,000 or report it to Paypal "because I'm invested in seeing it fixed" and receive nothing - that is only an easy decision for the whitest of white hat hacker.

Properly designed bug bounty programs are a cornerstone to any company who remotely cares about the security of their product, period.

The idea of misaligned incentives due to poor bug reports being free to submit is ignorant - and worse toxic, because it sounds so true to an executive who has no actual understanding of the issue.

A quality bug report should take no more than 1 minute for a reviewer to look at and know if it's really a bug or not. If it can't, it should be rejected saying provide more clear details. For example a dom based xss attack could be reported with just a target URL and it is quite clear what the problem is. That would take 10 seconds to analyze.

Additionally, most bugs reported to most decent sized companies are reported by someone who has previously reported a bug to the company before. If someone is constantly reporting good bugs or the opposite, its quite easy to prioritize which of those individuals gets their emails read first.

Re: Race conditions on Facebook, DigitalOcean and others (fixed)

#40

Post by hobarrera »

andersonmvd wrote: post #4

More interesting than the bounty itself is to understand which defense works best at scale and the nitty gritty details of those kind of attacks. Intuitively I think that we just need to avoid inconsistencies between the Time of Check (TOC) and Time of Use (TOU), so veryfing the existence of a discount coupon while inserting it in one query should do the trick (INSERT INTO coupons (...) Values (...) WHERE NOT EXISTS…

I'd never heard of "WHERE NOT EXISTS", but my first approach would be to make the pair (user_id, cupon_code) unique together, so that only one insertion can be made and only do any further processing if that transaction does not fail.
Post reply on HN