Security analysis of irker

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 look like this:

Here are our assumptions:

We can, accordingly, identify the following groups of security principals:

Our security goals for irker can be enumerated as follows:

We have audited the irker and irkerhook.py code for exploitable 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.

One way to help prevent DoS attacks would be in-band authentication - requiring irkerd submitters to present a credential along with each message submission. In principle this, if it existed, could also be used to verify that a submitter is authorized to issue notifications with respect to a given project.

We rejected this approach. The design goal for irker was to make submissions fast, cheap, and stateless; baking an authentication system directly into the irkerd codebase would have conflicted with these objectives, not to mention probably becoming the camel’s nose for a godawful amount of code bloat.

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 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.

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.

irkerd has no inherent secrecy risks.

The distributed version of irkerhook.py removes the host part of author addresses specifically in order to prevent address harvesting from the notifications.

We previously noted that source IP address is the only thing irker can see that an attacker can’t spoof. This makes auditability difficult unless we impose conventions on the notifications passing though it.

The irkerhook.py that we ship inherits an auditability property from the CIA service it was designed to replace: the first field of every notification (terminated by a colon) is the name of the issuing project. The only other competitor to replace CIA known to us (kgb_bot) shares this property.

In the general case we cannot guarantee this property against groups A and F.

irker and irkerhook.py were written as a replacement for the now-defunct CIA notification service. The author has written a critique of that service: "CIA and the perils of overengineering" at http://esr.ibiblio.org/?p=4540. It is thus worth considering how a risk assessment of CIA compares to this one.

The principal advantages of CIA from a security point of view were (a) 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 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 fanout to any desired set of IRC channels. Notifications were not authenticated, so anyone could masquerade as a member of any project. The only check on abuse was human intervention to source-block spammers, and this was by no means completely effective - spam shipped via CIA was occasionally seen on on the freenode #commits channel.

The principal security disadvantage of CIA was that it meant the entire notification system was subject to single-point failure due to software or hosting failures on cia.vc, or to DoS attacks against the server. While there is no evidence that the site was ever deliberately DoSed, failures were sufficiently common that a half-hearted DoS attack might not have been even noticed.

Despite the absence of authentication, irker instances on properly firewalled intranets do not obviously pose additional spamming risks beyond those incurred by the CIA service. The overall robustness of the notification system as a whole should be greatly improved.

The security and DoS issues irker has are not readily addressable by changing the irker codebase itself, short of a complete (much more complex and heavyweight) redesign. They are largely implicit risks of its operating environment and must be managed by properly controlling access to irker instances.