Security issues in volunteer computing

Many types of attacks are possible in volunteer computing.

• Result falsification. Attackers return incorrect results.
• Credit falsification. Attackers return results claiming more CPU time than was actually used.
• Malicious executable distribution. Attackers break into a BOINC server and, by modifying the database and files, attempt to distribute their own executable (e.g. a virus program) disguised as a BOINC application.
• Overrun of data server. Attackers repeatedly send large files to BOINC data servers, filling up their disks and rendering them unusable.
• Theft of participant account information by server attack. Attackers break into a BOINC server and steal email addresses and other account information.
• Theft of participant account information by network attack. Attackers exploit the BOINC network protocols to steal account information.
• Theft of project files. Attackers steal input and/or output files.
• Intentional abuse of participant hosts by projects. A project intentionally releases an application that abuses participant hosts, e.g. by stealing sensitive information stored in files.
• Accidental abuse of participant hosts by projects. A project releases an application that unintentionally abuses participant hosts, e.g. deleting files or causing crashes.

BOINC provides mechanisms to reduce the likelihood of some of these attacks.

Result and credit falsification

These can be reduced using replication or other result validation methods.

Malicious executable distribution

BOINC uses code signing to prevent this. Even if attackers break into a project's BOINC server, they will not be able to cause clients to accept a false code file.

Denial of server attacks on data servers

BOINC provides an optional mechanism, upload certificates, to prevent data server attacks. Each output file has an associated maximum size. Each project has a upload authentication key pair. The public key is stored on the project's data servers. Result file descriptions are sent to clients with a digital signature, which is forwarded to the data server when the file is uploaded. The data server verifies the file description, and ensures that the amount of data uploaded does not exceed the maximum size.

Theft of participant account information by server attack

Each project must address theft of private account information (e.g. email addresses) using conventional security practices. All server machines should be protected by a firewall, and should have all unused network services disabled. Access to these machines should be done only with encrypted protocols like SSH. The machines should be subjected to regular security audits.

Projects should be undertaken only by organizations that have sufficient expertise and resources to secure their servers. A successful attack could discredit all BOINC-based projects, and volunteer computing in general.

Theft of participant account information by network attack

Attackers sniffing network traffic could get a user's account key, and use them to get the user's email address, or change the user's preferences. BOINC does nothing to prevent this.

Theft of project files

The input and output files used by BOINC applications are not encrypted. Applications can do this themselves, but it has little effect since data resides in cleartext in memory, where it is easy to access with a debugger.

Intentional abuse of participant hosts by projects

BOINC uses account-based sandboxing: applications run under a specially-created account (Mac/Linux? version 5.4+, Windows version 6+). If file and directory permissions are set appropriately, applications will have no access to files outside of the BOINC directory.

Accidental abuse of participant hosts by projects

BOINC prevents some problems: for example, it detects when applications use too much disk space, memory, or CPU time, and aborts them. Projects can minimize the likelihood of causing problems by pre-released application testing. Projects should test their applications thoroughly on all platforms and with all input data scenarios before promoting them to production status.