We begin by stating some assumptions about how irker will be deployed,
and articulating a set of security goals.
-Communication flow in an irker deployment will looks like this:
+Communication flow in an irker deployment will look like this:
+-----------------------------------------------------------------------------
Committers
|
|
|
|
IRC servers
+-----------------------------------------------------------------------------
Here are our assumptions:
* Availability: Only group A should be able to to deny or degrade
irkerd's ability to receive commit messages and relay them to the
IRC server. We recognize and accept as inevitable that MITMs (groups
- 4 and 5) can do this too (by ARP spoofing, cable-cutting, etc.).
+ E and F) can do this too (by ARP spoofing, cable-cutting, etc.).
But, in particular, we would like irker-mediated services to be
resilient against DoS (denial of service) attacks.
* Auditability: If people abuse irkerd, we want to be able to identify
the abusive account or IP address.
-== Control Issues ===
+== Control Issues ==
We have audited the irker and irkerhook.py code for exploitable
-vulnerabilities. We have not found any in the code itself, but the
-fact that irkerhook.py relies on external binaries to mine data ought
-of its repository opens up a well-known set of vulnerabilities if a
-malicious user is able to insert binaries in a carelessly-set
-execution path. Normal precautions against this should be taken.
+vulnerabilities. We have not found any in the code itself, and the
+use of Python gives us confidence in the absence of large classes of errors
+(such as buffer overruns) that afflict C programs.
+
+However, the fact that irkerhook.py relies on external binaries to
+mine data out of its repository opens up a well-known set of
+vulnerabilities if a malicious user is able to insert binaries in a
+carelessly-set execution path. Normal precautions against this should
+be taken.
== Availability ==
3. Limit the number of requests that can be queued by source IP address.
This might be worth doing; it would stymie a single-source DoS attack through
-a publicly-exposed irkerd, though not a DDoS by a bitnet. But there isn't
+a publicly-exposed irkerd, though not a DDoS by a botnet. But there isn't
a lot of win here for a properly installed irker (e.g. behind a firewall),
which is typically going to get all its requests from a single repo host
anyway.
The deployment advice in the installation instructions assumes that
irkerd submitters are "authenticated" by being inside a firewall - that is,
mesages are issued from an intranet and it can be trusted that anyone
-issuing messages from within a given intrenet is authorized to do so.
+issuing messages from within a given intranet is authorized to do so.
This fits the assumption that irker instances will run on forge sites
receiving requests from instances of irkerhook.py.
-If this is *not* the case (e.g. the network between a hook and irkerd
-has to be considered hostile) we could hide irkerd behind an instance
-of spiped <http://www.tarsnap.com/spiped.html> or an instance of
-stunnel <http://www.stunnel.orgproxy>. These would be far superior to
-in-band authentication in that they would leave the job to specialist
-code not in any way coupled to irkerd's internals, minimizing
-global complexity and failure modes.
-
One larger issue (not unique to irker) is that because of the
insecured nature of IRC it is essentially impossible to secure
#commits against commit notifications that are either garbled by
software errors and misconfigurations or maliciously crafted to
-confuse anyone attempting to gather statistics from that. The lesson
-here is that IRC monitoring isn't a good method for that purpose;
-going direct to the repositories via a toolkit such as Ohloh is
-a far better idea.
-
-=== Future directions ===
+confuse anyone attempting to gather statistics from that channel. The
+lesson here is that IRC monitoring isn't a good method for that
+purpose; going direct to the repositories via a toolkit such as Ohloh
+is a far better idea.
-There is presently no direct support for spipe or stunnel in
-irkerhook.py. We'd take patches for this.
+When this analysis was originally written, we recommended using spiped
+or stunnel to solve the problem of passing notifications from irkerd
+to IRC servers over a potentially hostile network that might interfere
+with them. Later, SSL/TLS support proved easy to add and is now in
+irkerd itself.
== Secrecy ==
it provided a single point at which spam filtering and source blocking
could be done with benefit to all projects using the service, and (b)
since it had to have a database anyway for routing messages to project
-channels, the incremental overhead for an authentication feature will
-be relatively low.
+channels, the incremental overhead for an authentication feature would
+have been relatively low.
As a matter of fact rather than theory CIA never fully exploited
either possibility. Anyone could create a CIA project entry with
projects / irker.git / blobdiff