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.
After this we appear to have run out of easy options, as source IP address
is the only thing irkerd can see that an attacker can't spoof.
-=== Future directions ===
-
-One way we could mitigate some availability risks is by reaping old
-sessions when we're near resource limits. An ordinary DoS attack
-would then be prevented from completely blocking all message traffic;
-the cost would be a whole lot of join/leave spam due to connection
-churn.
+We mitigate some availability risks by reaping old sessions when we're
+near resource limits. An ordinary DoS attack would then be prevented
+from completely blocking all message traffic; the cost would be a
+whole lot of join/leave spam due to connection churn.
-= Authentication/Integrity =
+== Authentication/Integrity ==
One way to help prevent DoS attacks would be in-band authentication -
requiring irkerd submitters to present a credential along with each
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.
-
-=== Future directions ===
-
-There is presently no direct support for spipe or stunnel in
-irkerhook.py. We'd take patches for this.
+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 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.
+
+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