@david just released a new version of grin 
.
New grin release with some important stability improvements: Release v5.4.0 · mimblewimble/grin · GitHub
Be sure to update since it contains some important stability improvements.
11 Likes
Awesome!
1 Like
just tested in almalinux and rocky linux 10 that can run grin without compiling
however, the PIBD issue not really solved, especially when node has several connected peers like 20 or more.
thank you, will take a look at PIBD later
1 Like
we can run ‘grin server config’ or ‘grin --testnet server config’ to generate config file in separate folder, then we can run them separately, however, unlike original binary grin, grim can’t run 2 instances at same time. or maybe configuration is different.
yes, there is a protection to not run 2 instance of GUI at same time with application socket, its also needed to open slatepack files and deeplinks with same instance.
1 Like
Release 5.4.0 in fact fixes some critical vulnerabilities (details of which will be made available in a week), so the update is mandatory.
A majority of hash power is already updated, and all exchanges have been notified.
11 Likes
You could make tGrim (or another name), a separate testnet configure version of Grim wallet to avoid conflicts and confusion by users while making it easy for them to play with tesnet.
You can select testnet at connection settings and use it separately without issues.
(Will add same selection at global settings, so nobody will miss it for sure).
2 Likes
A few more details:
3 vulnerabilities combine to let an attacker inflate the coin supply:
-
Unchecked return value:
commit_parse()inrust-secp256k1-zkpdiscards the C return value. Always returnsOk, even on invalid input. -
Uninitialized buffer: the output is
MaybeUninit::uninit().assume_init(). On parse failure, the buffer contains whatever was at that stack address. -
LLVM stack slot reuse: in release builds, LLVM inlines
commit_parseintocommit_sumand reuses the same stack slot across loop iterations. A failed parse silently inherits the previous valid result.
A miner plants 33 fake bytes as an output in a block. Later, another block spends both a real output (Coinbase or Plain, value v) and the ghost as inputs. commit_sum parses the real output first (writes EC point to stack slot), then parses the ghost (fails, slot unchanged). The input sum is computed as 2v. The attacker creates an output worth 2v that balances. The inflated output spends normally.
Full details will be made available later.
8 Likes
Given such a significant security vulnerability, does this mean that someone has carried out numerous such attacks and obtained a large amount of coins? After all, we cannot obtain the total amount of coins from the blockchain.
A full block history scan (using archive nodes) shows this exploit is only theoretical and has never been used. Additionally it only works on the Rust stack combining these three vulnerabilities and it requires the attacker toine a block. If someone would have tried this in real time, Grin++ nodes would have flagged those transactions and the block containing the ghost input as invalid.
5 Likes
This once again shows how important it is to have another client like Grin++ (thank you David!). And thank you to whoever discovered and reported this vulnerability. Looking forward to reading the detailed report.
6 Likes
There is always funding available for anyone who wants to make good contributions to grin, whether on the Rust, C++, Python or another code base.
2 Likes
so the native grin-wallet should be updated to align the bug fix of the node? i see last compile since 2024.
@hellogrin The grin rust wallet gets its blockchain information from the grin rust node, meaning the vulnerability and its fix only needed to be made in the grin rust node. Wallets/nodes that incorporate the grin rust node like Grim and grin node for Umbrel have been updated already.
If you use a wallet like IronBelly or Grim with remote node, make sure that remote node has updated. For example, https://grinnode.live/ nodes have been updated.
2 Likes
I noticed API of this node returns 502 error for certain IP addresses (looks like GeoIP blocking enabled here) @mcm-mike
Hi ardocrat,
can you try https://grinnode.live/v2/owner , like
curl -d '{"id":1,"jsonrpc":"2.0","method":"get_status","params":{} }' -o - -X POST https://grinnode.live/v2/owner
thx, it works without port (using 443), this block is actual for 3413 port.
Do you think if it’s a good idea for grin ecosystem to ‘fork’ to invalidate the old node versions?
So we will eliminate the potential vulnerabilities completely?