So an attacker just issues a 1000 concurrent withdraws. Step 4 hasn't happened yet so they can withdraw more than their balance.
Solution: Step 4 should go before step 3. Update the balance before executing withdrawals. Handle payment failures later, worse case they don't drain your wallet
Yeah, since payment failures are common in lightning you can just put a temporary hold on the balance and then properly handle the balances after the payment completes. Can also just not allow concurrent withdrawals but that can provide a bad experience
Actually there were locks in place for these, but the bug was much less trivial: it was timing between the time it took to save the new tx to the dB and the balance compute from dB. There were (keyed per wallet) locks all over the place
I agree with all said, but want to add a little point about UX or bad experience... when you handle money... UX is the "last" of your priority, the back fire when you lose other people money is SO bad for your application that throw all the UX to the garbage.
Focus on "don't" lose money first, and then add all the shitty lights, remember... we are competing with banks... worst UX in the world.
This was more of a #reckless than a "No keys no cheese" situation.
Affected users had their keys. The issue was that they delegated those keys to an algorithm that automates signing. A bug in the algorithm allowed attackers to "trick" the software into signing wallet draining transactions.
Only delegate signing to audited or time tested code. Or mitigate loss by only delegating keys with minimal funds.
Race conditions like these are hard, not an easy thing to solve in lightning apps.
Mmm so is my understanding correct:
So an attacker just issues a 1000 concurrent withdraws. Step 4 hasn't happened yet so they can withdraw more than their balance.
Solution: Step 4 should go before step 3. Update the balance before executing withdrawals. Handle payment failures later, worse case they don't drain your wallet
Yeah, since payment failures are common in lightning you can just put a temporary hold on the balance and then properly handle the balances after the payment completes. Can also just not allow concurrent withdrawals but that can provide a bad experience
Actually there were locks in place for these, but the bug was much less trivial: it was timing between the time it took to save the new tx to the dB and the balance compute from dB. There were (keyed per wallet) locks all over the place
I agree with all said, but want to add a little point about UX or bad experience... when you handle money... UX is the "last" of your priority, the back fire when you lose other people money is SO bad for your application that throw all the UX to the garbage.
Focus on "don't" lose money first, and then add all the shitty lights, remember... we are competing with banks... worst UX in the world.
NYK, NYC
This was more of a #reckless than a "No keys no cheese" situation.
Affected users had their keys. The issue was that they delegated those keys to an algorithm that automates signing. A bug in the algorithm allowed attackers to "trick" the software into signing wallet draining transactions.
Only delegate signing to audited or time tested code. Or mitigate loss by only delegating keys with minimal funds.
Who wrote that?
The dev