Custom Query (1098 matches)
Results (16 - 18 of 1098)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#1281 | fixed | bitlbee-libpurple: Use after free when expiring file transfer requests | ||
Description |
DescriptionPending file transfer requests expire after 120 seconds, which may result in use after free if the corresponding account is disconnected. A malicious remote server could force this disconnection. CVE-2016-10188 has been assigned for this issue. ImpactThis results in denial of service (remote crash of the BitlBee instance), or remote code execution (theoretically). For BitlBee servers configured in ForkDaemon mode (default) or inetd mode, the crash is limited to one user connection, who may just reconnect.
Affected versionsbitlbee-libpurple 3.4.2 or older Unaffected versionsbitlbee (non-libpurple builds), any version bitlbee-libpurple 3.5 Resolution
0001-purple-fix-file-transfer-memory-management-3.4.2.patch
0001-purple-fix-file-transfer-memory-management-3.4-3.4.1.patch
the amount of accumulated bugfixes, but the following line may be
removed from purple_xfers_set_ui_ops(&bee_xfer_uiops); DiscussionThis affects any libpurple protocol when used through BitlBee. It does not affect other libpurple-based clients such as pidgin. This is a very visible issue - all file transfer request attempts and all disconnections will be logged in the control channel and visible by the targeted user. File transfer requests look like this: <@root> [account] - File transfer request from [username] for [filename] (0 kb). <@root> Accept the file transfer if you'd like the file. If you don't, issue the 'transfer reject' command. Cancelling the file transfer request using the "transfer reject" command before the disconnection happens can prevent this. However, using that command after the account is disconnected will result in an immediate crash. ReferencesCVE-2016-10188: Original bugfix commit: https://github.com/bitlbee/bitlbee/commit/ea902752503fc5b356d6513911081ec932d804f2 |
|||
#1275 | fixed | Sometimes double expansion of t.co URLs | ||
Description |
Sometimes you get a t.co URL expanded multiple times. Looks like this is just because they're mentioned in Twitter JSON repeatedly (man that stuff is verbose). Funny thing is it seems to happen more in the live feed than in backlog. Happens in decoded DMs all the time IME. Would be nice to detect this and stick to just one expansion. |
|||
#1274 | fixed | Improve handling of missing protocols | ||
Description |
This garbage: <@root> Error loading user config: Protocol not found: `telegram' <@root> Unknown error while loading configuration The next libpurple release will remove a handful of dead protocols, would be painful for everyone involved to leave it like this. |