Browse Source

changelog: update 0.33.6 (#5075)

## Description

update changelog on master and bump version

Closes: #XXX
pull/5077/head
Marko 4 years ago
committed by GitHub
parent
commit
f508459d80
No known key found for this signature in database GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 62 additions and 2 deletions
  1. +60
    -0
      CHANGELOG.md
  2. +1
    -1
      CHANGELOG_PENDING.md
  3. +1
    -1
      version/version.go

+ 60
- 0
CHANGELOG.md View File

@ -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
- 1
CHANGELOG_PENDING.md View File

@ -1,4 +1,4 @@
## v0.33.6
## v0.33.7
\*\*


+ 1
- 1
version/version.go View File

@ -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"


Loading…
Cancel
Save