I think i found a relatively big problem in BOINC - Particularly for small projects . It can achieve data quorum from workunits from the same computersteemCreated with Sketch.

in gridcoin •  7 months ago

Proof :

https://boinc.multi-pool.info/latinsquares/workunit.php?wuid=3996272

https://boinc.multi-pool.info/latinsquares/workunit.php?wuid=3996277

https://boinc.multi-pool.info/latinsquares/workunit.php?wuid=3996278

This is a big deal because it allows a malicious attacker to get credit for fake results, and it can also feed the program bad data, false result happens with every hardware, if you have your cpu or gpu overclocked it can ramp up even further.

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

Boinc projects have two configuration flags intended to prevent users from validating their own work. See: Project Configuration

<one_result_per_user_per_wu/>
If set, send at most one instance of a given job to a given user. This increases the effectiveness of replication-based validation by making it more difficult for hackers to get all the instances of a given job.
<one_result_per_host_per_wu/>
If present, send at most one result of a given workunit to a given host. This is weaker than one_result_per_user_per_wu; it's useful if you're using homogeneous redundancy and most of the hosts of a particular class belong to a single user.

If either of these flags are omitted it is possible for a user to validate their own work which leaves the project open to potential abuse.
Project administrators may chose to allow either users or hosts to validate their own work during application testing especially when there are a very small number of hosts contributing to the project.
Any active project with a large number of users should have both of the above flags set to ensure the integrity of their results.

If you are concerned about a project allowing either user or host self-validation you should post in their forums.

·

This is a known issue in BOINC server code. Nothing to panic about. There are solutions, which admins should enable if they see fit.

If you find a potential security hole, you should contact devs and wait for an explanation or patch before making it public.

·

I completely agree. If this is a legitimate exploit, giving it publicity before contacting devs or the project is reckless and puts the network at a greater risk. It's called responsible disclosure, look it up.

·

It isnt that bad, even if it were to be exploited malicious attackers would compete with each other and achieve their daily task limit whitout gaining any credit, and then getting banned from the project.

Edit: I forgot - The main problem is people accidentally feeding bad data to the project

If we suspected this was happening systematically in a project, we would immediately remove it from the whitelist until the project administrators demonstrated more robust security. It is definitely within the power of administrators to do this; there are BOINC threads out there discussing exactly this issue. Don't forget that even without Gridcoin, people like to compete using credits. So the BOINC community has invested a fair amount into ensuring accurate distribution of credit.

Don't forget also that you can't choose which workunits to download. So you'd have to sift through the automatically downloaded workunits until you finally received one you'd done before through a different client. This would be pretty tedious.

·

O no, what i mean was that those were downloaded in the same batch, it is a very limited bug but it can have a long term impact if incorrect data (this ryzen cpu is relatively new, it could had a undiscovered cpu bug) . But it isnt that serious as i impulsively thought.

·
·

Oh, sorry, I misunderstood. My bad. So it does sound like a fairly localized problem that can be fixed within the context of the project. Good someone is noticing, because yeah technically speaking a bad result could inadvertently be passed.