Vulnerability in pool server stratum implementation \[Quickfix for Pools In Here\]

vasp

Thank you coinotron. featherpool.ru fixed too.

justabitoftime

[quote name=“Nutnut” post=“22197” timestamp=“1374225914”]
[quote author=coinotron link=topic=2866.msg22191#msg22191 date=1374224781]
Hi

I’m operator of Coinotron pool.

I think I found vulnerability in the pool server stratum implementation which someone is actively using to block FTC pools.
Vulnerability causes pool to stop accepting any shares submitted by miners!
It is caused by different ways of verifying block time.

Featherclient does it like this :

[code]// Check timestamp
if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
return error(“CheckBlock() : block timestamp too far in the future”); [/code]

While stratum pool:

[code]if ntime > (self.timestamper.time() + 1000):[/code]

[url=https://github.com/viperaus/stratum-mining/commit/e760f30fa44dc58f4a478e87c444f10e83bebae3]https://github.com/viperaus/stratum-mining/commit/e760f30fa44dc58f4a478e87c444f10e83bebae3[/url]

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)

Quick fix is to change 1000 to 7200 in pool’s stratum code.
[/quote]

Thanks! Off to fix my stratum. :)

Edit: Fixed - Thanks coinotron. [url=http://ftc.nut2pool.com]ftc.nut2pool.com[/url] has stratum online again. :)
[/quote]

NutNut,

Please get word out to all our other mining partners.

svennand

FTC Pool Geek
FC Pool
D2 Pool
Give Me FTC

Has been notified.
If anyone run a pool please pm me your email adress so its easier to notify you about things like this.

ghostlander

[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.

coinotron

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.

gen

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.)

wrapper

Does this stratum vunerability affect Bitcoin and Litecoin? even with their hash power

flound1129

multipool was patched last night. You are free to mine FTC here on port 3337.

bigvern

fcpool.com stratum has been updated

BigVern

jeremiel

[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?

ghostlander

[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.

wrapper

[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?

ghostlander

[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.

groll

[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

ghostlander

[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]