| 1 | | [reserved] |
| | 1 | == Description == |
| | 2 | |
| | 3 | Pending file transfer requests expire after 120 seconds, which may |
| | 4 | result in use after free if the corresponding account is disconnected. |
| | 5 | A malicious remote server could force this disconnection. |
| | 6 | |
| | 7 | == Impact == |
| | 8 | |
| | 9 | This results in denial of service (remote crash of the BitlBee |
| | 10 | instance), or remote code execution (theoretically). |
| | 11 | |
| | 12 | For BitlBee servers configured in ForkDaemon mode (default) or inetd |
| | 13 | mode, the crash is limited to one user connection, who may just |
| | 14 | reconnect. |
| | 15 | |
| | 16 | * Access Vector: Network |
| | 17 | * Access Complexity: High |
| | 18 | * Authentication: None |
| | 19 | * Confidentiality Impact: None |
| | 20 | * Integrity Impact: None |
| | 21 | * Availability Impact: Partial |
| | 22 | * Exploitability: Functional Exploit Exists |
| | 23 | * Remediation Level: Official Fix |
| | 24 | * Report Confidence: Confirmed |
| | 25 | * Target Distribution: Medium |
| | 26 | * CVSS v2 score: 1.6 |
| | 27 | |
| | 28 | == Affected versions == |
| | 29 | |
| | 30 | bitlbee-libpurple 3.4.2 or older |
| | 31 | |
| | 32 | == Unaffected versions == |
| | 33 | |
| | 34 | bitlbee (non-libpurple builds), any version |
| | 35 | |
| | 36 | bitlbee-libpurple 3.5 |
| | 37 | |
| | 38 | == Resolution == |
| | 39 | |
| | 40 | * Upgrade to 3.5 (released 2017-01-08) |
| | 41 | |
| | 42 | * For 3.4.2 see the attached |
| | 43 | 0001-purple-fix-file-transfer-memory-management-3.4.2.patch [not |
| | 44 | included in this email] |
| | 45 | |
| | 46 | * For 3.4.1 and 3.4 see the attached |
| | 47 | 0001-purple-fix-file-transfer-memory-management-3.4-3.4.1.patch [not |
| | 48 | included in this email] |
| | 49 | |
| | 50 | * For earlier versions upgrading is strongly recommended because of |
| | 51 | the amount of accumulated bugfixes, but the following line may be |
| | 52 | removed from `protocols/purple/purple.c` to prevent any processing of |
| | 53 | incoming file transfers: |
| | 54 | |
| | 55 | purple_xfers_set_ui_ops(&bee_xfer_uiops); |
| | 56 | |
| | 57 | == Discussion == |
| | 58 | |
| | 59 | This affects any libpurple protocol when used through BitlBee. It does |
| | 60 | not affect other libpurple-based clients such as pidgin. |
| | 61 | |
| | 62 | This is a very visible issue - all file transfer request attempts and |
| | 63 | all disconnections will be logged in the control channel and visible |
| | 64 | by the targeted user. File transfer requests look like this: |
| | 65 | |
| | 66 | <@root> [account] - File transfer request from [username] for |
| | 67 | [filename] (0 kb). |
| | 68 | <@root> Accept the file transfer if you'd like the file. If you |
| | 69 | don't, issue the 'transfer reject' command. |
| | 70 | |
| | 71 | Cancelling the file transfer request using the "transfer reject" |
| | 72 | command before the disconnection happens can prevent this. However, |
| | 73 | using that command after the account is disconnected will result in an |
| | 74 | immediate crash. |
| | 75 | |
| | 76 | == References == |
| | 77 | |
| | 78 | Original bugfix commit: |
| | 79 | |
| | 80 | https://github.com/bitlbee/bitlbee/commit/ea902752503fc5b356d6513911081ec932d804f2 |