security.txt

   1 = Security analysis of irker =
   2
   3 This is an analysis of security and DoS vulnerabilities associated
   4 with irker, exploring and explaining certain design choices.  Much of
   5 it derives from a code audit and report by Daniel Franke.
   6
   7 == Assumptions and Goals ==
   8
   9 We begin by stating some assumptions about how irker will be deployed,
  10 and articulating a set of security goals.
  11
  12 Communication flow in an irker deployment will look like this:
  13
  14 -----------------------------------------------------------------------------
  15              Committers
  16                  |
  17                  |
  18         Version-control repositories
  19                  |
  20                  |
  21             irkerhook.py
  22                  |
  23                  |
  24                irkerd
  25                  |
  26                  |
  27              IRC servers
  28 -----------------------------------------------------------------------------
  29
  30 Here are our assumptions:
  31
  32 1. The repositories are hosted on a public forge sites such as
  33 SourceForge, GitHub, Gitorious, Savannah, or Gna and must be
  34 accessible to untrusted users.
  35
  36 2. Repository project owners can set properties on their repositories
  37 (including but not limited to irker.*), and may be able to set custom
  38 post-commit hooks which can execute arbitrary code on the repostory
  39 server. In particular, these people my be able to modify the local
  40 copy of irkerhook.py.
  41
  42 3. The machine which hosts irkerd has the same owner as the machine which
  43 hosts the the repo; these machines are possibly but not necessarily
  44 one and the same.
  45
  46 4. The network is protected by a perimeter firewall, and only a
  47 trusted group is able to emit arbitrary packets from inside the
  48 perimeter; committers are not necessarily part of this group.
  49
  50 5. irkerd communicates with IRC servers over the open internet,
  51 and an IRC server's administrator is assumed to hold no position of
  52 trust with any other party.
  53
  54 We can, accordingly, identify the following groups of security
  55 principals:
  56
  57 A. irker administrators.
  58 B. Project committers.
  59 C. Project owners
  60 D. IRC server administrators.
  61 E. Other people on irker's internal network.
  62 F. irkerd-IRC men-in-the-middle (i.e. people who control the network path
  63    between irkerd and the IRC server).
  64 G. Random people on the internet.
  65
  66 Our security goals for irker can be enumerated as follows:
  67
  68 * Control: We don't want anyone outside group A gaining control of
  69   the machines which host irkerd or the git repos.
  70
  71 * Availability: Only group A should be able to to deny or degrade
  72   irkerd's ability to receive commit messages and relay them to the
  73   IRC server. We recognize and accept as inevitable that MITMs (groups
  74   4 and 5) can do this too (by ARP spoofing, cable-cutting, etc.).
  75   But, in particular, we would like irker-mediated services to be
  76   resilient against DoS (denial of service) attacks.
  77
  78 * Authentication/integrity: Notifications should be truthful, i.e.,
  79   commit messages sent to IRC channels should actually reflect that a
  80   corresponding commit has taken place. We accept that groups A, C,
  81   D, and E can violate this property.
  82
  83 * Secrecy: irker shouldn't aid spammers (group G) in harvesting
  84   committers' email addresses.
  85
  86 * Auditability: If people abuse irkerd, we want to be able to identify
  87   the abusive account or IP address.
  88
  89 == Control Issues ===
  90
  91 We have audited the irker and irkerhook.py code for exploitable
  92 vulnerabilities.  We have not found any in the code itself, but the
  93 fact that irkerhook.py relies on external binaries to mine data ought
  94 of its repository opens up a well-known set of vulnerabilities if a
  95 malicious user is able to insert binaries in a carelessly-set
  96 execution path.  Normal precautions against this should be taken.
  97
  98 == Availability ==
  99
 100 === Solved problems ===
 101
 102 When the original implementation of irkerd saw a nick collision it
 103 generated new nicks in a predictable sequence. A malicious IRC user
 104 could have continuously changed his own nick to the next one that
 105 irkerd is going to try. Some randomness has been added to nick
 106 generation to prevent this.
 107
 108 === Unsolved problems ===
 109
 110 DoS attacks on any networked application can never completely
 111 prevented, only mitigated by forcing attackers to invest more
 112 resources.  Here we consider the easiest attack paths against irker,
 113 and possible countermeasures.
 114
 115 irker handles each connection to a particular IRC server in a separate
 116 thread - actually, due to server limits on open channels per
 117 connection, there may be multiple sessions per server. This may not
 118 scale well, especially on 32-bit architectures.
 119
 120 Thread instance overhead, combined with the lack of any restriction on
 121 how many URLs can appear in the 'to' list, is a DoS vulnerability. If
 122 a repository's properties specify that notifications should go to more
 123 than about 500 unique hostnames, then on 32-bit architectures we'll
 124 hit the 4GB cap on virtual memory (even while the resident set size
 125 remains small).
 126
 127 Another ceiling to watch out for is the ulimit on file descriptors,
 128 which defaults to 1024 on many Linux systems but can safely be set
 129 much larger. Each connection instance costs a file descriptor.
 130
 131 We consider some possible ways of addressing the problem:
 132
 133 1. Limit the number of URLs in a request.  Pretty painless - it will
 134 be very rare that anyone wants to specify a larger set than a project
 135 channel plus freenode #commits - but also ineffective.  A malicious
 136 hook could achieve DoS simply by spamming lots of requests.
 137
 138 2. Limit the total number of requests than can be queued. Completely
 139 ineffective - just sets a target for the DoS attack.
 140
 141 3. Limit the number of requests that can be queued by source IP address.
 142 This might be worth doing; it would stymie a single-source DoS attack through
 143 a publicly-exposed irkerd, though not a DDoS by a bitnet.  But there isn't
 144 a lot of win here for a properly installed irker (e.g. behind a firewall),
 145 which is typically going to get all its requests from a single repo host
 146 anyway.
 147
 148 4. Rate-limit requests by source IP address - that is, after any request
 149 discard additional ones during some timeout period.  Again, good for
 150 stopping a single-source DoS against an exposed irker, won't stop a
 151 DDoS.  The real problem though, is that any such rate limit might interfere
 152 with legitimate high-volume use by a very active repo site.
 153
 154 After this we appear to have run out of easy options, as source IP address
 155 is the only thing irkerd can see that an attacker can't spoof.
 156
 157 We mitigate some availability risks by reaping old sessions when we're
 158 near resource limits.  An ordinary DoS attack would then be prevented
 159 from completely blocking all message traffic; the cost would be a
 160 whole lot of join/leave spam due to connection churn.
 161
 162 == Authentication/Integrity ==
 163
 164 One way to help prevent DoS attacks would be in-band authentication -
 165 requiring irkerd submitters to present a credential along with each
 166 message submission.  In principle this, if it existed, could also be used
 167 to verify that a submitter is authorized to issue notifications with
 168 respect to a given project.
 169
 170 We rejected this approach. The design goal for irker was to make
 171 submissions fast, cheap, and stateless; baking an authentication
 172 system directly into the irkerd codebase would have conflicted with
 173 these objectives, not to mention probably becoming the camel's nose
 174 for a godawful amount of code bloat.
 175
 176 The deployment advice in the installation instructions assumes that
 177 irkerd submitters are "authenticated" by being inside a firewall - that is,
 178 mesages are issued from an intranet and it can be trusted that anyone
 179 issuing messages from within a given intrenet is authorized to do so.
 180 This fits the assumption that irker instances will run on forge sites
 181 receiving requests from instances of irkerhook.py.
 182
 183 If this is *not* the case (e.g. the network between a hook and irkerd
 184 has to be considered hostile) we could hide irkerd behind an instance
 185 of spiped <http://www.tarsnap.com/spiped.html> or an instance of
 186 stunnel <http://www.stunnel.orgproxy>. These would be far superior to
 187 in-band authentication in that they would leave the job to specialist
 188 code not in any way coupled to irkerd's internals, minimizing
 189 global complexity and failure modes.
 190
 191 One larger issue (not unique to irker) is that because of the
 192 insecured nature of IRC it is essentially impossible to secure
 193 #commits against commit notifications that are either garbled by
 194 software errors and misconfigurations or maliciously crafted to
 195 confuse anyone attempting to gather statistics from that.  The lesson
 196 here is that IRC monitoring isn't a good method for that purpose;
 197 going direct to the repositories via a toolkit such as Ohloh is
 198 a far better idea.
 199
 200 === Future directions ===
 201
 202 There is presently no direct support for spipe or stunnel in
 203 irkerhook.py.  We'd take patches for this.
 204
 205 == Secrecy ==
 206
 207 irkerd has no inherent secrecy risks.
 208
 209 The distributed version of irkerhook.py removes the host part of
 210 author addresses specifically in order to prevent address harvesting
 211 from the notifications.
 212
 213 == Auditability ==
 214
 215 We previously noted that source IP address is the only thing irker can
 216 see that an attacker can't spoof.  This makes auditability difficult
 217 unless we impose conventions on the notifications passing though it.
 218
 219 The irkerhook.py that we ship inherits an auditability property from
 220 the CIA service it was designed to replace: the first field of every
 221 notification (terminated by a colon) is the name of the issuing
 222 project.  The only other competitor to replace CIA known to us
 223 (kgb_bot) shares this property.
 224
 225 In the general case we cannot guarantee this property against
 226 groups A and F.
 227
 228 == Risks relative to centralized services ==
 229
 230 irker and irkerhook.py were written as a replacement for the
 231 now-defunct CIA notification service.  The author has written
 232 a critique of that service: "CIA and the perils of overengineering"
 233 at <http://esr.ibiblio.org/?p=4540>.  It is thus worth considering how
 234 a risk assessment of CIA compares to this one.
 235
 236 The principal advantages of CIA from a security point of view were (a)
 237 it provided a single point at which spam filtering and source blocking
 238 could be done with benefit to all projects using the service, and (b)
 239 since it had to have a database anyway for routing messages to project
 240 channels, the incremental overhead for an authentication feature will
 241 be relatively low.
 242
 243 As a matter of fact rather than theory CIA never fully exploited
 244 either possibility.  Anyone could create a CIA project entry with
 245 fanout to any desired set of IRC channels.  Notifications were not
 246 authenticated, so anyone could masquerade as a member of any project.
 247 The only check on abuse was human intervention to source-block
 248 spammers, and this was by no means completely effective - spam shipped
 249 via CIA was occasionally seen on on the freenode #commits channel.
 250
 251 The principal security disadvantage of CIA was that it meant the
 252 entire notification system was subject to single-point failure due
 253 to software or hosting failures on cia.vc, or to DoS attacks
 254 against the server.  While there is no evidence that the site
 255 was ever deliberately DoSed, failures were sufficiently common
 256 that a half-hearted DoS attack might not have been even noticed.
 257
 258 Despite the absence of authentication, irker instances on
 259 properly firewalled intranets do not obviously pose additional
 260 spamming risks beyond those incurred by the CIA service.  The
 261 overall robustness of the notification system as a whole should
 262 be greatly improved.
 263
 264 == Conclusions ==
 265
 266 The security and DoS issues irker has are not readily addressable by
 267 changing the irker codebase itself, short of a complete (much more
 268 complex and heavyweight) redesign.  They are largely implicit risks of
 269 its operating environment and must be managed by properly controlling
 270 access to irker instances.
 271