)]}'
{
  "commit": "1fb9fdc3027b27d8eb6a1e6a846435b070980770",
  "tree": "e6900d1e1354e3e8096e358e766ce42ed5edf655",
  "parents": [
    "ac9fc67a488427bc3e987f5a4c235e8fbeedf711"
  ],
  "author": {
    "name": "Matt Caswell",
    "email": "matt@openssl.org",
    "time": "Fri Jul 01 15:20:33 2016 +0100"
  },
  "committer": {
    "name": "Matt Caswell",
    "email": "matt@openssl.org",
    "time": "Fri Aug 19 13:52:40 2016 +0100"
  },
  "message": "Fix DTLS replay protection\n\nThe DTLS implementation provides some protection against replay attacks\nin accordance with RFC6347 section 4.1.2.6.\n\nA sliding \"window\" of valid record sequence numbers is maintained with\nthe \"right\" hand edge of the window set to the highest sequence number we\nhave received so far. Records that arrive that are off the \"left\" hand\nedge of the window are rejected. Records within the window are checked\nagainst a list of records received so far. If we already received it then\nwe also reject the new record.\n\nIf we have not already received the record, or the sequence number is off\nthe right hand edge of the window then we verify the MAC of the record.\nIf MAC verification fails then we discard the record. Otherwise we mark\nthe record as received. If the sequence number was off the right hand edge\nof the window, then we slide the window along so that the right hand edge\nis in line with the newly received sequence number.\n\nRecords may arrive for future epochs, i.e. a record from after a CCS being\nsent, can arrive before the CCS does if the packets get re-ordered. As we\nhave not yet received the CCS we are not yet in a position to decrypt or\nvalidate the MAC of those records. OpenSSL places those records on an\nunprocessed records queue. It additionally updates the window immediately,\neven though we have not yet verified the MAC. This will only occur if\ncurrently in a handshake/renegotiation.\n\nThis could be exploited by an attacker by sending a record for the next\nepoch (which does not have to decrypt or have a valid MAC), with a very\nlarge sequence number. This means the right hand edge of the window is\nmoved very far to the right, and all subsequent legitimate packets are\ndropped causing a denial of service.\n\nA similar effect can be achieved during the initial handshake. In this\ncase there is no MAC key negotiated yet. Therefore an attacker can send a\nmessage for the current epoch with a very large sequence number. The code\nwill process the record as normal. If the hanshake message sequence number\n(as opposed to the record sequence number that we have been talking about\nso far) is in the future then the injected message is bufferred to be\nhandled later, but the window is still updated. Therefore all subsequent\nlegitimate handshake records are dropped. This aspect is not considered a\nsecurity issue because there are many ways for an attacker to disrupt the\ninitial handshake and prevent it from completing successfully (e.g.\ninjection of a handshake message will cause the Finished MAC to fail and\nthe handshake to be aborted). This issue comes about as a result of trying\nto do replay protection, but having no integrity mechanism in place yet.\nDoes it even make sense to have replay protection in epoch 0? That\nissue isn\u0027t addressed here though.\n\nThis addressed an OCAP Audit issue.\n\nCVE-2016-2181\n\nReviewed-by: Richard Levitte \u003clevitte@openssl.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "a7732ff512e4f84cbbb1f91f09df7fee0425dcfe",
      "old_mode": 33188,
      "old_path": "include/openssl/ssl.h",
      "new_id": "4f23c9f804aa4c0f2136d390f1d0edf7b0ee64c8",
      "new_mode": 33188,
      "new_path": "include/openssl/ssl.h"
    },
    {
      "type": "modify",
      "old_id": "0f7881ecd0766095aa241a30a4d9285161f99015",
      "old_mode": 33188,
      "old_path": "ssl/record/rec_layer_d1.c",
      "new_id": "be6aac719f7ebeac96c257f32dd828141271e15f",
      "new_mode": 33188,
      "new_path": "ssl/record/rec_layer_d1.c"
    },
    {
      "type": "modify",
      "old_id": "3b9a700d9f8f1b855a04bdd9df1dbf0160882a1e",
      "old_mode": 33188,
      "old_path": "ssl/record/record_locl.h",
      "new_id": "52e59e46d53beb3cd6c86c5d9570bf167a307394",
      "new_mode": 33188,
      "new_path": "ssl/record/record_locl.h"
    },
    {
      "type": "modify",
      "old_id": "c99d5e4416f7efc283936f0b0733c627de4690ef",
      "old_mode": 33188,
      "old_path": "ssl/record/ssl3_record.c",
      "new_id": "32a97aff0826b00fba3d82c14f12c63df4469213",
      "new_mode": 33188,
      "new_path": "ssl/record/ssl3_record.c"
    },
    {
      "type": "modify",
      "old_id": "9644fd246627ad0bc34249fbdabdb88f48d5f826",
      "old_mode": 33188,
      "old_path": "ssl/ssl_err.c",
      "new_id": "1fddda612a813558c7b76467c52adb2fe58f6c44",
      "new_mode": 33188,
      "new_path": "ssl/ssl_err.c"
    }
  ]
}