BitcoinPool.com open thread

[xenon481]

http://www.bitcoinpool.com/forum/viewtopic.php?f=1&t=5

Some people aren't getting paid in certain blocks? I'm definitively stopping mining there! First "malicious attacks" against them and now they don't pay on certain blocks? too fishy for me

So people don't have to read the whole thread over there:

Actually, I've created a spreadsheet and tracked it down to two blocks that I have not received payment for. They are blocks 116105 and 116455. It would be nice if the site could show payment history per user per block. (Only under users login of course...) Although, I don't mind keeping my own books. I checked my wallet id's against block explorer and confirmed the transactions did not take place. Any help would be appreciated.

DaFish

I see that you were in fact not paid for block 116105, and I'll manually issue that payment to you.

However, for block 116455 I see the following in both our database, and bitcoin debug log:

Amount
2.56639874

Block
116455

UTC Timestamp
1301876564

How in the world was one user not paid for one of the blocks?

[1714909455]

1714909455

[1714909455]

1714909455

[shackleford]

How in the world was one user not paid for one of the blocks?

I guess since they say it is beta I am not surprised, but I will say that I really like how they have all their information available and does not feel like a black box. I would bet things like this happen on other pools but  good luck tracking it down. They seem honest.

Regan: Trust but verify (if you can)

[nster]

I like deepbit better as everything is in the open now with the history and stuff

[slush]

How in the world was one user not paid for one of the blocks?

Have to say that I had hard times with pool payouts, too, so I understand bitcoinpool troubles. Fortunately I'm excessive logging everything, so when bitcoind crashed during payouts (but json results for 'send' commands  were True), I had everything needed to reconstruct all accounts to consistent state.

Depends just on programmer's experience if he covered also very unlikely states of application and if he can recover crash without losing someone's money...

[xenon481]

How in the world was one user not paid for one of the blocks?

Have to say that I had hard times with pool payouts, too, so I understand bitcoinpool troubles. Fortunately I'm excessive logging everything, so when bitcoind crashed during payouts (but json results for 'send' commands  were True), I had everything needed to reconstruct all accounts to consistent state.

Depends just on programmer's experience if he covered also very unlikely states of application and if he can recover crash without losing someone's money...

I can understand the pool messing up for an entire block or for like the last half of the block or something like that. But only one user out of the entire pool not getting paid for a block?

I guess my concern is that it feels like the problem is likely to be much more widespread than has been identified so far.

[cdhowie]

I can understand the pool messing up for an entire block or for like the last half of the block or something like that. But only one user out of the entire pool not getting paid for a block?

I guess my concern is that it feels like the problem is likely to be much more widespread than has been identified so far.

I appear to be missing payments for some blocks too, and have been in contact with the admins about it.  Unfortunately I don't log very much, so I don't have a lot of useful info to give them other than "my historical balance on your site is larger than my payout to date" but I suspect that it may have been the same block(s) that we didn't get paid for.

[grndzero]

 I have been watching mine like a hawk since I started mining just over a week ago and haven't had any problems with payouts except for when they were frozen due to the attacks, and has been resolved.

 Being an admin. It's not really fair to hold DDOS attacks against them. The only reason it would be justified to hold the recent breach against them is if it was gross neglect (which I don't think it was). Even the best admins can't stop someone if they really want to get into a system.

[bobR]

I have been watching mine like a hawk since I started mining just over a week ago and haven't had any problems with payouts except for when they were frozen due to the attacks, and has been resolved.

 Being an admin. It's not really fair to hold DDOS attacks against them. The only reason it would be justified to hold the recent breach against them is if it was gross neglect (which I don't think it was). Even the best admins can't stop someone if they really want to get into a system.

here here I agree
lest we feed the trolls & their nonsense

[slush]

It's not really fair to hold DDOS attacks against them.

Every significant pool faced massive DoS attack already. I think operators should be happy that their pool is significant enough that somebody is trying to shut it down .

Even the best admins can't stop someone if they really want to get into a system.

How so? I think that it's pretty easy to _hurt_ some system (for example by DoS), but full system hack it is pretty complicated when you keep some basic rules while programming.

[grndzero]

Every significant pool faced massive DoS attack already. I think operators should be happy that their pool is significant enough that somebody is trying to shut it down .

Agreed

We originally stored everything in plaintext for compatibility with some miners. This was also prior to us adding any account modification tools to the site.

No doubt clients started out with someone, or a few people, hacking some code together and came up with a client. There's at least 1 example on here that I've seen of someone creating a from scratch client. Not many people start out writing their software from a security perspective. Most start out just to make something that works, then optimize it. Security is very often an after thought. Once the pools opened and people started using clients it's hard to change that. How many pool operators are willing to upset the status quo and change the security model of their pool and make people upgrade to a "Secure!" client. Mass conversions are hard when you know all the people involved, nevermind a loose association of people such as mining clients. Someone may be able to code a backward compatible security model into the server, but unless you force people to upgrade not all of them will, and as long as the old model still exists the problem will be there.

Even the best admins can't stop someone if they really want to get into a system.

How so? I think that it's pretty easy to _hurt_ some system (for example by DoS), but full system hack it is pretty complicated when you keep some basic rules while programming.

Unless you write every line of code yourself you are trusting other people to follow those rules to the level that you think they need to be followed, and many people's definitions vary (especially in the free/open source software community). Simple services can have hundreds of lines of code behind them. Even if all the rules and accepted practices are followed it doesn't mean that someone can't find a way to subvert them and create an exploit.

In their case it was a SQL. No matter which SQL server you are using, it's most likely that you wrote little, if any, code that is running on it. SQL query and security issues are constantly being found and addressed for every SQL vendor. SQL is a pretty big software app with a lot of lines of code and marketing is driven on speed. Very few SQL vendors care to advertise their security in depth unless you're Larry Ellison and willing to make a fool of yourself on stage then have Marketing scramble to CYA.

Secure and Security are precesses, not states.

[xenon481]

SQL query and security issues are constantly being found and addressed for every SQL vendor.

Their issue was not with a vulnerability within their DB vendor, it was a SQL Injection problem. SQL Injection vulnerabilities are caused by websites not sanitizing their inputs. You can solve this with a singular change that is global to the entire website that simply places escape characters around any potentially dangerous characters in input strings. This is something that every web page should ALWAYS do. Many web platforms have an option to automatically do this for you.

[bombo999]

+1

[slush]

Once the pools opened and people started using clients it's hard to change that.

That's why I introduced separate credentials for account and for workers. Sending plaintext credentials for full account access with getwork request is simply crazy (I mean this globally, I even don't know if bitcoinpool.com use the same password for account and for workers).

With separate credentials for getwork calls, things are quite safe. I don't know any significant type of attack which can be done by stolen getwork password.

In their case it was a SQL. No matter which SQL server you are using, it's most likely that you wrote little, if any, code that is running on it. SQL query and security issues are constantly being found and addressed for every SQL vendor.

Well, I don't have enough info, but most likely the attack was targeted to wrong escaping or handling of sql statements in application itself than exploiting some bug directly in sql server (probably mysql). Bitcoinpool is using native mysql binding for php (mysql_*) and escaping sql manually; it's pretty easy to make a mistake here.

Of course I didn't read complete software stack which I'm using, but you can avoid pretty much common mistakes with using well tested high-level libraries (like ORM, libraries for sanitizing input data, ...) than writing it by self. I read megabytes of source codes (mostly in PHP) from programmers who like to 'do everything under their control' (=don't use high level frameworks) and it's sometimes crazy how easily people are making huge holes to their systems .

[dbitcoin]

We originally stored everything in plaintext for compatibility with some miners. This was also prior to us adding any account modification tools to the site.

No doubt clients started out with someone, or a few people, hacking some code together and came up with a client. There's at least 1 example on here that I've seen of someone creating a from scratch client. Not many people start out writing their software from a security perspective. Most start out just to make something that works, then optimize it. Security is very often an after thought. Once the pools opened and people started using clients it's hard to change that. How many pool operators are willing to upset the status quo and change the security model of their pool and make people upgrade to a "Secure!" client. Mass conversions are hard when you know all the people involved, nevermind a loose association of people such as mining clients. Someone may be able to code a backward compatible security model into the server, but unless you force people to upgrade not all of them will, and as long as the old model still exists the problem will be there.

Miner clients code do not related to pool frontend and backend software in term of security.
Passwords and user from miner client used only for user identification for submitted share.
There is no one reason (besides laziness) for hold plain text passwords for user accounts, or reuse the same password and name for user account.

Unless you write every line of code yourself you are trusting other people to follow those rules to the level that you think they need to be followed, and many people's definitions vary (especially in the free/open source software community). Simple services can have hundreds of lines of code behind them. Even if all the rules and accepted practices are followed it doesn't mean that someone can't find a way to subvert them and create an exploit.

In their case it was a SQL. No matter which SQL server you are using, it's most likely that you wrote little, if any, code that is running on it. SQL query and security issues are constantly being found and addressed for every SQL vendor. SQL is a pretty big software app with a lot of lines of code and marketing is driven on speed. Very few SQL vendors care to advertise their security in depth unless you're Larry Ellison and willing to make a fool of yourself on stage then have Marketing scramble to CYA.

Secure and Security are precesses, not states.

Actually all normal programmers do not use raw sql queries with unescaped input from end user at least 7 years (if not more).
Only very lazy or naive "programmers" continue use this shit.

[cdhowie]

Their issue was not with a vulnerability within their DB vendor, it was a SQL Injection problem. SQL Injection vulnerabilities are caused by websites not sanitizing their inputs. You can solve this with a singular change that is global to the entire website that simply places escape characters around any potentially dangerous characters in input strings. This is something that every web page should ALWAYS do. Many web platforms have an option to automatically do this for you.

If you are referring to, for example, PHP's magic_quotes options then -- NO.  Those kind of options should never, ever be trusted.  They are not locale-aware (and therefore still vulnerable to injection attacks in some circumstances) and can corrupt your data if you're not careful.

Additionally, this would be the wrong place to perform such sanitation.  You should sanitize and escape values before they are used in whatever context you are using them.  For example, magic_quotes will protect against some (yes, some, not all!) SQL injection attacks.  But it will not stop XSS or the like.  SQL-escape user data before it enters the DB, not before it enters the entire script.  HTML-escape user data before you render it to a browser.  Etc.

A better option would be to use parametrized queries, which are by definition invulnerable to SQL injection attacks if the DB itself supports them, since the parameters are sent after the query has already been parsed.

[jgarzik]

A better option would be to use parametrized queries, which are by definition invulnerable to SQL injection attacks if the DB itself supports them, since the parameters are sent after the query has already been parsed.

Unfortunately the widely used Mysql C API does not support parameterized queries AFAICS.

[cdhowie]

Unfortunately the widely used Mysql C API does not support parameterized queries AFAICS.

It does, via mysql_stmt_prepare(), mysql_stmt_bind_param(), and mysql_stmt_execute().  The basic steps are: prepare the query (this is where the query itself is parsed), bind the parameters you take in the query, then execute the query.  This illustrates that the user-supplied data is sent to the server after the query structure is known, thereby preventing all forms of SQL injection.  (But not ensuring data integrity, of course.)

[jgarzik]

Unfortunately the widely used Mysql C API does not support parameterized queries AFAICS.

It does

That's useful, thanks.  I was looking at this page, and assumed that the "C API Function Descriptions" was a full and comprehensive list.

I use bound params with sqlite and postgresql already, but [mistakenly] thought mysql lacked same.

* jgarzik goes to update his just-written code...

[geebus]

Anything posted in this thread, by anyone other than myself or FairUser should be considered pure speculation or heresay.

We opened our own forum to address issues on our pool and from this point forward, we will not participate in any discussion posted to this forum.

You can join our forum at http://www.bitcoinpool.com/forum

And a note to slush... Unless you've audited our site through attempted attacks, or looked at our code directly through successful attacks, you don't know how our site, or pool is coded, and should not comment on it.

[xenon481]

A FairUser post from BitcoinPool's forum: (emphasis added)

[...] If that 90% of the getwork you missed contained the answer for the block, chances are you will not (1) find it and (2) get another getwork that contains the answer for the block for several days.

It is in your best interest and the pools for you to be efficiently mining. Please fix your problems before you continue mining in this pool. If you have a problem with that, then go be inefficient in different pool (cause it helps us when you do ;-).

From the first portion's (2), it is apparent that FairUser still does not understand probability when it comes to mining. Either that, or he is purposefully spinning things to seem bad. Not finding a valid solution does not have any effect upon the probability of when you will find a valid solution.

And the 2nd part...... That's a great way to treat people that are contributing to you. What was that about gift horses and mouths?