Hi, thanks for reporting this.
Assigned to the package maintainer.

(Please set the status to 'assigned' if you are working on it)

Assignee: bugsquad => pkg-bugs
CC: (none) => mitya, ouaurelien

Freeze push asked for cauldron

CC: (none) => mageia

Advisory:
========================

Updated coturn package fixes security vulnerability:

When sending a CONNECT request with the XOR-PEER-ADDRESS value of 0.0.0.0, a
malicious user would be able to relay packets to the loopback interface.
Additionally, when coturn is listening on IPv6, which is default, the loopback
interface can also be reached by making use of either [::1] or [::] as the peer
address (CVE-2020-26262).

If updating is not possible, the setting --denied-peer-ip=0.0.0.0 can mitigate
this issue.

The coturn package has been patched to fix this issue.

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26262
https://github.com/coturn/coturn/security/advisories/GHSA-6g6j-r9rf-cm7p
========================

Updated packages in core/updates_testing:
========================
coturn-4.5.2-1.4.mga7

from coturn-4.5.2-1.4.mga7.src.rpm

Debian has issued an advisory for this on January 11:
https://www.debian.org/security/2021/dsa-4829

Ubuntu has issued an advisory for this on January 11:
https://ubuntu.com/security/notices/USN-4690-1

mga7, x64

If anybody in QA knows what TURN and STUN mean and what VoIP is then you might care to try running this.  Installing the package produces some information on its use.

Meanwhile, for CVE-2020-26262, there is a procedure for reproducing the issue.
https://github.com/coturn/coturn/security/advisories/GHSA-6g6j-r9rf-cm7p

$ turnserver -v --user=username:password
<various warnings regarding lack of configuration>
0: IPv4. CLI listener opened on : 127.0.0.1:5766
0: IPv4. SCTP listener opened on : 127.0.0.1:3478
....

stunner is not available to us so the following command fails:
$ stunner turn peer proxy socks5 tcp://172.17.0.2:3478 \
    --local-bind 0.0.0.0:9999 -u username:password

It should be followed by:
$ curl -x socks5h://127.0.0.1:9999 http://127.0.0.1
and:
$ curl -x socks5h://127.0.0.1:9999 http://0.0.0.0
-----------------------------------------------------------------------------
http://www.softwaresea.com/Linux/install-Stunner-10001892.htm
Downloaded the tarball for stunner and compiled a local binary.  That however has different arguments from the one used upstream which must be a version modified in house.  No success in trying to interpret the upstream arguments.
Web original:
Usage: stunner [-h] [-i] [-p] [-u username] <hostname>

Leaving this as is  - a starting point for someone more knowledgeable.

CC: (none) => tarazed25

Herman tested the last two security updates for coturn. See bug 26879 and bug 26413. A little out of my league, but if you want to try his test, I would think that would be sufficient. 

If not, I'm sure somebody would let us know.

CC: (none) => andrewsfarm

Thanks Thomas, and Herman.
Right, testing this after update via server route and ignoring PoC.

# rpm -q coturn
coturn-4.5.2-1.4.mga7

Tried to start coturn.
# systemctl enable coturn
Failed to enable unit: Unit file coturn.service does not exist.
# systemctl start coturn
Failed to start coturn.service: Unit coturn.service not found.
<As expected>

Created a configuration file for turnserver and enabled turnserver in /etc/default/coturn.
turnserver cannot be started (times out) presumably because it needs coturn.

# grep turn /etc/services
stun            3478/tcp stun-behavior turn # Session Traversal Utilities for NAT (STUN) port, TURN over TCP
stun            3478/udp stun-behavior turn # Session Traversal Utilities for NAT (STUN) port, TURN over UDP
stuns           5349/tcp stun-behaviors turns # STUN over TLS, TURN over TLS
stuns           5349/udp stun-behaviors turns # Reserved for a future enhancement of STUN, Reserved for a future enhancement of TURN

Sure enough, no such services.

This is going nowhere.  Over to you Herman if you are willing.

Looking at it, but  the service from coturn is turnserver, not coturn.

CC: (none) => herman.viaene

This is hopeless to test: Before the service could be started with an essentially blank conf file. but now security has been raised and one needs a "real" conf.
The last error I got was:
CONFIG ERROR: allow_loopback_peers and empty cli password cannot be used together.
 The "allow_loopback_peers" was previously by default allowed, now  isn't anymore. And I'm not sure there aren't any other implications.
I have to concede defeat, and unless Someone else can come up with somlthing better, I would suggest OK on clean install.

@Herman, comment 10.
I shall try this with turnserver when I can find time.  Tomorrow maybe.  Thanks for trying it.

This system has a config file for turnserver (probably copied from the net).
Tried to start turnserver as before and it seemed to hang. 
While it was trying to start the status was:
# systemctl status turnserver
● turnserver.service - coturn
   Loaded: loaded (/usr/lib/systemd/system/turnserver.service; enabled; vendor >
   Active: activating (start) since Tue 2021-02-16 20:28:31 GMT; 43s ago
     Docs: man:coturn(1)
           man:turnadmin(1)
           man:turnserver(1)
 Main PID: 895 (turnserver)
    Tasks: 33 (limit: 4915)
   Memory: 8.9M
   CGroup: /system.slice/turnserver.service
           └─895 /usr/bin/turnserver -c /etc/turnserver/turnserver.conf

Feb 16 20:28:31 canopus turnserver[895]: 0: : IO method (auth thread): epoll (w>
Feb 16 20:28:31 canopus turnserver[895]: 0: : IO method (auth thread): epoll (w>
Feb 16 20:28:31 canopus turnserver[895]: 0: : IO method (auth thread): epoll (w>
Feb 16 20:28:31 canopus turnserver[895]: 0: : IO method (auth thread): epoll (w>
Feb 16 20:28:31 canopus turnserver[895]: 0: : IO method (auth thread): epoll (w>
Feb 16 20:28:31 canopus turnserver[895]: 0: : IO method (auth thread): epoll (w>
Feb 16 20:28:31 canopus turnserver[895]: 0: : IO method (auth thread): epoll (w>
Feb 16 20:28:31 canopus turnserver[895]: 0: : IO method (auth thread): epoll (w>
Feb 16 20:28:31 canopus turnserver[895]: 0: : IO method (admin thread): epoll (>
Feb 16 20:28:31 canopus turnserver[895]: 0: : SQLite DB connection success: /va> 

Eventually:
Job for turnserver.service failed because a timeout was exceeded.
See "systemctl status turnserver.service" and "journalctl -xe" for details.

This in the journal:
-- 
-- A start job for unit turnserver.service has finished with a failure.
-- 
-- The job identifier is 5447 and the job result is failed.

A bit short on information.

# systemctl status turnserver.service
● turnserver.service - coturn
   Loaded: loaded (/usr/lib/systemd/system/turnserver.service; enabled; vendor >
   Active: failed (Result: timeout) since Tue 2021-02-16 20:30:01 GMT; 3min 31s>
     Docs: man:coturn(1)
           man:turnadmin(1)
           man:turnserver(1)
  Process: 895 ExecStart=/usr/bin/turnserver -c /etc/turnserver/turnserver.conf>
  Process: 1102 ExecStopPost=/usr/bin/rm -f /var/run/turnserver/turnserver.pid >
 Main PID: 895 (code=killed, signal=TERM)

Feb 16 20:28:31 canopus turnserver[895]: 0: : IO method (auth thread): epoll (w>
Feb 16 20:28:31 canopus turnserver[895]: 0: : IO method (auth thread): epoll (w>
Feb 16 20:28:31 canopus turnserver[895]: 0: : IO method (auth thread): epoll (w>
Feb 16 20:28:31 canopus turnserver[895]: 0: : IO method (auth thread): epoll (w>
Feb 16 20:28:31 canopus turnserver[895]: 0: : IO method (admin thread): epoll (>
Feb 16 20:28:31 canopus turnserver[895]: 0: : SQLite DB connection success: /va>
Feb 16 20:30:01 canopus systemd[1]: turnserver.service: Start operation timed o>
Feb 16 20:30:01 canopus turnserver[895]: 0: : IO method (general relay thread):>
Feb 16 20:30:01 canopus systemd[1]: turnserver.service: Failed with result 'tim>
Feb 16 20:30:01 canopus systemd[1]: Failed to start coturn.

Three man pages to read.  According to coturn there should be examples in .../examples/scripts but there is nothing there for coturn.
According to coturn turnserver can be run from the command line without a config file.
$ turnserver -n .....
Most of the cli parameters refer to various database settings.  Since there are no databases set up on this system, that might have something to do with the fact that turnserver times out - it may be looking and waiting for something which does not exist.  None of the examples directories seem to exist either.
There is a /var/db/turndb which it might be possible to configure with turnadmin but only for a competent operator.

Correction to comment 12.  The example scripts do exist but there is no examples directory.
See /usr/share/doc/coturn/scripts/
e.g.
$ cd /usr/share/doc/coturn/scripts/basic
$ sh relay.sh
0: : Config file found: /etc/turnserver.conf
0: : Listener address to use: 127.0.0.1
0: : Listener address to use: ::1
0: : Relay address to use: 127.0.0.1
0: : Relay address to use: ::1
0: : 3000000 bytes per second allowed per session
0: : Config file found: /etc/turnserver.conf
0: : 
RFC 3489/5389/5766/5780/6062/6156 STUN/TURN Server
Version Coturn-4.5.2 'dan Eider'
0: : 
Max number of open files/sockets allowed for this process: 524288
0: : 
Due to the open files/sockets limitation,
max supported number of TURN Sessions possible is: 262000 (approximately)
0: : 

==== Show him the instruments, Practical Frost: ====

0: : TLS supported
0: : DTLS supported
0: : DTLS 1.2 supported
0: : TURN/STUN ALPN supported
0: : Third-party authorization (oAuth) supported
0: : GCM (AEAD) supported
0: : OpenSSL compile-time version: OpenSSL 1.1.0l  10 Sep 2019 (0x101000cf)
.....
0: : Domain name: 
0: : Default realm: ourcodeworld.com
0: : ERROR: 
CONFIG ERROR: -a and -z options cannot be used together.

$ cd ..
<Looked at readme.txt>
$ ./peer.sh
Seems to hang.

$ cd restapi
$ sudo ./secure_relay_secret.sh
0: : Config file found: /etc/turnserver.conf
0: : Listener address to use: 127.0.0.1
0: : Listener address to use: ::1
0: : Relay address to use: 127.0.0.1
0: : Relay address to use: ::1
0: : 3000000 bytes per second allowed per session
0: : Config file found: /etc/turnserver.conf
..........
0: : IO method (auth thread): epoll (with changelist)
0: : IO method (admin thread): epoll (with changelist)
0: : IPv4. CLI listener opened on : 127.0.0.1:5766
0: : SQLite DB connection success: /var/db/turndb
0: : New UID: turnserver(955)

It hangs there and may well be working.  No idea where to go from there though.

Unless anybody objects this update goes out.

Whiteboard: (none) => MGA7-64-OK

I got farther from these initial errors by filling out one by one things like realm and IP-address, so there is no time-out anymore. So I got to the point where it complained about no database specified and the allow loopbacks issue I mentioned above.
I found references to the CLI Len mentions, but that does not solve the problem of a service whihc should start at startup from its config file.
I have the feeling getting this all configured correctly would require hours of study and experiments, but I cann't afford that.

@Herman, in reply to comment 14.
"but I can't afford that" 
ACK, who can?  Thanks for following this up.  At least you know what "realm" means - I would have to research even that.  On the basis of our collective experience we should let this one go.

Just noticed an oddity relating to comment 13.

0: : New UID: turnserver(955)

$ id
uid=1000(lcl) gid=1000(lcl) groups=1000(lcl),952(turnserver),955(vboxusers)

??

Not so odd.  There is no user called vboxusers, only a group

Thanks for your efforts, guys. I had thought to give it a try using Herman's other tests as a guide, but because I'm completely out of my element I wouldn't have made it as far as you have.

Going to call this good enough. Validating. Advisory in Comment 3.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Advisory commited to SVN.

CVE: (none) => CVE-2020-26262
Keywords: (none) => advisory

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2021-0087.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED