Bug 1024697 (CVE-2017-5591) - VUL-0: CVE-2017-5591: poezio: Incorrect implementation of XEP-0280: Message Carbons
Summary: VUL-0: CVE-2017-5591: poezio: Incorrect implementation of XEP-0280: Message C...
Status: RESOLVED FIXED
Alias: CVE-2017-5591
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other All
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Security Team bot
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/180313/
Whiteboard:
Keywords:
Depends on: 1024736
Blocks:
  Show dependency treegraph
 
Reported: 2017-02-10 10:11 UTC by Mikhail Kasimov
Modified: 2024-05-07 16:17 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Kasimov 2017-02-10 10:11:09 UTC
Ref: http://seclists.org/oss-sec/2017/q1/373
=============================================
Summary
-------

An incorrect implementation of XEP-0280: Message Carbons[0] in multiple
XMPP clients allows a remote attacker to impersonate any user, including
contacts, in the vulnerable application's display. This allows for
various kinds of social engineering attacks.

Classification
--------------

  - CWE-304: Missing Critical Step in Authentication
  - CWE-940: Improper Verification of Source of a Communication Channel
  - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:N (score 7.1)

Affected Applications
---------------------
   - CVE-2017-5591: poezio (0.8 - 0.10)

Details
-------

The XMPP protocol extension "XEP-0280: Message Carbons"[0] allows
a user to run multiple clients on their XMPP account by sending "carbon
copies" of outgoing and incoming messages to the user's other devices
(besides the one that directly sent or received the original message).

This feature must be supported by the user's server and must be
explicitly enabled by the client. Carbon copies are always generated by
the user's server and originate from the user's bare JID (their account
address).

For example, the following is message "Hi!", sent by Alice
(`alice@xmpp.example`) to Bob's client 1 (`bob@xmpp.example/client1`):

        <message from="alice@xmpp.example" to="bob@xmpp.example/client1">
            <body>Hi!</body>
        </message>

Bob is also logged in with carbons-enabled client 2, which receives the
following carbon-copy of the message:

        <message from="bob@xmpp.example" to="bob@xmpp.example/client2">
            <received xmlns='urn:xmpp:carbons:2'><forwarded
xmlns='urn:xmpp:forward:0'>
                <message from="alice@xmpp.example"
to="bob@xmpp.example/client1">
                    <body>Hi!</body>
                </message>
            </forwarded></received>
        </message>

Now, client 2 can extract the original message from the carbon copy and
display it accordingly. The "Security Considerations" section of
XEP-0280 explicitly states that:

| Any forwarded copies received by a Carbons-enabled client MUST be from
| that user's bare JID; any copies that do not meet this requirement
| MUST be ignored.

The Carbons implementation in the affected clients was lacking this
test. It simply checked all incoming messages for presence of a Carbon
element (`<received/>` or `<sent/>`), extracted and parsed it like a
regular message.

Therefore, it was possible for Mallory to send the following specially
crafted message to Bob:

        <message from="mallory@evil.example" to="b@xmpp.example">
            <received xmlns='urn:xmpp:carbons:2'><forwarded
xmlns='urn:xmpp:forward:0'>
                <message from="alice@xmpp.example"
to="bob@xmpp.example/client1">
                    <body>Please come to Creepy Valley tonight,
alone!</body>
                </message>
            </forwarded></received>
        </message>

This would appear as an authentic message from Alice, including Alice'
proper screen name, allowing Mallory to perform social engineering
attacks on Bob.
=============================================


Fix: - 2017-01-30 Release of poezio 0.11 with slixmpp 1.2.4
    slixmpp fix commit:
https://github.com/poezio/slixmpp/commit/22664ee7b86c8e010f312b66d12590fb47160ad8

https://software.opensuse.org/package/poezio

TW|42.(1|2): 0.7.1 in server:messaging repo
Comment 1 Matthias Gerstner 2017-02-10 11:00:15 UTC
Poezio is not currently part of any openSUSE distributions but you may want to check on this security issue in the devel project to avoid shipping the problem in the future.
Comment 2 Mikhail Kasimov 2017-02-10 11:10:56 UTC
(In reply to Matthias Gerstner from comment #1)
> Poezio is not currently part of any openSUSE distributions but you may want
> to check on this security issue in the devel project to avoid shipping the
> problem in the future.

My logic is simple here (and everywhere :) ): if package can be searched on software.opensuse.org NOT in /home: repo(-s), security issues should be alarmed anyway. This can help to avoid using insecure software versions for people, who like and use openSUSE.
Comment 3 Mikhail Kasimov 2017-02-10 12:54:10 UTC
Due to

> 2017-01-30 Release of poezio 0.11 with slixmpp 1.2.4

added dependence from boo#1024736
Comment 4 Swamp Workflow Management 2017-02-10 23:00:53 UTC
bugbot adjusting priority
Comment 5 Michael Vetter 2024-03-10 08:19:00 UTC
See https://bugzilla.suse.com/show_bug.cgi?id=1024736#c3
This can be closed.