Quote from: phzi on March 28, 2014, 01:22:25 AM

Quote from: comeonalready on March 27, 2014, 03:33:11 PM

Where do you think that client.reconnect command originated anyway? It was not sent by your legitimate stratum servers, that's for sure. And not just anyone can send it, it must arrive on your open stratum connection, or forged to look like it, in order to be processed. Or the attacker must have been able to break your active stratum connection, or wait for it to break naturally, and then redirect you to a rogue server in order to send you that client.reconnect command.

I watched the attack occur and did some analysis (apparently unlike yourself?), and I don't believe there was any prior 'redirect' to a rogue server. My prior comments are more then just speculation... The client.reconnect command appeared to come from the legitimate stratum server. Aka, was "forged to look like it" as you suggest above. I explained above in reasonable detail exactly how such an attack could be potentially replicated. Go try it yourself if you have enough knowledge.

The only other attack method I can imagine based on what I observed, would be TCP injection at (a) key router(s) (by modifying packets and re-calculating header checksums). But, I highly doubt this is the case (else it probably would have been more wide-spread).

I can also assure you that it is still possible at this moment to capture the TCP headers of traffic destined for other servers on OVH right now - more complicated then it was a few months ago since they have been patching their switches, but still possible. The TCP header of course contains the miner IP, port, and current TCP sequence number - which, given the right setup, would be sufficient to counterfeit a packet from the stratum server. You might want to read about TCP injection attacks relating to TCP sequence prediction, if you were not aware this is possible: http://en.wikipedia.org/wiki/TCP_sequence_prediction_attack

FYI: I don't talk about things I am not knowledgeable about. I have nothing to prove (obviously unlike yourself), but I can assure you my knowledge of networking is higher then you might like to believe.

Quote from: comeonalready on March 27, 2014, 04:43:10 PM

Quote from: Undone on March 27, 2014, 04:39:23 PM

What/where is this patch?

It is not a complete solution, but it does help to a degree, if the next attack mirrors the previous one. Client.reconnect commands were included in the stratum mining protocol for a reason. The 'patch' to which you are referring is built into the latest versions of kalroth cgminer and veox sgminer. Just check their docs for use of no-client-reconnect option. But be forewarned, some pools might legitimately utilize the command, either now or in the future, so to enable it could break certain functionality. But poolwaffle has stated that he does not ever use it, so safe to use here.

It is a complete solution tho... If a pool wants to re-direct my miners somewhere else before the pool goes offline or something, I don't care - that's what fail-overs are for. There is no overly useful case for Client.reconnect that I can imagine. The stratum commands client.reconnect and client.get_version were added to cgminer in v2.8.2, as an aside.

In the copy of sgminer I am running, I simply disabled the client.reconnect ability entirely. Was a 5 second patch.

The reason Slush added client.reconnect to the protocol, btw:

Quote from: slush on September 12, 2012, 10:15:34 PM

* Implemented method client.reconnect(host, port), so pool can now easily balance clients between backends or gracefully shutdown a backend without a miner outage.

You are missing the point completely and if you cannot imagine another attack scenario, then your imagination is limited. If you happen to look back through this thread, you will find that I was the first to suggest that client.reconnect was being used as part of the attack. And if you look closely, you will find that I spelled out the exact potential attack scenario that you are preaching as gospel, and ironically enough now "teaching" me how it could be carried out. And also that mostly all of the ideas you presented as your own were only summaries of ideas that others had posted here before you -- with the notable exceptions of your misconceptions, that is.

It is all in the thread history. I am not going to correct your errors, as you can continue to believe whatever it is you wish to believe, but I am only posting this response as an advisory to others not to place too much value in your "facts", as some of them are only your opinions, misconceived as a result of misinterpreting relevant details. Simply stated, you are drawing false conclusions from an incomplete set of actual facts.

Quote from: phzi on March 28, 2014, 01:22:25 AM

FYI: I don't talk about things I am not knowledgeable about. I have nothing to prove (obviously unlike yourself), but I can assure you my knowledge of networking is higher then you might like to believe.

Really? If you're going to claim that you have nothing to prove, then why try to point out "your knowledge" before the very same sentence containing that claim even ends? This is the reason that I included some relevant wisdom from Hawking in my earlier reply. You're funny -- as in you amuse me like a clown, for those readers here who are fans of Joe Pesci in Goodfellas.