Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 31 Jan 2017 10:22:47 -0500
From: <>
To: <>
CC: <>, <>
Subject: Re: CVE Request - Remote DoS vulnerabilities in BitlBee

Hash: SHA256

> I've just released BitlBee 3.5.1 which includes fixes for these issues:
> a) bitlbee-libpurple: Use after free when expiring file transfer requests.
> b) Null pointer dereference with file transfer request from unknown contacts.
> c) Incomplete fix for issue (b), which left bitlbee-libpurple affected.
> I have already requested three CVEs to the distros mailing list when
> the issue was not public, but did not receive any reply at the time of
> this writing. If it is appropriate, I'd like to request them in this
> list instead.
> The first two were already public (fixed in 3.5, released 2017-01-08) but were
> not considered security issues before. The third issue is what 3.5.1
> fixes.

> # bitlbee-libpurple: Use after free when expiring file transfer requests
> Pending 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.
> This results in denial of service (remote crash of the BitlBee
> instance), or remote code execution (theoretically).
> * Authentication: None
> ## Unaffected versions
> bitlbee (non-libpurple builds), any version
> bitlbee-libpurple 3.5
> This 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.

> [] Original bugfix commit:

Use CVE-2016-10188.

> # Null pointer dereference with file transfer request from unknown contacts
> Receiving a file transfer request from a contact not in the contact
> list results in a null pointer dereference, leading to remote DoS by
> malicious remote clients.
> * Authentication: None
> ## Unaffected versions
> bitlbee-libpurple 3.5.1 or newer
> bitlbee (non-libpurple builds) 3.5 or newer
> The issue from 3.4.2 and older only affects the jabber protocol, which
> is the only non-purple protocol which implements file transfers.
> The issue that is still present in 3.5 affects any libpurple protocol
> that implements file transfers when used through BitlBee. It does not
> affect other libpurple-based clients such as pidgin.
> There's no visible effect of the issue other than the crash.

> [] Incomplete fix commit included in 3.5:

Use CVE-2016-10189 for the issue with Jabber file transfers that was
fixed by this commit.

> [] Libpurple specific bugfix commit included in 3.5.1:

Use CVE-2017-5668.

CVE-2017-5668 exists because of an incomplete fix for CVE-2016-10189.

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at ]
Version: GnuPG v1


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.