2002-08-19 18:43:10 +00:00
|
|
|
<title>Security</title>
|
2002-08-20 23:54:17 +00:00
|
|
|
<body bgcolor=ffffff>
|
2002-07-29 19:01:38 +00:00
|
|
|
<h2>Security</h2>
|
|
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
Many types of attacks are possible in public-participation
|
2002-07-29 19:01:38 +00:00
|
|
|
distributed computing.
|
2002-07-07 20:39:24 +00:00
|
|
|
<ul>
|
2002-08-19 18:43:10 +00:00
|
|
|
<li> <b>Result falsification</b>.
|
|
|
|
|
Attackers return incorrect results.
|
|
|
|
|
<li> <b>Credit falsification</b>.
|
|
|
|
|
Attackers return results claiming more CPU time than was actually used.
|
|
|
|
|
<li>
|
|
|
|
|
<b>Malicious executable distribution</b>.
|
|
|
|
|
Attackers break into a BOINC server and,
|
|
|
|
|
by modifying the database and files, attempt to
|
2002-07-29 19:01:38 +00:00
|
|
|
distribute their own executable (e.g. a virus program) disguised as a
|
|
|
|
|
BOINC application.
|
2002-08-19 18:43:10 +00:00
|
|
|
<li>
|
|
|
|
|
<b>Overrun of data server</b>.
|
|
|
|
|
Attackers repeatedly send large files to BOINC data servers,
|
|
|
|
|
filling up their disks and rendering them unusable.
|
|
|
|
|
<li>
|
|
|
|
|
<b>Theft of participant account information by server attack</b>.
|
|
|
|
|
Attackers break into a BOINC server and steal email
|
2002-07-29 19:01:38 +00:00
|
|
|
addresses and other account information.
|
2002-08-19 18:43:10 +00:00
|
|
|
<li>
|
|
|
|
|
<b>Theft of participant account information by network attack</b>.
|
|
|
|
|
Attackers exploit the BOINC network protocols to steal account information.
|
|
|
|
|
<li>
|
|
|
|
|
<b>Theft of project files</b>.
|
|
|
|
|
Attackers steal input and/or output files.
|
|
|
|
|
<li>
|
|
|
|
|
<b>Intentional abuse of participant hosts by projects</b>.
|
|
|
|
|
A project intentionally releases an application that abuses participant
|
2002-07-29 19:01:38 +00:00
|
|
|
hosts, e.g. by stealing sensitive information stored in files.
|
2002-08-19 18:43:10 +00:00
|
|
|
<li>
|
|
|
|
|
<b>Accidental abuse of participant hosts by projects</b>.
|
2002-10-03 20:41:23 +00:00
|
|
|
A project releases an application that unintentionally abuses participant
|
2002-07-29 19:01:38 +00:00
|
|
|
hosts, e.g. deleting files or causing crashes.
|
2002-07-07 20:39:24 +00:00
|
|
|
</ul>
|
2002-08-19 18:43:10 +00:00
|
|
|
BOINC provides mechanisms to reduce the likelihood of some of these attacks.
|
2002-07-29 19:01:38 +00:00
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
<b>Result falsification</b>
|
2002-07-29 19:01:38 +00:00
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
This can be probabilistically detected using redundant computing and
|
2002-07-29 19:01:38 +00:00
|
|
|
result verification: if a majority of results agree (according to an
|
|
|
|
|
application-specific comparison) then they are classified as correct.
|
|
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
<b>Credit falsification</b>
|
2002-07-29 19:01:38 +00:00
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
This can be probabilistically detected using redundant computing and
|
2002-07-29 19:01:38 +00:00
|
|
|
credit verification: each participant is given the minimum credit from
|
|
|
|
|
among the correct results.
|
|
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
<b>Malicious executable distribution</b>
|
2002-07-29 19:01:38 +00:00
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
BOINC uses code signing to prevent this. Each project has a key pair
|
|
|
|
|
for code signing.
|
|
|
|
|
The private key should be kept on a network-isolated
|
|
|
|
|
machine used for generating digital signatures for executables.
|
|
|
|
|
The public key is distributed to, and stored on, clients.
|
|
|
|
|
All files
|
2002-07-29 19:01:38 +00:00
|
|
|
associated with application versions are sent with digital signatures
|
|
|
|
|
using this key pair.
|
|
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
Even if attackers break into a project's BOINC servers, they will
|
2002-07-29 19:01:38 +00:00
|
|
|
not be able to cause clients to accept a false code file.
|
|
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
BOINC provides a mechanism by which projects can periodically change
|
|
|
|
|
their code-signing key pair.
|
|
|
|
|
The project generates a new key pair, then
|
2002-07-29 19:01:38 +00:00
|
|
|
(using the code-signing machine) generates a signature for the new
|
2002-08-19 18:43:10 +00:00
|
|
|
public key, signed with the old private key.
|
|
|
|
|
The core client will accept
|
|
|
|
|
a new key only if it's signed with the old key.
|
|
|
|
|
This mechanism is
|
2002-07-29 19:01:38 +00:00
|
|
|
designed to prevent attackers from breaking into a BOINC server and
|
|
|
|
|
distributing a false key pair.
|
|
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
<b>Overrun of data server</b>
|
2002-07-29 19:01:38 +00:00
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
Each result file has an associated maximum size.
|
|
|
|
|
Each project has a
|
|
|
|
|
<b>upload authentication key pair</b>.
|
|
|
|
|
The public key is stored on the
|
2002-07-29 19:01:38 +00:00
|
|
|
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
|
2002-08-19 18:43:10 +00:00
|
|
|
ensures that the amount of data uploaded does not exceed the maximum size.
|
2002-07-29 19:01:38 +00:00
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
<b>Theft of participant account information by server attack</b>
|
2002-07-29 19:01:38 +00:00
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
Each project must address this 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.
|
2002-07-29 19:01:38 +00:00
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
Projects should be undertaken only the organizations that have
|
|
|
|
|
sufficient expertise and resources to secure their servers.
|
|
|
|
|
A successful
|
2002-07-29 19:01:38 +00:00
|
|
|
attack could discredit all BOINC-based projects, and
|
|
|
|
|
public-participation computing in general.
|
|
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
<b>Theft of participant account information by network attack</b>
|
2002-07-29 19:01:38 +00:00
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
<b>Theft of project files</b>
|
2002-07-29 19:01:38 +00:00
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
The input and output files used by BOINC applications are not encrypted.
|
|
|
|
|
Applications can do this themselves, but it has little effect
|
2002-07-29 19:01:38 +00:00
|
|
|
since data resides in cleartext in memory, where it is easy to access
|
|
|
|
|
with a debugger.
|
|
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
<b>Intentional abuse of participant hosts by projects</b>
|
2002-07-29 19:01:38 +00:00
|
|
|
</p>
|
|
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
BOINC does nothing to prevent this (e.g. there is no "sandboxing" of
|
|
|
|
|
applications).
|
|
|
|
|
Participants must understand that when they join a BOINC project,
|
|
|
|
|
they are entrusting the security of their systems to that project.
|
2002-07-29 19:01:38 +00:00
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
<b>Accidental abuse of participant hosts by projects</b>
|
2002-07-29 19:01:38 +00:00
|
|
|
<p>
|
2002-08-19 18:43:10 +00:00
|
|
|
BOINC does nothing to prevent this.
|
|
|
|
|
The chances of it happening can
|
|
|
|
|
be minimized by pre-released application testing.
|
|
|
|
|
Projects should test
|
2002-07-29 19:01:38 +00:00
|
|
|
their applications thoroughly on all platforms and with all input data
|
|
|
|
|
scenarios before promoting them to production status.
|
