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:
== 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 ==
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
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 ===
There is presently no direct support for spipe or stunnel in
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