[HN Gopher] The bug which lost more than $600M in various crypto...
___________________________________________________________________
The bug which lost more than $600M in various cryptocurrencies a
few hours ago
Author : edward
Score : 109 points
Date : 2021-08-12 08:35 UTC (14 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| 55555 wrote:
| There's a serious fundamental problem with DeFi that can't be
| solved with blockchains.
|
| Someone starts a blockchain company and hires a bunch of devs who
| make, idk, $40 to $100 per hour to build the thing. Maybe more,
| it doesn't really matter. Even just one dev or a few devs can
| make all the contracts needed for this.
|
| One day that dev notices a vulnerability in the smart contract
| he's writing! He has two choices: (a) patch the vulnerability,
| which will get him a pat on the back, or (b) convince himself he
| didn't notice anything, quit his job, wait a month, go to a
| coffee shop with a hoodie on, boot into whonix, connect to the
| internet with a 4g dongle, run a few lines of code, and get $600
| million dollars.
|
| Most people would choose (a)! And law enforcement is a thing! But
| a lot of people will choose (b), and if they do a merely decent
| job they will get away with it, and 600 million dollars is
| stolen(r).
|
| Actually, it's worse than that, because unlike normal banks, the
| code used by these digital banks is open source, and anyone in
| the world can go bug hunting.
| fny wrote:
| Now say you're a company hired to do an audit. Same incentives.
|
| The hilarious thing is nearly all of these high profile hacks
| happen even after being audited.
|
| There was one company I remember being called out as a suspect,
| but I can't find the name.
|
| Also given (a) anonymity (b) ability to take cover amid so many
| other hacks, you could do this for a few years, slow down, and
| remain a top tier firm claiming the lowest hack rate.
| bko wrote:
| > Actually, it's worse than that, because unlike normal banks,
| the code used by these digital banks is open source, and anyone
| in the world can go bug hunting.
|
| An argument that open source is less secure, and on Hacker
| News! Now I've seen it all.
| gpderetta wrote:
| It is not a statement about security but about plausible
| deniability.
| TravisHusky wrote:
| There is an argument to be made for having some things remain
| closed, and obscured from public view. If a company/group has
| an experienced and large internal audit team that reviews
| systems, and they are building something that is likely to be
| placed under extreme amounts of targeted attacks (military
| crypto, banking systems, etc.) it sometimes makes sense to
| not allow just anyone to see/poke at the whole thing.
|
| Military cryptographic systems, IBM mainframes, and many
| other products use this approach as a layer in their security
| framework and it is actually pretty successful.
|
| If I asked you to break into the a PFSense box you could just
| Google "PFSense version X.X.X CVEs" and you would probably
| get a way in if the box was enough out of date, but if you
| tried to find the same thing for something like the General
| Dynamics TACLANE you would have a hard time even finding
| where to start.
| legulere wrote:
| Why should law enforcement be a problem? I thought the idea
| behind smart contracts was that code is law?
| robertwt7 wrote:
| but is it that simple though? Even in enterprise company we
| have to do 2-3 review on PR before merging.
|
| I think proper DeFi company should have their own system on
| deploying contracts. Further, they should have their own
| security team that audit everything.
| hjorthjort wrote:
| That's what you hire auditors for.
| kevingadd wrote:
| An auditor has the same incentive to become a bad actor for
| profit
| JulianMorrison wrote:
| I wonder if there's some way to make a "thief monkey". Some
| program that searches your code for vulnerability patterns and
| rips you off if it can. (Obvs, a tame monkey will then give you
| the money back).
|
| Humans might be motivated to sit on a bug until they can reach
| the cybercafe. Bots, not so much.
| crypt1d wrote:
| A lot of these contracts, and especially those owned by first-
| tier cryptocurrency companies, are reviewed by 3rd party
| auditors. Of course that doesn't completely remove the risk,
| but certainly at least ensures that no obvious bugs are missed.
| bawolff wrote:
| Auditors have never fully prevented bugs in any other
| computing domain, i dont know why cryptocurrency would be any
| different.
| uncomputation wrote:
| It's very hard to take this claim seriously in this thread,
| which details a huge (and somewhat obvious) security
| vulnerability in a currency worth at least $600m (an amount
| anyone would assume is "first-tier").
| crypt1d wrote:
| Yeah I can understand that. Once you dive into crypto
| however, you quickly realize that $600m is just not that
| much money (especially not if we are talking about digital
| assets valued at current ticker price). And that lots of
| money isn't necessarily the right measure of quality of the
| project.
| fny wrote:
| Lol, even 1% of $600M is $6M. That's a lot of money.
| You'd have to have garbage liquidity to only get back 1%.
| christkv wrote:
| It's valued at 600 million that does not mean it can be
| liquidated for 600 million.
| smaryjerry wrote:
| That is literally what that means. Market caps are what
| they are because everyone who thinks it is worth less has
| sold and everyone who thinks it's worth that or more will
| buy. There's some outliers but in general these coins are
| trading their entire market cap over the course of maybe
| a month or less. Liquid generally means short term, if
| you can sell it for cash in under a year then it is
| liquid. Sure if you tried to sell all coin today in the
| same minute you won't find a buyer but over a month this
| happens all the time.
| [deleted]
| hjorthjort wrote:
| I had never heard of this bridge before the attack. The
| fact that a project manages to attract half a billion in
| capital unfortunately doesn't say all that much, since so
| much capital is flowing in so fast to every project with a
| pulse.
|
| And the bug wasn't really obvious, although the lack of
| input sanitation is something an auditor (given enough
| time) would probably point out.
| yunohn wrote:
| Do you have some sources for this claim? Or just a belief?
| whitepaint wrote:
| High quality protocols like PoolTogether for example have
| this: https://docs.pooltogether.com/security/audits-and-
| testing
| yunohn wrote:
| Most people have never heard of PoolTogether, so I'm not
| sure if your definition of "first tier" and "high
| quality" is objective.
|
| Regardless, this quote from your link stands out: "it
| should never be expected that 100% of the deployed code
| has been formally audited."
| whitepaint wrote:
| It has $175 M locked in the protocol, it is also featured
| on https://ethereum.org/en/dapps/, and is one of the
| oldest DeFI projects. By my definition, it is both "first
| tier" and "high quality". We can of course have the
| philosophical debate of objectivity and if such thing
| even exists, not sure if it's needed here though.
|
| The audits of this protocol is also continuous.
| yunohn wrote:
| 175M$ is like 1/4th of the hack that this thread is
| discussing.
|
| Also, they specifically state that not everything is
| audited? Nowhere do they mention continuous audits.
| whitepaint wrote:
| You are right, it's not mentioned, but they do in fact
| spend hundreds of thousands every few months for audits.
| You'll find more info here: https://gov.pooltogether.com/
| 1998v2 wrote:
| Here are some examples I'm aware of, I haven't personally
| verified these.
|
| Uniswap: https://uniswap.org/audit.html
|
| Sushi Swap: https://github.com/peckshield/publications/blob
| /master/audit...
|
| Alpaca Finance (high complexity in my opinion):
| https://docs.alpacafinance.org/transparency
|
| A lot of projects provide their source and you can verify
| that what you're interacting with matches the source.
| crypt1d wrote:
| Not sure what you mean by source, but its fairly easy to
| find out if any official audits were done as this is always
| announced and documented by the involved parties (for
| example, I couldn't find any detailed audit info for Poly).
| It's not like the audit is mandated by law, its initiated
| by the SC owners to put the investors at ease. A lot of
| companies like Certik, Consensys, ZK Labs, etc. provide
| auditing services for this purpose explicitly.
| bko wrote:
| As this space evolves, I think there will be insurance and
| basic best practice safety measures. Also considering that
| almost all blockchains are open by design, it's no trivial
| task to liquidate a large sum of stolen tokens. So its not
| exactly a straight path from writing a script at Starbucks to
| making hundreds of millions of dollars.
| crypt1d wrote:
| I agree. There are already some insurance protocols in
| place - see Cover Protocol or Unslashed Finance. Its still
| very early in this space, but things are definitely
| developing!
| basseq wrote:
| > And law enforcement is a thing!
|
| More than that, there's a minority perspective in DeFi that the
| code is the law. If the code allows it (e.g., withdrawals under
| an unintended circumstance), it's therefore legal. If it were
| illegal, the code wouldn't allow it.
| GhostVII wrote:
| I think the bigger problem is people who are intentionally
| being malicious rather than people who stumble upon a bug. Just
| look at how many people fall for wire transfer or gift card
| scams. Crypto allows scammers to do that much more easily,
| since there is no human in the pipeline to flag transactions,
| and since there aren't the same limits that banks put in place
| on transactions. If someone finds a way to exploit a particular
| pattern/transaction type/etc. it's not like you can just
| immediately patch it when you have a decentralized currency.
| Ex. in an Bitcoin wallet malicious actors could show any text
| they wanted in an update popup [0]. So of course this was
| immediately used to steal millions.
|
| With crypto all it takes is one piece of malicious software, or
| to fall for a single phishing email, and you've lost
| everything.
|
| [0] https://www.zdnet.com/article/bitcoin-wallet-trick-has-
| nette...
| motoboi wrote:
| 1990's CGI. All over again.
|
| Never trust user input.
| joelbluminator wrote:
| So I'm gonna stick with real currencies but thanks...looks good.
| Clewza313 wrote:
| Here's the original thread, as opposed to a random person quoting
| a random tweet halfway into it:
|
| https://twitter.com/kelvinfichter/status/1425217046636371969
|
| https://threadreaderapp.com/thread/1425217046636371969.html
| rahimnathwani wrote:
| Calling dang.
| seanwilson wrote:
| > So someone realized that they could send an cross-chain message
| directly to the EthCrossChainData contract.
|
| > By sending this cross-chain message, the user could trick the
| EthCrossChainManager into calling the EthCrossChainData contract,
| passing the onlyOwner check. Now the user just had to craft the
| right data to be able to trigger the function that changes the
| public keys.
|
| Could this bug have been avoided by extra safety features in the
| language used to write the contracts like a better type system?
| Or the code wasn't using all the language features it could? I
| found the cause of the bug hard to understand to be honest.
| mrtksn wrote:
| Cryptocurrencies are fascinating but the irreversibility is not a
| feature but a bug.
|
| I don't get the appeal for irreversibility. A legitimate trade
| always occurs between willing partners, why would you be so
| afraid that the transaction would be cancelled?
|
| The only legitimate use that comes to my mind are complex
| financial instruments where things mostly happens with an
| assumption that the underlaying assets are very well defined, so
| you want assets be stable.
|
| Is there a company or cryptocurrencies focusing on solving the
| human part in the transactions? Huge part of the value with
| working in traditional systems is their resiliency against human
| errors. Sometimes mistakes happen(a faulty system, a design bug
| or straight out human error and people who are trying to take
| advantage of those), most of the time these are correctable.
| lucozade wrote:
| > why would you be so afraid that the transaction would be
| cancelled?
|
| The transaction will likely be for goods, services and/or
| money. If one or more parties don't provide said goods,
| services or money then the other parties may well want the
| transaction cancelled. That's different from them all being
| willing to transact in the first place.
|
| That's not a justification for irreveribility. The opposite in
| fact. But if you were planning on screwing your customer, say,
| the irreversibility is a bonus.
| cryptica wrote:
| Irreversibility is one of its best features. Imagine a scenario
| in 50 years when 80% of token holders are dead... This could
| result in a non-trivial % of tokens being lost forever; this
| greatly reduces the remaining circulating supply of tokens and
| thus makes everyone else who still remembers their keys
| wealthier (less supply, same demand translates to higher
| price).
|
| On the other hand, stocks are more susceptible to demographic
| collapse; for example, if a lot of shareholders die and all
| their relatives inherit their stocks, you can expect a selloff
| to occur which could crash the stock price. With stocks, shares
| are never lost forever; they just get passed down to an
| increasing number of increasingly lazy and incompetent heirs.
| That's not to say that cryptocurrencies cannot be passed down
| (they can) but the fact that they are tied to a secret
| passphrase (instead of the legal system) makes it more likely
| that they can get lost. The negative economic effects of wealth
| inheritance are not as strong in crypto space.
|
| The idea that negligent people may lose their tokens is highly
| meritocratic as it transfers wealth from negligent people to
| careful people.
| nradov wrote:
| That's just such a naive take with no connection to reality.
| Occasional deaths and inheritance by retail shareholders has
| zero impact on share prices.
| nybble41 wrote:
| Irreversibility in the core protocol is a feature, and a
| necessary one at that.
|
| If you start with irreversible payments and you need payments
| to be reversible with some kind of review/appeal process you
| can add reversibility through escrow. The classic arrangement
| is a 2-of-3 multi-key system where the payment is made to an
| escrow address where it can be either finalized or refunded
| only when at least two key holders concur; the third key, held
| by a neutral third party, is used to settle disputes when the
| payer and payee cannot come to an agreement on their own.
|
| There are, however, situation were reversible payments are a
| liability, and there is no way to build an irreversible payment
| system on top of a reversible one. For example, you can't build
| a reliable escrow system on top of reversible payments since
| the payer can trivially circumvent the escrow by unilaterally
| revoking their payment to the escrow account.
| lawn wrote:
| > A legitimate trade always occurs between willing partners
|
| Charge back fraud (also called friendly fraud) is a big problem
| in commerce, where the buyer will buy something, receive it and
| then cancel the payment. The merchant will often have to
| swallow the cost.
| mrtksn wrote:
| But that is an illegitimate trade and cuts BOTH WAYS. When
| the buyer is fraudulent the merchant swallows the cost AND
| when the merchant is fraudulent the buyer swallows the cost.
|
| That's actually why credit cards come with protection against
| fraudulent merchants and you need a good enough credit score
| to actually get a credit card. On top of that, payment
| processors run fraud detection systems that block suspicious
| actions.
|
| Irreversibility turns the trade into a competition over who
| is the better fraud. The only thing that the crypto
| guarantees is that the winner keeps the prize.
| legutierr wrote:
| > Sometimes mistakes happen(a faulty system, a design bug or
| straight out human error and people who are trying to take
| advantage of those), most of the time these are correctable.
|
| These errors are correctable if the counter-parties trust each
| other, or at least have a relationship that they don't want to
| undermine by being petty.
|
| Immutable blockchain systems are valuable in part because they
| allow entities to transact with each other even if they don't
| trust each other at all, don't know each other at all, or are
| even antagonistic with each other. Yes, if something goes
| wrong, a transaction won't be reversed, but without the
| blockchain these potentially antagonistic entities wouldn't
| have the capacity to do business with each other in the first
| place.
|
| Blockchains allow these entities capture the value of
| transacting with each other--value that wouldn't otherwise be
| realized--at the expense of irreversibility.
|
| You can potentially imagine that if antagonistic entities tried
| to do business in a more malleable environment, a request to
| reverse an error by one entity might not be honored by the
| other entity, or one entity might maliciously attempt to
| reverse a transaction that was _not_ performed in error, but
| was simply disadvantageous in hindsight.
|
| The possibility that a transaction may need to be reversed--or
| that a reversal request may need to be litigated--increases
| transaction costs, especially when counter parties are
| antagonistic. The certainty of irreversibility creates a
| context by which certain entities are willing to do business
| with each other, when they might not otherwise do business at
| all.
| mrtksn wrote:
| How do they transact if they don't trust each other? You have
| the guarantee that the money your received is not going back
| but what kind of guarantee does the receiver of
| product/service has?
|
| Yes - so far, it worked well for extortion with ransomware
| but is that something that we want to have? Can you think of
| a legit business case where the merchant providing the
| promised service is guaranteed and all you need is a method
| to receive the payment? All that when the merchant and the
| buyer don't trust each other at all and on't have a conflict
| resolution mechanism. What do they trade exactly?
| [deleted]
| imtringued wrote:
| One thing I don't understand is this. The vast majority of
| people will use credit cards (or equivalent) to purchase
| things. If I wanted to pay with Bitcoin I would get a crypto
| credit card.
|
| Payment processing just isn't the same thing as a currency.
| It's like expecting the dollar bill to do payment processing.
| Is lightning network supposed to be that fancy decentralized
| payment processing platform that is going to kill credit cards
| or will people stick with visa and mastercard?
| dboreham wrote:
| Yes and yes.
| colechristensen wrote:
| The end question is "why bother" with cryptocurrencies if you
| have a central authority that handles transaction disputes.
|
| It makes sense if you have a small group of trusted entities
| that want to have a ledger between themselves (like inter-bank
| ledgers for various purposes) but if you have somebody in the
| middle handling disputes... don't you just have paypal? Then
| cryptocurrency is just an extra complicated step that doesn't
| really matter.
| Taek wrote:
| The appeal for irreversibility is the complete removal of
| counterparty risk. It's a sharp edge and you need to be
| structured/careful, but for certain types of transactions, the
| cost of being careful is 100x cheaper than the cost of finding
| and using a trustworthy counterparty.
|
| A strong example of where the irreversibility of crypto is very
| useful is in the online sale of expensive electronic goods.
| Especially for things like speakers, TVs, and projectors, fraud
| rates are extremely high and boutique shops struggle to
| effectively support online customers, because such a large
| percentage of their sales get chargebacks after they've shipped
| the goods.
|
| If you accept crypto, you have a 100% guarantee that when the
| money has hit your wallet, the money is good and will stay in
| your wallet. You don't need to deal with an anti-fraud firm,
| you don't need to check whether this person is trying to have
| the goods shipped to a sketchy country, and you don't need to
| fear that your $6,000 item is going to sail away from you
| without payment.
|
| Yes, this means that the consumer has to fully trust the
| merchant, but in the case of online sales, the merchant is the
| known quantity with a reputation. Every consumer is a random,
| unknown person to the merchant and so it's much harder (and
| therefore more expensive) for the merchant to establish
| trustworthyness.
| yunohn wrote:
| > in the case of online sales, the merchant is the known
| quantity with a reputation
|
| This is absolutely not true. There's plenty of risk buying
| expensive goods online, lots of problematic merchants. I
| don't understand why merchants are inherently more
| trustworthy than customers?
| Taek wrote:
| It's not that merchants are inherently more trustworthy,
| it's that the buyer has ample opportunity to research the
| merchant and establish credibility. If there's a merchant
| that only accepts crypto and the buyer can't get
| comfortable that the merchant is trustworthy, the buyer can
| walk away instead of making a purchase.
|
| The merchant has much less to go on. There aren't review
| websites detailing the reputation and history of every
| random buyer that enters a credit card onto your website.
| barrkel wrote:
| I don't quite buy that. The ability to claw back credit
| card payments to fraudulent merchants enables commerce
| before credibility is established. This is in the
| merchant's interest too, especially when they're starting
| out.
| Taek wrote:
| It's only in the interest of the merchant if they are
| selling items that have a low enough chargeback rate.
| Credit cards and clawbacks work great in-person and for
| low value online merchandise but it's non-viable for
| online high resale value merchandise.
| yarcob wrote:
| This just moves the risk from the vendor to the consumer.
|
| I assume that most chargebacks happen for purchases made with
| stolen credit cards. So the chargeback just returns the money
| to the rightful owner.
|
| If the consumer used bitcoin, and someone stole their
| credentials to buy something, then they would have no way to
| get their money back.
| Taek wrote:
| The chargeback returning the money to the rightful owner
| doesn't help the merchant who shipped $6,000 of hardware to
| some stranger. Certain types of electronic sales simply
| can't be done online because of the high rates of fraud.
| When you add crypto, these sales become possible.
|
| Yes, they become possible at the cost of putting the
| counterparty risk onto the consumer, but that's better than
| the sale being entirely non-viable.
| yunohn wrote:
| I don't understand your line of reasoning at all. Like
| the others have said, moving risk from sellers to
| customers is not a solution.
|
| Especially when the risk of customers committing fraud is
| incredibly low. Why would you start with an assumption
| that this is something so rampant it needs to be solved
| in a way that harms literally all honest customers?
| Taek wrote:
| I operated an online store selling $2,000 pieces of
| computer hardware, and both credit card companies and
| banks alike refused to service us because fraud rates
| were extremely high.
|
| If you think fraud rates are extremely low, you've never
| tried to sell $2,000 electronics online as a boutique
| electronics store.
|
| Bitcoin was the only option.
| yunohn wrote:
| It's not that I don't believe there is fraud, I'm saying
| the vast majority of customers are well-intentioned. If
| this is not the case, could you point me to some sources
| and not just your anecdote?
|
| Regardless, how does Bitcoin solve this? There's a lot of
| illegitimate users of crypto, how are you solving fraud
| with irreversible transactions?
| Taek wrote:
| > If this is not the case, could you point me to some
| sources and not just your anecdote?
|
| It's difficult to find sources, but generally speaking
| you are going to go 'on warning' at around 1.5% and if
| you go too much over 2% chargeback rate you just get
| dropped by the credit card company as a customer. Credit
| card companies don't like dealing with high fraud
| customers and won't support you.
|
| https://chargeback.com/average-chargeback-rates-how-does-
| you... https://chargebacks911.com/chargeback-rate/
|
| Bitcoin helps in two ways. The first is that it gives you
| a way to accept money at all. As stated above, if your
| chargeback rate is above 2% for any extended period of
| time, all of your payment processors - including your
| banks - are going to drop you as a customer. You may be
| willing to pay 5% overheads for a higher chargeback rate,
| but your credit card company doesn't want that as a
| statistic and they just won't support you.
|
| The other way Bitcoin helps is that once your wallet (use
| BTCPay) says "2 confirmations" you've got a 99.97%
| guarantee that the money is yours and won't be reverted.
| And that's true whether you are receiving $2,000 or
| $2,000,000. Regardless of whether that money came from
| "an illegitimate user", you as the merchant can be
| confident shipping hardware out because you know that the
| payment is not going to be clawed back.
| barrkel wrote:
| Fraud is a cost of business. Prices can be raised to take
| it into account; different markets have different rates
| of fraud, but fundamentally it can be priced in.
|
| Merchants are in a much better position to price this in
| than consumers. Merchants structurally execute a lot more
| transactions within a market vertical than consumers ever
| do.
|
| If the merchant can't do that, because deals are simply
| too high value or aren't frequent enough, then insurance
| companies or intermediaries (e.g. payment processors) can
| pool risk across merchants, using actuarial techniques to
| assign a price to the insurance. For example,
| professional indemnity insurance for property
| transactions.
| ryani wrote:
| If you raise your prices, you drive away legitimate
| customers but don't drive away fraudsters, since the
| fraudsters aren't actually paying with real money. So
| raising your price _increases_ the percentage of fraud
| you see, which means you probably need to raise your
| prices further, which further increases the relative
| amount of fraud.
|
| To counteract this negative feedback loop, assuming the
| increased prices don't drive away all of your real
| customers, you can spend the increase on transaction
| analysis, and turn away customers based on their
| likelihood of fraud, so you've added inefficiency into
| the system to help deal with a criminal element, and also
| likely turned away real sales due to false positives in
| your analysis.
|
| It's no surprise that these types of merchants are
| looking for a disruptive technology to remove this
| inefficiency. Doing so would allow them to charge less
| and outcompete as well as capture the entire market of
| people marked as false positives by other merchants.
| astoor wrote:
| > irreversibility is not a feature but a bug
|
| Completely true. Irreversibility and lack of consumer
| protections might just about fly for small transactions with
| pocket change which people on both sides of the transaction
| don't mind losing, but isn't going to be acceptable to most
| people for larger transactions. If I'm buying a house, for
| example, I don't want the risk of it being stolen because of an
| unfixable bug in a smart contract, or sold to the wrong person
| by an irreversible mistake entering the address. Scaling up
| further, if you look at the back office for any investment
| bank, a big chunk of people power is spend on trade
| reconciliation and essentially fixing human errors - this is a
| good thing for both parties making such transactions.
| im3w1l wrote:
| So my understanding of contracts (and particularly cross chain
| ones) is low. But how likely is the compare-four-bytes-only to be
| a deliberate weakness? Is this an inside job?
| creshal wrote:
| Cynic mode: Putting sighash in things you shouldn't is
| incredible common cargo culting in cryptobro areas, it's much
| more likely that the people involved didn't even understand its
| implications.
| malthaus wrote:
| So as someone very critical of the whole DeFi / Smart Contracts
| philosophy (purely in terms of practicality, not the high-level
| concepts behind it) - please explain to me how the impacts of
| those bugs are going to be mitigated going forward.
|
| At will and ex-post broadcasting "oops, we had a bug - please
| roll back or block the bad actors" doesn't strike me as a solid
| solution, nor a fair & automated one. I was under the impression
| this hyped up space learned from the DAO fiasco but i might be
| wrong.
| zimbatm wrote:
| I bet that we will see insurance companies emerge in the
| market. Contracts will send a portion of the transaction to an
| insurance company. The insurance company would mandate "layers"
| to validate the contract. Users can then claim damages if there
| was a bug in the contract.
|
| Once all this is done, the transaction fees will be equal or
| higher than traditional banking systems :-p
| legutierr wrote:
| Over time, there will be old smart contract code that is
| trusted because it has been used for so long, and there will be
| new code that is less trusted because it is new. Time will
| ensure that smart contract code that is flawed will be
| discarded and forgotten, or blacklisted, so it will be safe to
| assume that any old code that is still popular is trustworthy.
| Time will also ensure that popular code is well understood by
| experts who would be in a position to detect and understand any
| problems in the code.
|
| The problem of buggy software will continue to exist for new
| smart contracts that are introduced and manage to capture value
| quickly, but as the ecosystem matures and more niches are
| filled, new code will be less likely to attract large numbers
| of users, so the scope and impact of any bugs in that code will
| be much less.
|
| Eventually an equilibrium will be reached whereby survival of
| the fittest ensures that the smart contracts most people rely
| upon can be trusted. Effectively, some smart contracts will
| build brand value, and people will be able to rely on the
| reputations of these smart contracts. Some people may take a
| risk on a new smart contract and loose (or win), but most
| people who follow the heard will not have a problem.
| GhostVII wrote:
| The problem is that it is totally possible for there to be a
| hidden bug in an old smart contract that everyone trusts. And
| only a single bug like that can destroy the entire ecosystem.
| It's not enough for trusted smart contracts to be less buggy,
| they have to be so secure that they don't have any bugs ever
| legutierr wrote:
| Yes, the process I described above would not be sufficient
| to ensure that smart contracts are perfectly safe, with
| zero exceptions ever.
|
| It is also important that scrutiny be applied to these
| protocols, and I imagine that at some point DeFi protocols
| may be be subject to regulator audit and approval before
| they are opened up and made available for use by retail
| customers. If the right people pay enough attention to the
| implementation of these protocols, then it should be
| possible to trust them. Also, if you yourself are risking
| significant funds, it wouldn't be a bad idea to personally
| review and understand the smart contract code.
|
| That being said, over extended periods of time (decades),
| long-lived smart contracts will tend to be safer, and
| insecure smart contracts will tend to be identified as
| such. If enough value is at risk, and if enough time has
| passed, then it is extremely unlikely that an exploitable
| bug will exist that has not already been exploited.
|
| Keep in mind that as a general rule smart contract
| implementations are immutable, so any bug that exists
| within a protocol is typically a bug introduced to the
| protocol when it is first deployed. There are never any
| "new" bugs that are introduced to an existing smart
| contract; if a bug emerges after a long period of time has
| passed, it is a bug that existed at the beginning but had
| not been previously identified.
|
| At a certain point the passage of time will have reduced
| this risk below a tolerable threshold that is more than
| outweighed by the value that people get from using the
| software. So in practical terms, in the aggregate, such
| long-lived systems could reasonably be treated as secure.
| masa331 wrote:
| You can't really mitigate this entirely as you can't really
| write software without bugs.
|
| There will always be a need for this eventual "please roll back
| or block the bad actors". And more money you put into the game
| more it will be demanded when someone gets hurt.
|
| I don't like crypto but this way of fixing things is pretty
| normal and standard in software and orher industries also. You
| simply can run into situations which weren't planned. So i
| don't think there is a problem with these fixes
| hoseja wrote:
| Sounds to me like there's a decentralized, trustless
| incentive to make sure your software is secure. Yelping NO
| FAIR! and central-bank-style rolling back the oopsie does not
| seem very radical and libertarian and crypto.
| ed_elliott_asc wrote:
| "You can't really write software without bugs" - which is why
| crypto will never be for me
| G3rn0ti wrote:
| This is plain silly. Even centralized payment settlement
| systems do depend on thousands of lines of closed source
| code that contain bugs. Banking backends have bugs. Cars
| have bugs. Even buildings may have fuck ups that need to be
| dealt with after construction.
|
| If you think it through you simply can not rely 100% on
| anything humans build. But still societies as a whole
| thrive and human progress is real.
|
| DeFi is no exception. It's designed to make banking
| cheaper. But it's new technology and will take some time to
| mature.
|
| Personally, I believe banks won't exist in the traditional
| sense anymore 20 years in the future if you like it or
| don't. I mean, I love steam locomotives but I don't expect
| them to be a common means of transportation ever again. ;-)
| dqpb wrote:
| > you can't really write software without bugs
|
| Formal verification
| lmm wrote:
| > I don't like crypto but this way of fixing things is pretty
| normal and standard in software and orher industries also.
| You simply can run into situations which weren't planned. So
| i don't think there is a problem with these fixes
|
| It's normal in most industries, but it also defeats the main
| selling point of crypto - "code is law" doesn't actually
| work, you always end up in a world of humans and politics.
| masa331 wrote:
| Yes i agree and i don't think there is actually a problem
| with that. We are humans and we should be able to solve
| problems like this. I try to view it just as another way of
| bug fixing technique. Sometimes you can just explain that
| you messed up and others will understand
| throwaway6734 wrote:
| Relying on an external authority to control the allocation of
| money seems to completely undermine the purpose of crypto.
|
| What's to stop these actions being taken for reasons other
| than theft?
| masa331 wrote:
| You always need to rely on some external authority. You
| can't crypto/decentralize everything.
|
| And relying on external authorities is a good thing
| actually. Because it's way way more effective than software
| solutions. Now of course the external authority can
| compromise sometimes but for this we also already have
| solutions for like thousands of years - diversification. If
| people just would learn not to put all their eggs into pne
| basket and expect eventual compromise that wouldn't be a
| problem. I think some 101 finances and practical real world
| problem solutions classes or something like this would get
| us way further than decentralisig everything with software
| moss2 wrote:
| When was the last time banking software got hacked?
| Taek wrote:
| At least up to this point, the amount of growth in the industry
| from moving fast and having buggy software (as opposed to
| moving slow and having fully verified software) has more than
| made up for all the hacks. For every $600 million dollar hack,
| there's been $6 billion dollars in gains from growth in the
| industry. Moving slower means fewer hacks, but it also means
| lower growth, and the growth is the more important multiple
| right now.
|
| As the growth slows down there will be an increased focus on
| best practices for smart contracts, on auditing, and on formal
| verification. There are also a lot of startups that are looking
| into insurance for smart contracts and crypto balances in
| general.
|
| In general, the best experts in the space could probably write
| smart contracts with >100x fewer bugs than your typical smart
| contract. Especially with something as complex as the EVM it's
| difficult to assert that any piece of software is truly bug-
| free, but there are a lot of steps that can be taken to make
| them significantly more rare. It's just that these mitigating
| steps are more expensive than the growth at this time.
| gjulianm wrote:
| There are several issues with this. The main one is how can
| people trust a product that will let them lose money in the
| name of growth.
|
| The second one is that the more money, the more incentives to
| hack. And given that transactions are irreversible, you only
| need each bug once, you don't care that it's fixed later. So
| if a bug can report a hacker millions of dollars, there's
| going to be quite a lot of hackers researching, probably with
| more effort there than the effort put in best practices,
| audit and formal verification.
| irjustin wrote:
| Can someone help ELI5 please?
|
| [EDIT] Okay not 5... maybe like 25 but not in crypto tech.
| saalweachter wrote:
| Smart contracts are actually dumb contracts.
| lordnacho wrote:
| My quick reading of it: there's this chain of chains that tries
| to make it possible to interoperate the various blockchains.
| The way they do it is they have a gatekeeper on each chain that
| locks up funds on one chain and releases them on another.
| Someone found a way to replace this gatekeeper with their own
| version, leading to havoc.
|
| The technical details are fascinating and super complex. And
| IME comically badly documented.
| trhway wrote:
| >Someone found a way to replace this gatekeeper with their
| own version
|
| The gatekeeper function was "protected" by hash of its name
| and parameter types and this is the $600M quote:
|
| "You don't need to find a full hash collision, you're only
| checking the first four bytes. "
|
| And it is all in the environment where mountains of hardware
| with highly optimized software are combined in huge networks
| with the only purpose of calculating few basic types of
| hashes :)
| cesarb wrote:
| If I understood it correctly, there was one contract
| (EthCrossChainManager) which could call arbitrary methods on
| other contracts, the methods being identified by a 4-byte hash.
| There was another contract (EthCrossChainData) which had a
| method the attacker wanted to call, since it allowed to change
| relevant public keys, but which had a check on the identity of
| the caller. However, that check allowed the former contract to
| call the later. So the attacker only had to find a method name
| which led to the same 4-byte method identifier, and trick one
| contract into calling the other; the first one though it was
| calling an arbitrary function on an unrelated arbitrary
| contract, while the second one thought it was a legitimate
| internal call from the related first contract.
|
| As another comment mentioned, this is a classic "confused
| deputy" vulnerability.
| vincnetas wrote:
| I would say it was confused deputy attack :
| https://en.wikipedia.org/wiki/Confused_deputy_problem
| legutierr wrote:
| Ethereum smart contract functions (i.e. methods) are addressed
| based on a four-byte hash of the signature, within the context
| of the smart contract itself (a smart contract is analogous to
| a Java or Python class instance, having state and logic). So,
| after compilation, a function will be addressed like <smart
| contract address>.<method hash>, if you can imagine.
|
| This is distinct from other languages where methods and
| functions are addressed unambiguously by the full signature as
| a string (like in Python), or by a specific memory address
| (like in C).
|
| In most situations this addressing scheme works very well,
| because in practical terms there will never be a hash collision
| inside of a smart contract, and if there were such a collision,
| the compiler would catch it and fail to compile, and the EVM
| would reject any bytecode containing such a conflict.
| Regardless, this is not a problem within Ethereum.
|
| The thing is, Poly Network is a separate thing from Ethereum,
| and although it does integrate with Ethereum, it does so with
| its own separate software. The way it interfaces with Ethereum
| is via several Ethereum smart contracts, including one (smart
| contract #1) that holds the tokens that it manages on the
| Ethereum blockchain (valued in the hundreds of millions of
| dollars), and another (smart contract #2) that permits users of
| the Poly Network software to invoke arbitrary functions on
| arbitrary smart contracts already deployed on Ethereum. The
| Poly Network software talks directly to these smart contracts.
|
| Poly controls these smart contract with a permissions system
| implemented inside the smart contracts themselves, whereby the
| invocation of any function of the smart contracts is verified
| against a list of public keys (i.e. account addresses) that are
| authorized to make any such invocation. Only users that hold
| the private keys that correspond to these authorized public
| keys may invoke the smart contracts' functions; in practice,
| these keys are controlled by the Poly Network software. Each
| smart contract stores this list within its own data (analogous
| to private instance data inside a Java object).
|
| The problem is that the Poly Network proprietary software uses
| the same authorized key pairs to move funds in and out of smart
| contract #1 and also to invoke smart contract #2. This means
| that a user of the Poly Network software can use smart contract
| #2 to invoke smart contract #1, which is very bad.
|
| What happened is that the hacker figured this out, and used
| smart contract #2 to update the authorized public key list
| inside contract #1, which was allowed to happen because he
| routed the message through the Poly Network software, which
| dutifully signed the message with its own secure private keys.
| In other words, the Poly network signed a message from the
| hacker authorizing the Poly smart contracts to replace the
| authorized public key list with the hacker's public key, giving
| the hacker control over contract #1.
|
| It wasn't as simple as this, though. Apparently, although the
| Poly Network allows any function name to be invoked by the end
| user, that function is required to be invoked with a signature
| that includes a particular set of arguments, specifically
| "(bytes,bytes,uint64)". The hacker wouldn't be able to call
| "putCurEpochConPubKeyBytes" directly from the Poly Network
| software, because "putCurEpochConPubKeyBytes" accepts only one
| argument, not the three arguments that the Poly Network
| software uses to construct the signature for function
| invocations sent from contract #2.
|
| So, the hacker had to discover another function name that when
| combined with the three arguments would result in a four-byte
| hash that corresponded to the four-byte hash of the function he
| wanted to invoke. By brute force the hacker discovered that
| "f1121318093(bytes,bytes,uint64)" has the same four-byte hash
| as "putCurEpochConPubKeyBytes(bytes)". So the hacker used an
| invocation to "f1121318093(bytes,bytes,uint64)" to invoke
| "putCurEpochConPubKeyBytes(bytes)" on contract #1, and thereby
| replace the authorized public keys for that contract with his
| own. Having obtained control over contract #1, he was able to
| transfer out all of the tokens it controlled, to the tune of
| hundreds of millions of dollars.
|
| There are any number of ways that Poly Network could have
| prevented this from occurring, most obviously by not allowing
| contract #2 to invoke contract #1. They also could have done a
| better job of filtering what kinds of messages users can send
| from the Poly Network software.
| MauranKilom wrote:
| Very ironic (or topical?) for a crypto exploit to boil down to
| finding a hash collision.
| paulgb wrote:
| "Find a hash matching these digits" is roughly Bitcoin's proof
| of work system. Maybe another way of looking at this is that
| these weren't hackers, they were just miners who found a more
| lucrative coin to mine.
| t0mbstone wrote:
| OMG that's brilliant
| jokoon wrote:
| I'm having a great laugh every time I hear about crypto-stuff
| goofs.
|
| Who thought an amazing new P2P invention would improve the image
| of normal money and traditional banks?
| whitepaint wrote:
| Rome was not built in a day. Examples of 2008, GME fiasco, and
| many other display a clear and obvious need for decentralized
| finance.
| thehappypm wrote:
| In my opinion, 2008, GME, and many other gaffes really show
| we need more regulation -- not less!
| dqpb wrote:
| Mocking inventors for the challenges they cross along the way
| tends to not age well.
| exo762 wrote:
| > Who thought an amazing new P2P invention would improve the
| image of normal money and traditional banks?
|
| Shady stuff that happens in the banking system usually happens
| behind the closed doors and we don't hear about it for years,
| if ever. Crypto/DeFi is new and exciting - it gets a lot of
| attention from press. It is still way easier for me to trust
| code than to trust people. Call it a character trait / flaw if
| you want.
| NicoJuicy wrote:
| Can't really hide lost funds worth 600 million $ because of a
| hack.
|
| "Exciting" or not.
| londons_explore wrote:
| "Check the first 4 bytes of" should be banned in crypto code.
|
| Either I want something to match, in which case check it all, or
| I don't care if it matches, in which case don't check at all.
|
| Why would you ever check 4 bytes?
|
| To me it smells like a way to prevent fuzzers stumbling on a
| deliberate loophole.
| et2o wrote:
| This is perhaps the most confusing element of it all, to me. I
| can hardly imagine a legitimate reason to do this. Defeats
| entirely the purpose of a hash.
| ed_elliott_asc wrote:
| Checking whole hash was probably too slow, you can imagine
| they put in a check for first four bytes, if that matched
| then check the whole hash - probably merge conflict and lost
| the second bit - doesn't seem too far fetched!
| thrwawy4345784 wrote:
| Maybe somebody thought of short sha-1 id's of git:
| https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection
| With that only 4 chars is enough to identify a commit :-)
| cesarb wrote:
| If I understood it correctly, the purpose of this hash is
| just to shorten the method signature (name+types) to a 4 byte
| identifier. Unless a contract has thousands of methods, the
| chance of collision is very low (and the compiler could
| detect any collision, since it can see all methods). The
| "legitimate reason" for shortening the method signature is
| probably just to save space; bytes on distributed blockchain
| transactions are expensive.
| abstractbarista wrote:
| This blew me away. That's 2^32. They took a cryptographic hash,
| with good preimage/second-preimage/collision resistance, and
| then discarded 7/8 of it before comparing to ensure some user-
| provided input is valid. _What in the world?!_
| social_quotient wrote:
| Is the disincentive with lack of security going to be so strong
| with crypto projects that people finally take it serious enough
| to make it a first priority?
|
| I don't like loss or theft ,obviously, but I have to think if
| regular IT/apps/software/networks etc.. had this big of a
| material threat, we would see far more secure systems and
| organizations.
|
| So it would reason that as block chains and crypto eat the world
| they will raise the bar.
|
| Am I thinking about this right?
| whitepaint wrote:
| Haha, that is a really interesting point. It actually seems
| inevitable imo.
___________________________________________________________________
(page generated 2021-08-12 23:02 UTC)