Hacker News new | past | comments | ask | show | jobs | submit login
Backdoor in the firmware of Antminer Bitcoin mining hardware (antbleed.com)
263 points by twowo on Apr 26, 2017 | hide | past | web | favorite | 118 comments

The hardware checks in with central bitmain servers to see if the hardware is "legitimate". The bitmain servers have to explicitly return false to disable the machines, which is really important because it means that the servers just being disabled (via a DDoS for example) will not shut down anyones systems.

That's why redirecting the traffic from "auth.minerlink.com" to point at "" 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.

We've had third party software systems fail before because they check into the vendor's system asking if they were authorized, the vendor at that same time had a database issue which caused it to return false for us, thus taking down all of our infrastructure reliant on that system.

So yeah, just because it explicitly looks for false doesn't mean it's a non-issue.

They are controlling a huge share of the hashing power themselves. If they kill all the ASICs that they produced but do not control themselves I think it is quite likely they would control over 50% of the hash power themselves. That is a nightmare scenario.

Yes. It'd also be interesting if there was a way to turn the hashers off and on intermittently (does it try again after receiving a "false"? don't feel like reading the code right now). This would be a good way to sell hardware but still preserve their control over hash power by causing devices to have some idle time, which means more blocks and shares from pools for themselves.

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]

[0] https://news.ycombinator.com/item?id=14040165

[1] https://news.ycombinator.com/item?id=14166820

"The power to destroy a thing is the absolute control over it." – Dune

"Plans within plans"


The workaround seems incredibly simple so I'm not sure it was nefarious but i would love to know what they thought it was for.

1 remote code execution on that server or on the DNS server or domain hijacking and Bitcoin takes a serious hit on social recognition.

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.

Someone noticed it in September, opened an issue, and got no response. https://github.com/bitmaintech/bmminer/issues/7

It also looks like the backdoor may have a remote code execution vulnerability: https://twitter.com/petertoddbtc/status/857340167400587264

Relevant source code:


Edit: Nobody cares about the vulnerability until it has a name and a logo :-)

An 8000+ line C file. I can understand how a single bug might be overlooked there.

It wasn't overlooked though. Issue was raised in Sept 2016


Or a single malicious "feature"...

It has a bug but it's only an out-of-bounds read, not a write. So you might be able to make it crash, but why would you want to? Crashing might make it reboot and continue mining. Instead, send "false\0" and it'll stop dead in its tracks.

Bitmain is not only the producer of those mining ASICs, it also controls a huge share of the mining power itself.

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.

Are you the same as "twowo" who posted this, but using a different username?

The Reddit thread on this seems somewhat evenly divided on whether this is a real issue: https://www.reddit.com/r/btc/comments/67qzsn/antbleed_exposi...

Surprising, as it seems like a straightforward, real issue.

I think that particular subreddit is being generous about the issue because they overwhelmingly support the Antminer manufacturer on a completely separate issue (increased block sizes). That issue is more-or-less the big schism at the moment between /r/btc and /r/bitcoin.

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...

The analogy helps a lot. Funny how that reality distortion field effect kicks in for something that seems obviously bad.

It appears that Antbleed is a proposed temporary denial of service attack.

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.

Why would Bitmain shut down their customers' hardware? It's a sure way to kill their (quite successful) brand.

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.

This comes into play in the event of a contentious hard fork. Since the miners send their MAC, the parent can look up the customer from sales records. If that customer is against the parent's position in the hard fork, they turn off their machines.

The "enemy" fork loses massive hash power at a critical moment.

It becomes a bigger issue just because that conflict is so infected. No room for honest mistakes, then.

If you are an affected miner, then you have a direct financial cost. This is also a motiviation for other miners to exploit this, as they can take advantage of the decreased difficulty to mine more blocks themselves.

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.

It might open a window allowing a large intact miner to double spend.

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.

Who is that "large intact miner"?

I didn't have a specific miner in thought while commenting, but in this instance it could be 1) a miner that does not use any bitmain equipment 2) a miner that uses bitmain equipment but has otherwise preemptively mitigated this attack vector or 3) Bitmain themselves acting maliciously.

Yeah, so can you name that mysterious miner? You can see the big ones here, for instance:


Which one is it?

I have absolutely zero insight into the security practices of bitcoin mining operations. I suspect at least some of them take it seriously considering the amount of money involved.

Bitmain themselves?

> Why would Bitmain shut down their customers' hardware?

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.

> That sort of mechanism doesn't build itself, though, so I have to imagine they have at least one scenario in mind...

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)

Much more likely IMHO is that it is a testing facility. When you are building equipment that is intended to work in a network mesh, being able to setup, tear down and simulate network problems quickly is important. It should never be in production code, but you know what engineers are like when they are pushed for deadlines.

>In the very worst case that will take 2016 blocks, or 14 days.

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.

I think you are wrong, blocks will not be mined 3 times slower just because the global hashrate dropped by 70%.

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.

No, it's not a race to a finish line, it's a race to find a random number that when placed in the block header hashes to a value that is less than the difficulty. The difficulty is adjusted as desdiv said above based on the network performance in the previous period. When network hashrate increases significantly, the next difficulty adjustment happens sooner and if the hashrate dropped dramatically then it would happen slower.

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.

It's not a race, it's a scavenger hunt. If you remove half of the searchers you'll take twice as long.

I don't think your runner analogy holds up, as the difficulty change essentially effects the global work required (lower chance of finding a suitable random value). It's more like measuring the total distance run by all runners - reaching the same total distance with less runners would take significantly longer.

When the difficulty is adjusted, the next difficulty adjustment is set to happen after the number of blocks the current hash rate will complete in two weeks. If the hash rate drops, it will take more than two weeks to adjust again.

If you can shut down up to 70% of the mining power, it would make mounting a 51% attack incredibly easy. It would also mean whoever controls the remaining mining power is in for a treat with block rewards for a while.

Whoever was left mining after that wouldn't get more block rewards unless it was something more extreme like bricking 70% of miners instead of just disabling them for a short amount of time. They would be able to mine 100% of blocks but there would be a lot more time between blocks until the next difficulty change. Unless it's something that would permanently break miners it wouldn't last long enough to earn the attackers anything extra in terms of extra blocks mined but facing congestion all blocks would be filled with extra high fee transactions so there would be some BTC to gain, but not from the normal block reward.

51% attack would require a collusion of the large group of the miners, and, if successful, will likely cause a massive price drop. Which is the last thing miners want.

P.S. And btw, it's >50% attack, not 51% attack. You don't need that whole extra percent.

> 51% attack would require a collusion of the large group of the miners

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.

There is no reason to think they would this is just another part of the long running smear campaign against Bitmain by a collective of Bitcoin Core developers calling themselves the "Dragon's Den" so called because that is the name of the slack chat room where they plan their character assassination campaigns against people and companies who disagree with them.

So you are saying "Dragon's Den" is responsible for the backdoor? How?

I'm saying they are responsible for the messaging and pushing this as some kind of evil plot. The Antminer firmware is opensource and has been on GitHub for anyone to inspect for quite sometime.

Why does it have to be Bitmain to shutdown the miners? How about a random hacker who gained control of that home server or the domain?

Shorting 100x before shutting them down sounds like a good incentives for those people.

Redirecting auth.minerlink.com to point at is not a permanent way to bypass the issue.

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.

>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.

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.

> you can attack the network by including illegitimate transactions in the blocks

This part is incorrect. Any block with an invalid transaction will be rejected by the rest of the network.

Right ... as long as you don't control "the rest of the network", which is what a 51% attack is.

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.

A 51% attack only beats out the other miners.

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.

OK, thanks for clarifying. Is this enforced client-side in the default client? What other types of validations are performed client-side? Where is the limit on the trace up the chain? You'd have to have a full clone of the blockchain to validate all the way up, or it'd terminate at the oldest block. I assume that even if you're one of the few still running a full chain these days, transactions in the block aren't checked against the coin's entire history. Does it reject/ignore the entire block or just the transactions for which it has a conflicting history?

Yes, the original client (Bitcoin Core) and some others enforce it, while others (Electrum) only rely on the proof-of-work, which of course is more risky, but acceptable for some users.

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.

First, to clarify, clients don't choose the longest chain; they choose the chain that took the most work to create. Someone could trivially create a new, longer chain with the genesis block at it's root and completely rewrite the transaction history, but since they can't trivially create blocks that prove more work (as in proof-of-work), no other clients would use that chain.

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 cannot rewrite or otherwise change transactions with a 51% attack, nor can you capture any bitcoin.

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.

With more than 50% you can reject all other blocks and keep the chain to yourself.

Yes you can. Rewriting a transaction is exactly what a double spend is.

Yes - for your own coins.

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.

Can someone explain why Bitmain controls such a large share of the global hashing power? Why can't competitors produce Bitcoin mining chips as good as Bitmain's? Is the case simply that Bitmain were first with 16nm-based miners, and when everyone else get there too, Bitmain will have no advantage left?

Why can't competitors produce Bitcoin mining chips as good as Bitmain's?

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.

There were many many other companies in the market 3 years ago but they all went bust because they all scammed their customers in one way or another. Antminer was the only one that didn't follow shady business practices that is the main reason they are still around. The reason a segment of the bitcoin world likes to hate on them is because they are an outspoken supporter of bigger blocks and bigger block threatens the business plan of certain non-mining interests.

> The reason a segment of the bitcoin world likes to hate on them is because they are an outspoken supporter of bigger blocks and bigger block threatens the business plan of certain non-mining interests.

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-...

> against the wishes

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.

Statement from the company: https://blog.bitmain.com/en/antminer-firmware-update-april-2...

tldr; Code left behind from abandoned feature implementation to allow owners to remotely shutdown miners that have been stolen/misappropriated. Our bad... sorry.

I wonder if YC would fund a new Bitcoin mining ASIC startup. I often regret not being able to pivot my previous company from FPGAs into ASICs :/

I'd love a bitcoin miner that doubles as a household heater. Imagine turning the heater on and making money from it. But it would need to look like a standard household heater, and operate as quietly as one too.

If you want to make one let me know, I'll happily be a tester for you!

There was http://www.bitheat.io/ but the project seems dead.

I hope not. From a business point of view, Bitcoin and hardware are both risky; putting the two together is exceptionally so. From an ethical point of view, the environmental impact of large-scale Bitcoin mining is a real problem.

> the environmental impact of large-scale Bitcoin mining is a real problem

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.

Alright, well, here's some math.

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.

Generally a house that isn't electrically heated or cooled uses 1 kWh per hour. So 380 megawatts for Bitcoin mining is the around the same amount of energy that 380,000 houses would use on a nice day.

Here's some numbers[0] from a study done by the Natuonal University of Ireland.

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...

Did you even read my comment? I literally mentioned that ridiculous study.

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?

Bitcoin mining has congregated around cheap sources of energy, In China at least, many are using surplus energy from the grid in cutprice deals with provincial govts.

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.

Those other activities produce something of value. A pure fiat currency like Bitcoin has no value other than the consensus: gold has a lower bound capped at industrial use and you could at least plant tulip bulbs but if people stop using Bitcoin or switch systems all of that effort will be wasted.

I'm not a VC, but I would assume the question is not whether a venture is risky or not, but whether it is worthwhile. All startups are exceptionally risky.

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.

We don't actually know how well Coinbase is doing just that they seem to still be regularly raising money and doing it from weird places.

After 21.co lit that mountain of money on fire trying to build their own miners, I doubt any investors will be too quick to follow suit..

Did 21.co try to build miners? I didn't pay _too_ much attention to them. All I heard was that they were trying to get mining cores into cellphones and their platform devices, so that the devices would have a passive stream of bitcoins with which to provide and access microservices.

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.

They spent a ton of cash building their own miners and mined something like 1,500 blocks:


The chips on devices thing was a pivot once their initial idea didn't work.

Their first business was mining with their own miners. And they moved a lot of blocks leading up to their jumbo round. They apparently hoped to use that chip set for the whole "an energy sink in every device" business plan which was obviously never going to work.

Sounds like maybe you have some existing IP that could be utilized.

What level of capital commitment would you need to build a proof of concept?

> Sounds like maybe you have some existing IP that could be utilized.

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.

As usual please make sure you link to github links directly.


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...

Never knew of that keyboard shortcut for GitHub.

Thanks for sharing.

Looks like they also took down auth.minerlink.com ... at least it doesn't resolve to anything for me.

It doesn't resolve yet. The idea is that they could set it up, thus activating the backdoor.

"Sell them coin-operated shovels that we can remotely disable". Until they get caught. Oops.

I'm not sure what's worse about this:

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.


>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.

> auth.minerlink.com

This is localhost.

> You can check if your Antminer is vulnerable to this attack by SSHing to the Antminer, and changing the /etc/hosts file on the device to include: auth.minerlink.com

This will cause the Antminer to connect to our test server

They admit that doing that redirection will make your miner shut down, that's basically worst case.

The main advantage i can see is that this provides an easy way of proving there really is a kill switch.

That's to test if you're affected, not suggested as a solution.

And a lot of people would test to know if they need to use the solution, don't they?

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.

You can install the fix no matter what, it's innocent. They should have offered source code for their test app instead, but that's definitely not malicious.

The test source code was made available here https://pastebin.com/2wd7GDTC.

>2. The fact that they're using "something" bleed as the name (creativity, please)

Seriously, it isn't even a data leak.

And someone took the time to register a domain and design the page and logo...

bleed is a nod to the vuln "heartbleed", not to leaks.

Incorrect, heartbleed caused leaks from the servers affected. This is not even vulnerability it's just a stupid design decision that someone can MitM.

This issue should have been called Ant-in-the-Middle.

That's actually a great name for it or something along the lines of killswitch. Maybe AntKill or MinerRaid.

Yes, and the "bleed" in "heartbleed" comes from the fact that data was being leaked (bleeding out).

Which leaked (bleed) core (heart) information.

Yes, it's interesting who made this site and why.


> Do people run their mining equipment connected directly to the internet?

Yes, it is quite common to have the ASIC connect directly to the mining pool servers (over TCP with the Stratum protocol).

It's interesting who made /r/btc and why.

It's interest who made this comment and why.

You would need to be MiTM to exploit that. This "backdoor" will have probably almost no effect, it's interesting that someone made special site just for it..

They haven't made it hard; the phone-home is unauthenticated, so you could just spoof someone's DNS for instance.

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.

As usual, this is a strong lesson for those who haven't considered capability-safe designs. A big pile of C carrying many libc calls is pretty hard to audit!

Bad and hard to grok code can be created in any language. Even more-so in languages that have more syntax complexity than C.

The point of capability-secure design is that it's possible to prove that a chunk of code, regardless of its nastiness, cannot take certain actions.

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.

This code is running on a dedicated Zynq SoC on the miner, where it's treated more as "firmware". Any capability based system running on this SoC would be designed by Bitmain, so they could just backdoor it as well. In addition, the software is required to make outgoing connections, for the stratum mining protocol.

Hard to grok was probably one of the main requirements in this case, so this whole sidebar doesn't mean much in this context. The writer of this code has no interest in safe or lucid.

  Standard inbound firewall rules will not protect against this because the Antminer makes outbound connections.
What kind of idiot doesn't have outbound firewall rules, particularly on their production mining network?

You'd need a bit more than a standard IP firewall since the auth server can simply be moved to a different IP address. The best way to truly block it would be to block it directly on the nameservers for the network.

The proper outbound firewall configuration would be default-deny with outbound connections allowed only to the hosts required. That way Antminer would have to somehow take over an IP address that was already whitelisted and run their auth server on it.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact