)]}'
{
  "commit": "c51443f4aa6b7f0b0d6ad5409ad7d4b215092443",
  "tree": "effbe8695f7bfd0ed5261b08d5beddb66cceed64",
  "parents": [
    "78116ab6e1524815910658898620776ae5fd4d18"
  ],
  "author": {
    "name": "David Lamparter",
    "email": "equinox@opensourcerouting.org",
    "time": "Mon Jul 08 23:05:28 2013 +0200"
  },
  "committer": {
    "name": "David Lamparter",
    "email": "equinox@opensourcerouting.org",
    "time": "Sun Jul 28 16:13:10 2013 +0200"
  },
  "message": "ospfd: CVE-2013-2236, stack overrun in apiserver\n\nthe OSPF API-server (exporting the LSDB and allowing announcement of\nOpaque-LSAs) writes past the end of fixed on-stack buffers.  This leads\nto an exploitable stack overflow.\n\nFor this condition to occur, the following two conditions must be true:\n- Quagga is configured with --enable-opaque-lsa\n- ospfd is started with the \"-a\" command line option\n\nIf either of these does not hold, the relevant code is not executed and\nthe issue does not get triggered.\n\nSince the issue occurs on receiving large LSAs (larger than 1488 bytes),\nit is possible for this to happen during normal operation of a network.\nIn particular, if there is an OSPF router with a large number of\ninterfaces, the Router-LSA of that router may exceed 1488 bytes and\ntrigger this, leading to an ospfd crash.\n\nFor an attacker to exploit this, s/he must be able to inject valid LSAs\ninto the OSPF domain.  Any best-practice protection measure (using\ncrypto authentication, restricting OSPF to internal interfaces, packet\nfiltering protocol 89, etc.) will prevent exploitation.  On top of that,\nremote (not on an OSPF-speaking network segment) attackers will have\ndifficulties bringing up the adjacency needed to inject a LSA.\n\nThis patch only performs minimal changes to remove the possibility of a\nstack overrun.  The OSPF API in general is quite ugly and needs a\nrewrite.\n\nReported-by: Ricky Charlet \u003cricky.charlet@hp.com\u003e\nCc: Florian Weimer \u003cfweimer@redhat.com\u003e\nSigned-off-by: David Lamparter \u003cequinox@opensourcerouting.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "74a49e3be93f45e5c5f04820d2fba01306c0ddfb",
      "old_mode": 33188,
      "old_path": "ospfd/ospf_api.c",
      "new_id": "fae942ec2011308e5c5e5c18943db0740c0e2902",
      "new_mode": 33188,
      "new_path": "ospfd/ospf_api.c"
    }
  ]
}