Backdoor in the firmware of Antminer Bitcoin mining hardware
antbleed.com
antbleed.com
That's why redirecting the traffic from "auth.minerlink.com" to point at "127.0.0.1" is an effective way to bypass the issue. The server (localhost) isn't responding with false and thus the system stays up and running.
The idea that all machines would be shutdown globally seems a bit excessive. While possible it would require Bitmain to lose control of their domain globally, and I imagine an issue like that would get resolved fairly quickly.
That being said it is a bit stupid of bitmain to be doing this, especially if they aren't even doing it over SSL.
While this is obviously a big problem, it is a little bit of a vindication for me, because people have scoffed when I've expressed concerns that bitcoin mining is too centralized. [0]
And if one ASIC vendor can do this, what could a government do? [1]
-Dune
So yeah, just because it explicitly looks for false doesn't mean it's a non-issue.
That is far from how it's called a distributed ledger.
Not sure the percentage of machines with the capability out of Bitmain's products but it's said Bitmain's products provide about 70% of the global hash rate.
It also looks like the backdoor may have a remote code execution vulnerability: https://twitter.com/petertoddbtc/status/857340167400587264
https://github.com/bitmaintech/bmminer/blob/b5de92908498590d...
Edit: Nobody cares about the vulnerability until it has a name and a logo :-)
If it really can kill a large fraction of the remaining hash power it is quite likely they would control over 50% themselves.
That is scary! Especially as they are known to act maliciously in other situations and are opposing the remaining part of the community in the Segwit vs Bitcoin Unlimited debate.
Surprising, as it seems like a straightforward, real issue.
If that's confusing, as a hypothetical example: You just linked to an /r/conservative thread about Trump's alleged Russian ties.
The opposing subreddit (i.e. the /r/politics thread) is much less forgiving about it: https://www.reddit.com/r/Bitcoin/comments/67qwqv/antbleed_ex...
Even without Bitmain being malicious, the API is unauthenticated and would allow any MITM, DNS or domain hijack to shutdown Antminers globally. Additionally the domain in question DNS is hosted by Cloudflare making it trivially subjected to government orders and state control.
But even if it happens, all you have to do is update the firmware again, and keep mining.
But let's imagine someone actually does shut down 70% of the mining power. What's the real consequence? Blocks will be mined somewhat slower (but not even close to 3 times slower) till the difficulty self-corrects. In the very worst case that will take 2016 blocks, or 14 days.
I'm not them, so I don't know.
That sort of mechanism doesn't build itself, though, so I have to imagine they have at least one scenario in mind...
Also, reason #547 I don't take Bitcoin seriously. One vendor gets popular, and 70% of your infra depends on a watchdog not malfunctioning. That is not a sign of a stable ecosystem.
Most likely this is an attempt at DRM, an ability to remotely shut down any units they've deemed infringing or violating their TOS or haven't paid a renewed licencing fee or whatever (I don't know what their business model is)
The "enemy" fork loses massive hash power at a critical moment.
It is also a network security concern. Bitcoin's 50% security definition is already pretty weak compared to most crypto security definitions. If you have a seperate attack that can take out 70% of the network, then you only need to have power equal to that of 30% of the network to launch a double spend attack.
By itself this might not be enough to make an attack feasible, but if the network is vulnerable to enough of these attacks at the same time, they would compound and a succesfully double spend becomes possible.
P.S. And btw, it's >50% attack, not 51% attack. You don't need that whole extra percent.
If you can shut off 70% of all the miners (because they run backdoored hardware), then you only need >50% of the remaining 30%, no? Which should be a lot easier.
If bitmain (or an attacker) took down 70% of the mining power but one miner either didn't use any bitmain hardware or was otherwise protected from the shutdown they would very likely have over 50% of the remaining hashrate. This could give them control over the blockchain until other miners got back online and their share of the overall hashrate dropped below 50% again, worse yet a difficulty correction won't fix things if other miners are slow to recover.
https://blockchain.info/blocks
Which one is it?
The difficulty self-corrects every 2016 blocks, or 14 days if there's no major change in the hashrate. If the hashrate drops by 70% then the worst case is 14 / 30% = 46 days of slow mining until the next correction.
I agree with your overall point; just here to point out the math error.
Think of it as a race, many participants are running the distance with slightly different speeds. You randomly remove 70% of the runners, and your new top runner will be likely just a tiny bit behind the previous top runner, if at all.
The better analogy would be a race to turn over stones looking for the one with the secret on the back but the number of stones was adjusted for the previous number of searchers and now with fewer searchers it will take longer for any of them to find it.
Shorting 100x before shutting them down sounds like a good incentives for those people.
If the next patch includes a localhost server that can proxy communication to auth.minerlink.com, the issue returns.
If the next patch updates the url to auth2.minerlink.com (or any other domain), the issue returns.
If the next patch flips from default-allow to default-deny, all customers will be out of luck until they patch and come back to the central control mechanism.
If the next patch implements some form of authentication such that you can't easily spoof a "True", all customers will be out of luck.
If the remote code execution is used to patch code without the administrator's knowledge/permission (haakon has a link saying remote code execution is possible) any/all of the above are trivially easy to take advantage of.
Lastly - my understanding of bitcoin is a little fuzzy, but I believe with 50% of the computing power, you can rewrite transactions as you please, capturing as many bitcoin as you want. If you had a plan to not centralize those accounts, it would be extremely difficult to sort out.
Close. My understanding is rusty too, but I'll give it a go. Someone more versed in the technicalities of bitcoin, please correct me.
"51% attacks" threaten the integrity of the money supply because the network works by consensus. A transaction is considered valid once miners authenticate it by including it in blocks (blocks are issued ~6 times per hour). The network awards new bitcoin with each block.
If you control most of the hash power, you can attack the network by including illegitimate transactions in the blocks, effectively creating a new version of the ledger.
If you own coin ID A and send it to address B, that transaction gets included in a block and becomes official. You can't spend that coin again because the next miner won't include it in a block, since the previous block said it's already been spent. But if you control most of the hash power, you can teach your miner to skip the spent check for coin ID A and include it in every block that gets computed. This is called a double-spend attack because it lets you respend that coin more than once.
This is why bitcoin payment confirmations can take a while. Anyone can submit any transaction they want, but you have to wait for a block to be issued to issued to ensure it matches the ledger's accepted state. To be really careful, you need to wait for more than one block, since a rogue miner may have been able to get a bad block accepted. This is why btc payment processors would wait 3 blocks before an immediate transaction would be confirmed (~30 minutes).
The upside of this is that the community can decide to change its mind, and if you get the miners calculating according to the proposal, it becomes the standard. This is why a lot of people consider bitcoin a "consensus protocol".
It would be easy to track and untangle double-spends, however, because everyone could see when the invalid blocks started getting included and cut the chain there. The hard part would be moving everyone over to the new version of the blockchain that didn't include the double-spends.
This part is incorrect. Any block with an invalid transaction will be rejected by the rest of the network.
Faced with two competing chains, my understanding is that the bitcoin network chooses the longer one, assuming that the other tangents are dead (either due to a policy change or an invalid block).
In practice it would probably help to control more than 51% of the network, but it's called a 51% attack because theoretically, that's all you need to create the longest (that is, the winning) chain.
The network includes all of the individuals and businesses who run nodes but don't mine. They will only accept valid blocks.
So say you execute a 51% attack and attempt to include an invalid transaction. No other node on the network will accept that block as valid. So all of the businesses, including the bitcoin exchanges, will reject your block as invalid and not process it. And any block you try to build on that invalid block will also be invalid for the same reason.
You cannot include any invalid transactions in a bitcoin block even if you had 99% of the hashing power. The rest of the network will just ignore all of your blocks and will accept the next valid block that comes along.
You need to follow the chain back from the very first block (the genesis block), not only to verify the following blocks but any blocks in the future (you could spend an unspent output from the very first block and it would be valid). Luckily, you don't actually need to store the blocks, just the parts that affect future validation (the UTXO set), so you can throw the blocks away after this (called prune mode in Bitcoin Core). As long as you can put up with the initial sync (several hours) the costs aren't too bad. In fact, I would argue the very limited powers given to miners is one of the most important parts of Bitcoin.
When even a single transaction in a block is invalid, the entire block is rejected wholesale.
That said, clients will choose the valid chain that took the most work to create. If someone with 51% starts creating invalid blocks, nobody else will accept them, and the practical effect will just be a 51% reduction in mining power on the network.
EDIT: Oops, brain fault. I had this tab open for a few days, then happened to come back, read the parent comment, and responded; only then did I realize it was posted 6 days ago, not 6 minutes ago..
You can, however, deny certain (or all) transactions from being mined into a block. And you can exclude past transactions if you can overtake the current longest chain. But rewriting history to exclude past transactions would require more than 51% of the hashing power. The further back you go, the more power it will require to overtake the longest chain.
You can re-spend the coins that you own and send them to another location and invalidate one of your own spends.
You cannot rewrite or modify any other transactions that you do not hold the private keys for. You can only withhold them from a block.
The problem is far more daunting than just creating a chip. You need to rigidly hit a schedule or it's immediate game-over. Most of the people who created and worked at HashFast are friends of mine; I got an up-close view of how that fiasco played out.
Hardware depreciates rapidly as the difficulty goes up. If you slip by a few months, it may cut the expected value each box will generate in half. How many hardware kickstarters deliver on time? When you have a delay, you're not facing some yuppie whining about having to wait for their toy - it's a commercial buyer watching their ROI diminish with every passing day. They'll sue, dox you personally, and generally act like the least mature elements of 4chan.
Bitcoin hardware is a shitty business with shitty customers and zero brand loyalty. Whoever has slightly more hashes per second per dollar gets all the sales. Every product is obsolete when it ships, so there's zero tolerance for mistakes in the learning curve. I'm not surprised at all that a single company dominates. You'd be a fool to get into this business.
I think that people are primarily pissed with them for blocking SegWit for absolutely no good reason [0], against the wishes of the industry and community.
[0] one potential explanation is that SegWit blocks a covert performance boost that Bitmain secretly built into their ASICs. https://bitcoinmagazine.com/articles/breaking-down-bitcoins-...
Since when do businesses have to play nice along others' wishes?
Stop blaming financial incentives...
While they have been acting somewhat hostile to the rest of the community, this "please be nice even by sacrificing yourself or you're evil" sounds crap as a real world claim.
tldr; Code left behind from abandoned feature implementation to allow owners to remotely shutdown miners that have been stolen/misappropriated. Our bad... sorry.
YC has already funded at least one Bitcoin startup, which is currently doing quite well for itself (Coinbase).
Of all the ASICs that could be built, mining ASICs are the least risky. Their logic is simple, repetitive, and self testing. They have the highest yield and are the most flexible for binning.
And cryptocurrency mining has a _long_ history of pre-sales. That effectively eliminates all risk.
This is completely ridiculous. I've never seen anyone supply numbers to remotely back this up. A few people have linked to a blog post that through extrapolation and gross misunderstanding asserted that bitcoin mining used up as much electricity as all of Ireland (lets use our very best judgement).
The truth is the financial industry is 8% of GDP. How much power does it take to air condition all the banks of world?
Beyond that there is the fact that not all electricity has significant environmental impact and the fact that bitcoin mining ends up happening in places where electricity is the cheapest and most plentiful, which means it probably is not being generated with coal or oil.
This assertion is an enormous detachment from reality based on gut feeling.
The Bitcoin network hashrate is currently at ~3,800,000,000 GH/s. The most efficient miners are at ~0.1W/GH. So the Bitcoin network, at its most efficient, would be using 380,000,000 Watts right now.
I'm not sure what to compare that against. I looked up and found this article: https://www9.nationalgridus.com/non_html/shared_energyeff_of...
That article says that office buildings use ~1.53 Watts per square foot to cool the building (that's an average 1.53 throughout the year). So the power used to secure the Bitcoin network is equal to cooling ~248 million square feet of office space. Sounds like a lot, but pulling up a random office building, 55 Water Street, and I see it's 3.5 million square feet.
The U.S. as a whole uses 446,689,497,716 Watts on average. So Bitcoin is using 0.085% of the total U.S. power consumption. Or, 0.015% of world power consumption.
I have no idea if what we are currently spending on the Bitcoin network, in terms of natural resources, is more or less efficient than our current banking system. But those are the numbers.
Personally, I don't think any of its relevant. Reducing energy consumption should not be the primary focus of our species. We should focus on increasing sustainable energy _production_. Energy production is a core attribute of our economy and our civilization. It may even be the _most_ important thing to us, as a growing species. Obviously reducing waste when we can is good, but I'd rather expend the majority of our resources building out solar installations rather than quibbling about whether Bitcoin is power efficient or not.
They conclude that "the power currently used for Bitcoin mining is comparable to Ireland’s electricity consumption."
[0]: https://karlodwyer.github.io/publications/pdf/bitcoin_KJOD_2...
Before I point out the absurd flaws in how they came to this conclusion, how likely do you think it is that in 2014, the electricity use for bitcoin mining was equivalent to all the private, public, commercial and industrial electricity used by over 5 million people?
Undoubtedly there is huge amounts of energy being pumped into Bitcoin daily, but it's environmental effects seem over-hyped compared to many other human endeavours.
If that's accurate, then that's not the same as building a mining chip. The mining, for them, was just a way to make their microservices stuff viable. Everyone I ever heard who discussed those offerings of theirs knew that the tiny mining cores weren't profitable, and said as much. It's obvious that any chip which isn't 100% dedicated to mining won't be economically viable.
https://www.blocktrail.com/BTC/pool/21inc
The chips on devices thing was a pivot once their initial idea didn't work.
What level of capital commitment would you need to build a proof of concept?
Yes, I co-founded a company a few years back that designed, built, and sold FPGA mining equipment. We are probably one of the very few hardware Bitcoin mining companies to ship hardware on-time with nothing but happy customers. I designed the FPGA firmware (which is open source), embedded firmware, and drivers. Others designed the boards, software, etc.
> What level of capital commitment would you need to build a proof of concept?
Depends on what kind of proof of concept. A small scale proof of concept, where you have a board in your hands that's mining Bitcoin, would cost ... nothing. I'd just lend my devkits to the company :P Or the existing FPGA miners that we built.
Sometimes it's required to simulate a significant percentage of the final ASIC design. That would require a much higher end FPGA devkit; ~$10k-$20k. Sometimes you can get FPGA vendors to loan you the kits, though.
If the goal of the company is merely to sell mining equipment, or if that's necessary to promote a crowd funding round, then the proof of concept should probably be closer to what that shippable product would be. I'd rough that out to maybe $100k to pay a board designer to do layout and fund a spin or two of small quantity prototypes based on FPGAs for simulation. That board design would then be re-used once the ASICs are ready. That's back of the napkin; could be more or less depending on scope but generally in that 6 figure ballpark.
If you want to make one let me know, I'll happily be a tester for you!
"https://github.com/bitmaintech/bmminer/blob/master/driver-bt...
If the file is edited that link is useless. Even worse, removed or moved.
Press "y" and you get: https://github.com/bitmaintech/bmminer/blob/b5de92908498590d...
Thanks for sharing.
1. The fact that it exists
2. The fact that they're using "something" bleed as the name (creativity, please)
3. That whoever created this page recommends the user alter the miner to point to some other, user-controlled HTTP server, effectively MITMing anyone who sees this page.
Shame.
https://www.reddit.com/r/btc/comments/67rbyz/is_antbleed_the...
It's interest who made this comment and why.
Yes, it is quite common to have the ASIC connect directly to the mining pool servers (over TCP with the Stratum protocol).
>127.0.0.1 auth.minerlink.com
This is localhost.
139.59.36.141 auth.minerlink.com
This will cause the Antminer to connect to our test server
Look at this site and twitter account. You can't get any info on who registered the site because it's protected by "privacy guard", why should anyone trust this site? And their twitter account looks more like marketing campaign from competition.
The main advantage i can see is that this provides an easy way of proving there really is a kill switch.
Seriously, it isn't even a data leak.
But even if a third-party exploit were impossible, it's a real problem if one company actually has a kill switch for 70% of Bitcoin's hashing power.
In particular, in this case, it sounds like the offending code:
* Makes outgoing connections with sockets * Alters the flow of execution outside its scope
Both of these flaws can be mitigated if the ability to do these things is closely-held and not available to all code.
It's true that object-capability languages like E, Monte, Pony, etc. cannot stop you from writing bad code. But they can automatically prove that your code only is as bad as it appears to be, and not any worse via skulduggery.
Standard inbound firewall rules will not protect against this because the Antminer makes outbound connections.