Vulnerability in pool server stratum implementation \[Quickfix for Pools In Here\]
-
[quote]1. Attacker is producing blocks with timestamps shifted 2 hours to the future
2. Getblocktemplate RPC used by all pools returns Block Templates with ntime shifted over 1 hour to the future.
3. Miners are submitting their shares with ntime based on Block Templates from the pool.
4. Pool doesn’t accept those shares because share ntime > (self.timestamper.time() + 1000)[/quote]Is it related to stratum only or getwork/getblocktemplate are also affected? Couldn’t find anything like this in libblkmaker.
-
I’ve found it in my pool code which is based on original Slush’s stratum pool. viperaus fork on github is also affected. Probably it is present in all Slush’s stratum forks.
Whether getwork pools are affected or not I don’t know. It all depends on implementation.
-
Hi, saw it happened about 10hours ago, it only affected stratum. the getwork pool was still accepting shares (in a pool that has both stratum and getwork.)
-
Does this stratum vunerability affect Bitcoin and Litecoin? even with their hash power
-
multipool was patched last night. You are free to mine FTC here on port 3337.
-
fcpool.com stratum has been updated
BigVern
-
[quote name=“wrapper0feather” post=“22285” timestamp=“1374261792”]
Does this stratum affect Bitcoin and Litecoin? even with their hash power
[/quote]Do you mean? Does this vulnerability affect all stratum based crypto currency pools?
-
[quote name=“d2” post=“22380” timestamp=“1374306737”]
Hi coinotron! Thanks for your input regarding this issue. While this solution will work temporarily, it surely isn’t an actual solution as the attacker can simply up the timestamp more to be outside of the adjusted window. Sadly, the only permanent solution will require more strict rules in the client with block chain handling. Regardless, thanks for your input and temporary solution!
[/quote]CheckBlock() in daemon/client rejects any blocks with time stamps 2 hours above system time. Hope we’ll reduce this value soon. This is Bitcoin legacy.
-
[quote]
“CheckBlock() in daemon/client rejects any blocks with time stamps 2 hours above system time. Hope we’ll reduce this value soon. This is Bitcoin legacy.” [/quote]Brilliant news about CheckBlock() - Why hasn’t my suggestion for temporal sequencing been implemented, I have already shown this only happens with attacks? This requires an urgent security fix.
I suggest no transaction should be more than 5min in the future! ( 2 * block time )
- This thread seems tied at the Top of the Forum, but is no longer current? Haven’t the stratum fixes been done by now?
-
[quote name=“wrapper0feather” post=“26069” timestamp=“1377163203”]
[quote]
“CheckBlock() in daemon/client rejects any blocks with time stamps 2 hours above system time. Hope we’ll reduce this value soon. This is Bitcoin legacy.” [/quote]Brilliant news about CheckBlock() - Why hasn’t my suggestion for temporal sequencing been implemented, I have already shown this only happens with attacks? This requires an urgent security fix.
I suggest no transaction should be more than 5min in the future! ( 2 * block time )
[/quote]No need to be extreme. 30 minutes is a safe bet.
-
[quote]No need to be extreme. 30 minutes is a safe bet.[/quote]
but time adjuted need to be lower then this it is actually 35 minutes. Else you can get attack that adjust time of clients to 35 minutes back than normal time block would be refuse by them. This require the attacker to get most of the connections of the client. This is possible, but difficult as you need to get many rogue clients in many subnet to do this. but we should play safe. the max future should be > time adjust allowed
-
[quote name=“groll” post=“26106” timestamp=“1377228042”]
[quote]No need to be extreme. 30 minutes is a safe bet.[/quote]
but time adjuted need to be lower then this it is actually 35 minutes. Else you can get attack that adjust time of clients to 35 minutes back than normal time block would be refuse by them. This require the attacker to get most of the connections of the client. This is possible, but difficult as you need to get many rogue clients in many subnet to do this. but we should play safe. the max future should be > time adjust allowed
[/quote]I’ve thought about it [url=http://forum.feathercoin.com/index.php?topic=2847.msg22378#msg22378]earlier[/url]. nTimeOffset needs to be decreased accordingly. 20 minutes may be fine. Bitcoin uses 70 minutes, Litecoin has had halved it to 35 minutes.
[code=“util.cpp”]// Only let other nodes change our time by so much
if (abs64(nMedian) < 35 * 60) // Feathercoin: changed maximum adjust to 35 mins to avoid letting peers change our time too much in case of an attack.
{
nTimeOffset = nMedian;
}
else
{
nTimeOffset = 0;
[/code]
