Bitcoin Exploit
twitter.com
twitter.com
This is a big nothing-burger. The "attacker" has to actively sustain downloading the data being requested. No amplification, no anything making it anything but a nuisance. Just a lamer that discovered that they can keep making requests in a loop in a Python script.
Sure, some per-IP rate-limiting might be desirable there (but has to be balanced against new nodes being able to download the history), but any service exposing data on the public Internet can be DDoSed by just making requests to it from multiple IPs, and that's why so many companies hide behind Cloudflare.
The total rate limiting seems to be already implemented: https://notatether.com/academy/how-to-limit-bandwidth-of-bit...
This "attack" might rake some fees on people hosting public nodes in the cloud (just like about any http server, S3 bucket etc.), but that's about it. Lots of nodes don't accept incoming connections, communicate via Tor, network relays, etc. so this has absolutely no chance of making any dent in the network as a whole.
It's normal for a node to request headers in chunks of 2000, either as part of syncing the entire chain from scratch, or when catching up after being offline for more than two weeks.
https://github.com/bitcoin/bitcoin/blob/fc06881f13495154c888...
It's not the most efficient (asymmetric) way to waste bandwidth either. For each ~100 byte header request you get a 160 KB reply. You can instead ask for a block using a shorter message and get up to 4 MB. This way you can download the entire blockchain at 500+ GB multiple times.
Those with limited upload bandwidth (and for some reason not behind a NAT) can use -maxuploadtarget to limit the total upload.
I'm not sure how the available bandwidth is distributed between peers, but it's generally quite hard to dominate all connections of all nodes (search for "eclipse attacks"), even with a botnet [0].
So that leaves CPU draining as a possible goal (or stealing Bitcoin from random script kiddies who run untrusted code and dependencies from the internet).
[0] = which isn't free, probably not their most economic use case and some of their operators may not like it when you attack a cryptocurrency they themselves may want to use
not theoretical https://github.com/dogecoin/dogecoin/issues/3243 - i've attacked several of my own nodes. anyone could launch a botnet against the actual network
>to cause a specific target networked Bitcoin node to consume quite a bit of bandwidth by returning blockchain data to the attacker.
correct
>It doesn't seem like this would have any effect on the Bitcoin network at large
until a botnet or botnets make huge swaths of the mining network unprofitable https://bitnodes.io/nodes/#networks-tab
>While I don't doubt that there exists an obscure client vulnerability that could be patched, it seems far-fetched and alarmist to categorise this as a "bitcoin exploit".
it meets all of the criteria to be called, bluntly, a remote financial attack/exploit that much of the network is vulnerable to
If you think this is a real vulnerability I'd suggest you report it to any project like that, a proof of concept exploit would basically involve curl in a while loop with the output going to /dev/null.
Here's an incomplete list of applications that should also have this vulnerability that you can start going through: https://en.wikipedia.org/wiki/Comparison_of_web_server_softw...
Bitcoin mining rigs don't even use bitcoin p2p protocol themselves, they typically use stratum protocol(https://braiins.com/stratum-v1/docs) and don't accept incoming connections from the public internet generally. They usually connect to mining pool servers which have long had various forms of ddos attack mitigation systems in place.
> if this was a non-issue they wouldn't be patching it https://github.com/dogecoin/dogecoin/issues/3243
They added an integrated basic bandwidth limiter from the looks of it, one can do something like that using external tools already. Hardly a real vulnerability.
Bulk header requesting is used as part of the initial block download, that's literally how it's designed to work: https://developer.bitcoin.org/devguide/p2p_network.html#head...
> while you make some valid points - i find it humorous that you have tasked yourself with defining what constitutes a security vulnerability.
Pretty much every internet connected service can be attacked with various forms of volumetric denial of service attacks, there are many mitigation measures available, you've implemented the bitcoin p2p protocol attack equivalent of curl in a while loop, that's not really something one would typically consider to be a real vulnerability.
> furthermore - you may want to examine https://bitnodes.io/nodes/ and come to a realistic figure of how many machines running bitcoind aren't accepting tcp/8333 from 0.0.0.0
First of all it's trivial to create fake nodes that show up on sites like that so I wouldn't really trust the numbers there, also it's easy for bitcoin users to add more real nodes if/when needed due to an attack, similar to how one can add more cloud application servers when there is a load increase or ddos attack on a web service the bitcoin network can add nodes if/when there is a need to mitigate these types of attacks.
As far as I can tell, nobody is claiming it's a 'non-issue'. Rather, it's a minor issue with an impact that is greatly exaggerated or sensationalised by the person reporting it.
until, again, a botnet makes huge swaths of the bitcoin network unprofitable.
this is computer science - not how you feel about or faultily interpret an exploit.
You seem to be mixing up bitcoin nodes and bitcoin miners.
Mining pools don't typically expose tcp/8333 in a way that makes it easy for them to be targeted and when they do they typically have redundant nodes and other mitigation measures in place to ensure reliability.
There have additionally been high speed optimized block relay networks used in the past by mining pools, although I don't think they are used anymore due to the public p2p network being much faster and more reliable than in the past due to various protocol improvements.