mirror of
https://github.com/tendermint/tendermint.git
synced 2026-01-10 23:10:59 +00:00
changelog: update 0.33.6 (#5075)
## Description update changelog on master and bump version Closes: #XXX
This commit is contained in:
60
CHANGELOG.md
60
CHANGELOG.md
@@ -1,5 +1,65 @@
|
||||
# Changelog
|
||||
|
||||
## v0.33.6
|
||||
|
||||
*July 2, 2020*
|
||||
|
||||
This security release fixes:
|
||||
|
||||
### Denial of service
|
||||
|
||||
Tendermint 0.33.0 and above allow block proposers to include signatures for the
|
||||
wrong block. This may happen naturally if you start a network, have it run for
|
||||
some time and restart it **without changing the chainID**. (It is a
|
||||
[misconfiguration](https://docs.tendermint.com/master/tendermint-core/using-tendermint.html)
|
||||
to reuse chainIDs.) Correct block proposers will accidentally include signatures
|
||||
for the wrong block if they see these signatures, and then commits won't validate,
|
||||
making all proposed blocks invalid. A malicious validator (even with a minimal
|
||||
amount of stake) can use this vulnerability to completely halt the network.
|
||||
|
||||
Tendermint 0.33.6 checks all the signatures are for the block with +2/3
|
||||
majority before creating a commit.
|
||||
|
||||
### False Witness
|
||||
|
||||
Tendermint 0.33.1 and above are no longer fully verifying commit signatures
|
||||
during block execution - they stop after +2/3. This means proposers can propose
|
||||
blocks that contain valid +2/3 signatures and then the rest of the signatures
|
||||
can be whatever they want. They can claim that all the other validators signed
|
||||
just by including a CommitSig with arbitrary signature data. While this doesn't
|
||||
seem to impact safety of Tendermint per se, it means that Commits may contain a
|
||||
lot of invalid data.
|
||||
|
||||
_This was already true of blocks, since they could include invalid txs filled
|
||||
with garbage, but in that case the application knew that they are invalid and
|
||||
could punish the proposer. But since applications didn't--and don't--
|
||||
verify commit signatures directly (they trust Tendermint to do that),
|
||||
they won't be able to detect it._
|
||||
|
||||
This can impact incentivization logic in the application that depends on the
|
||||
LastCommitInfo sent in BeginBlock, which includes which validators signed. For
|
||||
instance, Gaia incentivizes proposers with a bonus for including more than +2/3
|
||||
of the signatures. But a proposer can now claim that bonus just by including
|
||||
arbitrary data for the final -1/3 of validators without actually waiting for
|
||||
their signatures. There may be other tricks that can be played because of this.
|
||||
|
||||
Tendermint 0.33.6 verifies all the signatures during block execution.
|
||||
|
||||
_Please note that the light client does not check nil votes and exits as soon
|
||||
as 2/3+ of the signatures are checked._
|
||||
|
||||
**All clients are recommended to upgrade.**
|
||||
|
||||
Special thanks to @njmurarka at Bluzelle Networks for reporting this.
|
||||
|
||||
Friendly reminder, we have a [bug bounty
|
||||
program](https://hackerone.com/tendermint).
|
||||
|
||||
### SECURITY:
|
||||
|
||||
- [consensus] Do not allow signatures for a wrong block in commits (@ebuchman)
|
||||
- [consensus] Verify all the signatures during block execution (@melekes)
|
||||
|
||||
## v0.33.5
|
||||
|
||||
Special thanks to external contributors on this release: @tau3,
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
## v0.33.6
|
||||
## v0.33.7
|
||||
|
||||
\*\*
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ const (
|
||||
// Must be a string because scripts like dist.sh read this file.
|
||||
// XXX: Don't change the name of this variable or you will break
|
||||
// automation :)
|
||||
TMCoreSemVer = "0.33.5"
|
||||
TMCoreSemVer = "0.33.6"
|
||||
|
||||
// ABCISemVer is the semantic version of the ABCI library
|
||||
ABCISemVer = "0.17.0"
|
||||
|
||||
Reference in New Issue
Block a user