4 ms·

> CVE-2018-1000891 – Uncontrolled resource consumption when receiving messages with invalid checksums This is really just a bandwidth DoS, which no client can

> CVE-2018-1000891 – Uncontrolled resource consumption when receiving messages with invalid checksums This is really just a bandwidth DoS, which no client can protect against. > CVE-2018-1000892 – Uncontrolled resource consumption when receiving sendheaders messages This is really just a bandwidth DoS, which no client can protect against. > CVE-2018-1000893 – Uncontrolled resource consumption when deserializing transactions This is why the buffer is smaller in bitcoin than in these scamcoins. Edit: Seems I made the scammers mad.

Erlich_Bachman 8y ago
> This is really just a bandwidth DoS, which no client can protect against. Couldn't the client just find and blacklist misbehaving nodes? (Which Bitcoin already does, right?)
- nullc 8y ago
  > Couldn't the client just find and blacklist misbehaving nodes? (Which Bitcoin already does, right?) That particular report is essentially "if you send a message with an invalid checksum, the peer just ignores the message and carries on instead of banning you and thereby wastes bandwidth and cpu time". But this is kind of a pointless report (of a sort all too often produced by paid auditors :( ) -- the same "attacker" can simply send the same messages with a _valid_ checksum at no more cost to them, using the same resources, but totally bypassing the ban. So why bother? There may be good or bad reasons to disconnect or ban a peer that does something incorrect or unexpected-- depending on the nature of the incorrect action--, but bans that can be evaded by sending one constant instead of another with the same resource usage are not useful protections against denial of service. A downside of this particular ban is that you'll ban hosts that are guilty of the crime of being behind an overactive NAT or idiotic censorware proxy... [In fact, a lot of the motivation of the checksum is simply to avoid inappropriately banning peers whos messages were invalid simply due to the network corrupting their traffic. Banning on an invalid checksum defeats much of the purpose of the checksum in the first place.] Bitcoin is moving away from bans more or less completely because of their minimal utility (over otherwise necessary anti-isolation handling) compared to the amount that they amplify the negative effects of simple misconfigration (or even, have themselves resulted in attacks). The earlier poster's comment about bandwidth usage attacks is probably referring to the fact that no matter what your bitcoin software does a third party can still chew up inbound bandwidth by e.g. sending ICMP echo requests, SYNs, etc.
- wyldfire 8y ago
  Not resilient against Sybil attack but might help mitigate poorly executed DoS.
JeremyBanks 8y ago
What makes you think it's a bandwidth DoS (and therefore unprotectable)? The vague description sound more like the program is using excessive resources to handle certain messages, which reminds me of the hash algorithm collision DoSs, which weren't just bandwidth attacks. Do you know more details? Calling it "scamcoin" without explaining anything just makes you seem uncredible. If you have information, please share it instead.
- nullc 8y ago
  "Bitcoin SV" is the cryptocurrency created and promoted by a well known conman, Craig Wright ( https://en.bitcoin.it/wiki/Craig_Wright https://en.bitcoin.it/wiki/Craig_Wright ), who has earned the ire of the Bitcoin community by, among many other things, fraudulently claiming to be the creator of Bitcoin. More recently his creation of an incompatible competing clone of Bitcoin and calling it the confusingly similar name "Bitcoin Satoshi's Vision" has only furthered that irritation. It's great and well appreciated that their development staff followed a good procedure with these reports (even though the reports weren't terribly interesting in this case), but that in no way excuses or validates the underlying fraudulent actions.
  - JeremyBanks 8y ago
    Craig Wright sounds like an ass. That doesn't help me understand why the poster was claiming these issues are irrelevant.
    - pstrateman 8y ago
      They describe issues fundamental to any software accepting remote connections from untrusted peers, ie they are entirely irrelevant.
    - nullc 8y ago
      You asked why he called that cryptocurrency a scam, -- you have your answer. :) He did not call it a scam due to the reports themselves, he addressed their merits individually.
- 8y ago
narcissus 8y ago
"This is why the buffer is smaller in bitcoin than in these scamcoins." Are you saying that the buffer is smaller in Bitcoin because of that CVE issue? As in, the issue was discovered and the solution was the make the buffer smaller, instead of resolving the issue correctly? Because reading that article seems to imply, at least, that core is affected that issue or am I reading that wrong? Or do you mean something like "lucky the buffer is smaller in core"? Saying that 'something is why something else' reads like that something else is what caused the something, and like I say, I find it hard to believe that the solution to that CVE was "forget fixing the actual problem, we'll just make the buffer smaller"...
- nullc 8y ago
  The buffers in Bitcoin were specifically sized in response to known vulnerabilities long ago, some of which have been reintroduced by clones. Appropriately sizing buffers is the correct fix in some cases... For example, when the vulnerability is that an attacker can make N connections and begin N max_size messages, causing the allocation of N*max_size ram a perfectly reasonable fix is making sure that the protocol guarantees that the maximum size of any single message is small enough that decoding N in parallel isn't an issue.
  - narcissus 8y ago
    That's fair... I was completely misunderstanding the problem. So is it that core is not affected by that last CVE at all, or just not as much as the others?
    - nullc 8y ago
      > So is it that core is not affected by that last CVE at all Not at all. "re: deserialization memory allocation: as should be obvious from the code snippet in the report, the Unersialize_impl function for vector types does not allocate more than 5MB at a time, instead ensuring the input stream has the neccessary amount of data to fill the allocation first. Thus, this function will never allocate (materially) more than the input stream, which in this case is limited by the maximum message size. In the case of Bitcoin Core this is limited to around 4MB, though again, I understand Bitcoin SV has significantly increased this limit. Thanks again for the report!"
dguido 8y ago
Hello, CEO of Trail of Bits here -- we performed the security review of the Bitcoin Cash / Bitcoin SV code. Your characterization of the issues as "bandwidth denial of service" is incorrect and does not properly describe the impact. The most significant findings in our report detail ways for messages to waste a victim’s CPU and network resources without triggering any of the denial-of-service mitigations that normally detect and ban misbehaving peers. We also discovered a variety of edge cases that enable similar denial of service potential where exploitation was not straightforward. These included specific code security issues. (I'm being intentionally vague, sorry) The plan is to fully disclose our entire report at some point in the future, when the remainder of the Bitcoin clients have more fully implemented our recommendations.
- pstrateman 8y ago
  Can you stop forward progress? I already know you cannot because I did the work to prevent a malicious peer sending nonsense from doing that.

Erlich_Bachman 8y ago

> This is really just a bandwidth DoS, which no client can protect against. Couldn't the client just find and blacklist misbehaving nodes? (Which Bitcoin already does, right?)

nullc 8y ago
> Couldn't the client just find and blacklist misbehaving nodes? (Which Bitcoin already does, right?) That particular report is essentially "if you send a message with an invalid checksum, the peer just ignores the message and carries on instead of banning you and thereby wastes bandwidth and cpu time". But this is kind of a pointless report (of a sort all too often produced by paid auditors :( ) -- the same "attacker" can simply send the same messages with a _valid_ checksum at no more cost to them, using the same resources, but totally bypassing the ban. So why bother? There may be good or bad reasons to disconnect or ban a peer that does something incorrect or unexpected-- depending on the nature of the incorrect action--, but bans that can be evaded by sending one constant instead of another with the same resource usage are not useful protections against denial of service. A downside of this particular ban is that you'll ban hosts that are guilty of the crime of being behind an overactive NAT or idiotic censorware proxy... [In fact, a lot of the motivation of the checksum is simply to avoid inappropriately banning peers whos messages were invalid simply due to the network corrupting their traffic. Banning on an invalid checksum defeats much of the purpose of the checksum in the first place.] Bitcoin is moving away from bans more or less completely because of their minimal utility (over otherwise necessary anti-isolation handling) compared to the amount that they amplify the negative effects of simple misconfigration (or even, have themselves resulted in attacks). The earlier poster's comment about bandwidth usage attacks is probably referring to the fact that no matter what your bitcoin software does a third party can still chew up inbound bandwidth by e.g. sending ICMP echo requests, SYNs, etc.
wyldfire 8y ago
Not resilient against Sybil attack but might help mitigate poorly executed DoS.

JeremyBanks 8y ago

What makes you think it's a bandwidth DoS (and therefore unprotectable)? The vague description sound more like the program is using excessive resources to handle certain messages, which reminds me of the hash algorithm collision DoSs, which weren't just bandwidth attacks. Do you know more details? Calling it "scamcoin" without explaining anything just makes you seem uncredible. If you have information, please share it instead.

nullc 8y ago
"Bitcoin SV" is the cryptocurrency created and promoted by a well known conman, Craig Wright ( https://en.bitcoin.it/wiki/Craig_Wright https://en.bitcoin.it/wiki/Craig_Wright ), who has earned the ire of the Bitcoin community by, among many other things, fraudulently claiming to be the creator of Bitcoin. More recently his creation of an incompatible competing clone of Bitcoin and calling it the confusingly similar name "Bitcoin Satoshi's Vision" has only furthered that irritation. It's great and well appreciated that their development staff followed a good procedure with these reports (even though the reports weren't terribly interesting in this case), but that in no way excuses or validates the underlying fraudulent actions.
- JeremyBanks 8y ago
  Craig Wright sounds like an ass. That doesn't help me understand why the poster was claiming these issues are irrelevant.
  - pstrateman 8y ago
    They describe issues fundamental to any software accepting remote connections from untrusted peers, ie they are entirely irrelevant.
  - nullc 8y ago
    You asked why he called that cryptocurrency a scam, -- you have your answer. :) He did not call it a scam due to the reports themselves, he addressed their merits individually.
8y ago

narcissus 8y ago

"This is why the buffer is smaller in bitcoin than in these scamcoins." Are you saying that the buffer is smaller in Bitcoin because of that CVE issue? As in, the issue was discovered and the solution was the make the buffer smaller, instead of resolving the issue correctly? Because reading that article seems to imply, at least, that core is affected that issue or am I reading that wrong? Or do you mean something like "lucky the buffer is smaller in core"? Saying that 'something is why something else' reads like that something else is what caused the something, and like I say, I find it hard to believe that the solution to that CVE was "forget fixing the actual problem, we'll just make the buffer smaller"...

nullc 8y ago
The buffers in Bitcoin were specifically sized in response to known vulnerabilities long ago, some of which have been reintroduced by clones. Appropriately sizing buffers is the correct fix in some cases... For example, when the vulnerability is that an attacker can make N connections and begin N max_size messages, causing the allocation of N*max_size ram a perfectly reasonable fix is making sure that the protocol guarantees that the maximum size of any single message is small enough that decoding N in parallel isn't an issue.
- narcissus 8y ago
  That's fair... I was completely misunderstanding the problem. So is it that core is not affected by that last CVE at all, or just not as much as the others?
  - nullc 8y ago
    > So is it that core is not affected by that last CVE at all Not at all. "re: deserialization memory allocation: as should be obvious from the code snippet in the report, the Unersialize_impl function for vector types does not allocate more than 5MB at a time, instead ensuring the input stream has the neccessary amount of data to fill the allocation first. Thus, this function will never allocate (materially) more than the input stream, which in this case is limited by the maximum message size. In the case of Bitcoin Core this is limited to around 4MB, though again, I understand Bitcoin SV has significantly increased this limit. Thanks again for the report!"

dguido 8y ago

Hello, CEO of Trail of Bits here -- we performed the security review of the Bitcoin Cash / Bitcoin SV code. Your characterization of the issues as "bandwidth denial of service" is incorrect and does not properly describe the impact. The most significant findings in our report detail ways for messages to waste a victim’s CPU and network resources without triggering any of the denial-of-service mitigations that normally detect and ban misbehaving peers. We also discovered a variety of edge cases that enable similar denial of service potential where exploitation was not straightforward. These included specific code security issues. (I'm being intentionally vague, sorry) The plan is to fully disclose our entire report at some point in the future, when the remainder of the Bitcoin clients have more fully implemented our recommendations.

pstrateman 8y ago
Can you stop forward progress? I already know you cannot because I did the work to prevent a malicious peer sending nonsense from doing that.