[Pkg-xmpp-devel] Bug#1071696: profanity: (security) Untrusted OMEMO keys are being used. Fingerprint trust is inconsistent.

[Manny]

Package: profanity
Version: 0.13.1-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.profanity at sideload.33mail.com

The Profanity user guide¹ states

  “Before you can start talking with a contact you need to
   authenticate him by trusting his fingerprint(s).”

That seems to be true for some correspondents but not others. I have
four people configured as follows:

  * Alice -   trusted fingerprint
  * Bob -     untrusted fingerprint (implicit distrust)
  * Freddie - untrusted fingerprint (implicit distrust)
  * Martin -  untrusted fingerprint (implicit distrust)

My trustmodel is “manual”.  All those users are using Snikket on iOS
and the server is also Snikket. OMEMO is always enabled for all those
users. According to the documentation, only Alice should be able to
receive messages from me in this situation. However, Alice, Freddie,
and Martin all seem to receive messages from me. Bob is exceptionally
plagued with a false error claiming lack of OMEMO support every time I
send Bob a msg. Apart from the error message being false, msgs to Bob
are rightfully dysfunctional (though I would prefer if he receives no
msg at all - what’s the point of sending him a msg he cannot
open?). Msgs to Alice are rightfully functional.

But what about Freddie & Martin?  They generally receive my msgs fine,
yet I apparently did not trust their fingerprints. This suggests a
noteworthy security vulnerability because an untrusted key should not
be used with a trust model of /manual/.

Alternative theory 1:

I did not keep notes on whose fingerprints I trusted. I am surprised I
did not trust Freddie’s key. So I wonder if Profanity might be lying
about whether keys are trusted. After entering /msg Freddie to get a
dedicated 1:1 window, I entered “/omemo fingerprint” and it showed a
fingerprint. It does not say trusted or untrusted. But if I do the
same for Alice, “(trusted)” is printed next to the fingerprint. So by
the way, the absence of “(trusted)” is an incredibly cryptic way of
telling users a key is untrusted. I struggled to trust the
software. So I found this file:

  ~/.local/share/profanity/omemo/$my_acct/trust.txt

And indeed the fingerprints for Bob, Freddie, and Martin were not
there. So I think we can rule out the alternative narrative that
Profanity is lying about which keys are trusted.

Alternative theory 2:

Perhaps the “OMEMO” tag in the window status bar is a lie, and
Profanity is actually sending unencrypted payloads to Freddie &
Martin. This also seems unlikely but I will ask them if Snikket shows
a padlock or shield on messages they receive from me. If not, I’ll
amend this ticket. Otherwise assume they are getting a padlock.

¹ https://profanity-im.github.io/guide/0131/omemo.html

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages profanity depends on:
ii  libc6                      2.36-9+deb12u7
ii  libcurl3-gnutls            7.88.1-10+deb12u5
ii  libgcrypt20                1.10.1-3
ii  libgdk-pixbuf-2.0-0        2.42.10+dfsg-1+b1
ii  libglib2.0-0               2.74.6-2+deb12u2
ii  libgpgme11                 1.18.0-3+b1
ii  libgtk-3-0                 3.24.38-2~deb12u1
ii  libncursesw6               6.4-4
ii  libnotify4                 0.8.1-1
ii  libotr5                    4.1.1-5
ii  libpython3.11              3.11.2-6
ii  libreadline8               8.2-1.3
ii  libsignal-protocol-c2.3.2  2.3.3-3
ii  libsqlite3-0               3.40.1-2
ii  libstrophe0                0.12.2-1
ii  libtinfo6                  6.4-4

profanity recommends no packages.

profanity suggests no packages.

-- no debconf information