Bug 23310 - openslp new security issue CVE-2017-17833
Summary: openslp new security issue CVE-2017-17833
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA5TOO MGA6-64-OK MGA5-32-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2018-07-16 20:34 CEST by David Walser
Modified: 2018-08-18 00:28 CEST (History)
6 users (show)

See Also:
Source RPM: openslp-2.0.0-8.mga6.src.rpm
CVE:
Status comment:


Attachments
Proof of concept trigger script for CVE-2018-12938/CVE-2017-17833 (3.47 KB, text/plain)
2018-07-21 18:45 CEST, Len Lawrence
Details
Possible procedure for PoC test (462 bytes, text/plain)
2018-07-21 18:59 CEST, Len Lawrence
Details

Description David Walser 2018-07-16 20:34:54 CEST
Ubuntu has issued an advisory on July 9:
https://usn.ubuntu.com/3708-1/

The Ubuntu CVE page links to the upstream commit that fixed it (but we should check Ubuntu's patch for any additional fixes, per their notes):
https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-17833.html

We'll also have to check the code in 2.0.0, as it may not be affected.

If we are affected, Mageia 5 and Mageia 6 are as well.
Comment 1 David Walser 2018-07-16 20:48:42 CEST
openSUSE has issued an advisory for this on July 14:
https://lists.opensuse.org/opensuse-updates/2018-07/msg00030.html

We should check their patch (which is actually for 2.0.0).

Whiteboard: (none) => MGA6TOO

Comment 2 Marja Van Waes 2018-07-17 15:27:28 CEST
Assigning to the registered maintainer.

CC: (none) => marja11
Assignee: bugsquad => cooker

Marja Van Waes 2018-07-17 15:32:59 CEST

QA Contact: (none) => security
Component: RPM Packages => Security

Comment 3 David Walser 2018-07-20 18:51:14 CEST
Fedora has issued an advisory for this on July 19:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/H4WB4SKVDGCKX5FZGDSCL7VOCERVQDS3/
Comment 4 Johnny A. Solbu 2018-07-21 11:06:56 CEST
Cauldron, mga6 and mga5 updated.

Source packages:
openslp-2.0.0-5.3.mga5.src.rpm

openslp-2.0.0-8.1.mga6.src.rpm

Ubuntu only ship the 1.x version, and the patch apparently applies to that also. This is why they have the version number in their advisory, which every distro apparently blindly copies. :-)

I found the details of the problem in a redhat closed-as-duplicate bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1596450

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

OpenSLP is vulnerable to a double freeing of memory that causes a crash in the slp_buffer:SLPBufferRealloc() function, which makes it vulnerable to a denial-of-service or remote code execution attack.

This update fixes that.

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17833

Whiteboard: MGA6TOO => MGA6TOO, MGA5TOO
Assignee: cooker => qa-bugs
Status: NEW => ASSIGNED

Comment 5 David Walser 2018-07-21 12:28:03 CEST
Advisory:
========================

Updated openslp packages fix security vulnerability:

OpenSLP is vulnerable to a double freeing of memory that causes a crash in the
slp_buffer:SLPBufferRealloc() function, which makes it vulnerable to a
denial-of-service or remote code execution attack (CVE-2017-17833).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17833
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/H4WB4SKVDGCKX5FZGDSCL7VOCERVQDS3/
========================

Updated packages in core/updates_testing:
========================
openslp-2.0.0-5.3.mga5
libslp1-2.0.0-5.3.mga5
libslp-devel-2.0.0-5.3.mga5
openslp-2.0.0-8.1.mga6
libslp1-2.0.0-8.1.mga6
libslp-devel-2.0.0-8.1.mga6

from SRPMS:
openslp-2.0.0-5.3.mga5.src.rpm
openslp-2.0.0-8.1.mga6.src.rpm

Version: Cauldron => 6
Whiteboard: MGA6TOO, MGA5TOO => MGA5TOO
CC: (none) => cooker

Comment 6 Len Lawrence 2018-07-21 18:39:35 CEST
Installed openslp-2.0.0.8 on Mageia 6, x86_64.
Downloaded the PoC script from https://dumpco.re/blog/openslp-2.0.0-double-free and modified the target address to that of a local machine, 192.168.1.3 (Unsure of what to do so this was a guess).  192.16.1.103 is the source machine.
Ran the script:
$ sudo python openslp-2.0.0-double-free-poc.py
Proof-of-concept heap massager and double-free trigger for openslp-2.0.0 slpd
Run this script before launching slpd and remember to update targetIp variable.
[-] Waiting for multicast service request from slpd...
[+] Got request! Sending reply to 192.168.1.103 427...
[-] Sending first Service Request to 127.0.0.1:427 from 127.0.0.1:34035...
[-] Waiting for response...

Started the slpd service and the script continued...

[+] Received 71 bytes from 127.0.0.1:427
[-] Sending  packet to (multicast) 239.255.255.253:427 from 192.168.1.3:34113...
[+] Got request! Sending reply to 192.168.1.103 34113...
[+] Received 56 bytes from 192.168.1.103:34113
[-] Connecting to 192.168.1.3:427...
Traceback (most recent call last):
  File "openslp-2.0.0-double-free-poc.py", line 68, in <module>
    tcpclientsock.connect((targetIp, 427))
  File "/usr/lib64/python2.7/socket.py", line 228, in meth
    return getattr(self._sock,name)(*args)
socket.error: [Errno 111] Connection refused

Need to fiddle with the ports on both sides.


This is an operational failure due to user ignorance.
The response should have ended with 
"  [+] Connected. Sending...
   [-] Sent packet to 192.168.245.191:427 from 192.168.245.191:39914...
   [+] Done!"

Since there is no connection the second part of the test cannot be executed;
< $ sudo ./slpd/slpd -d -c etc/slp.conf >
which should have returned the double free error message.
Either there is an authorization problem between the two machines or there is a problem with the ports.  Is the user supposed to open them  and which ones where?  Those mentioned may be arbitrary - no way of knowing.  427, 34035, 34113?

CC: (none) => tarazed25

Comment 7 Len Lawrence 2018-07-21 18:45:26 CEST
Created attachment 10288 [details]
Proof of concept trigger script for CVE-2018-12938/CVE-2017-17833

TargetIP needs to be adjusted to suit local user.
Comment 8 Johnny A. Solbu 2018-07-21 18:48:03 CEST
So, in english. 
Did the patch close the hole?
Comment 9 Len Lawrence 2018-07-21 18:59:17 CEST
Created attachment 10289 [details]
Possible procedure for PoC test
Comment 10 Len Lawrence 2018-07-21 19:02:01 CEST
Re comment 8 - no idea Johnny.  Still struggling to understand how to to run this PoC.  It is all untrodden ground.
Comment 11 Len Lawrence 2018-07-21 19:19:08 CEST
Tried opening the ports mentioned, at both ends then reran the script.  Some of the port numbers changed so it looks like those are arbitrary.  The connection failed again with a socket error - connection refused.  No idea why.  I can talk to the other machine on ssh using password authentication.  No idea how slp does it.
Comment 12 Len Lawrence 2018-07-21 20:00:49 CEST
Gave up on the PoC and updated the package.  Went hunting for some kind of guide  to using the protocol - the web talks about an easy to use interface for network service discovery but there does not seem to be any description of this interface that a newbie can understand so I am giving up on this.  Step up experts.
Comment 13 Len Lawrence 2018-07-21 22:07:25 CEST
Getting somewhere.  Wondered if the slpd server needed to be running on both machines.  Looks like it.  Made the connection this time after running the PoC command and then starting slpd on the source machine
# python openslp-2.0.0-double-free-poc.py
Proof-of-concept heap massager and double-free trigger for openslp-2.0.0 slpd
Run this script before launching slpd and remember to update targetIp variable.
[-] Waiting for multicast service request from slpd...
[+] Got request! Sending reply to 192.168.1.103 427...
[-] Sending first Service Request to 127.0.0.1:427 from 127.0.0.1:48537...
[-] Waiting for response...
[+] Received 71 bytes from 127.0.0.1:427
[-] Sending  packet to (multicast) 239.255.255.253:427 from 192.168.1.3:43725...
[+] Got request! Sending reply to 192.168.1.103 43725...
[+] Received 56 bytes from 192.168.1.103:43725
[-] Connecting to 192.168.1.3:427...
[+] Connected. Sending...
[-] Sent packet to 192.168.1.3:427 from 192.168.1.3:39636...
[+] Done!

The server was started from another terminal when the "Waiting for multicast..." message came up.  The handshaking continued and the connection succeeded without any error message.

Still not sure if things have been done correctly but it looks as if the exploit had been squashed already, before the update.  My uneasiness stems from the difference in the output messages which implies a second pause (which did not happen here).  Could be network latency for upstream.
Upstream reports:
  [-] Waiting for multicast service request from slpd...
  [+] Got request! Sending reply to 192.168.245.191 427...
  [-] Sending first Service Request to 127.0.0.1:427 from 127.0.0.1:53309...
  [-] Waiting for response...
  [+] Received 71 bytes from 127.0.0.1:427
  [-] Sending  packet to (multicast) 239.255.255.253:427 from 192.168.245.191:41965...
  [+] Got request! Sending reply to 192.168.245.191 41965...
* [-] Waiting for response from bad-multicast-server.py...
  [+] Received 71 bytes from 192.168.245.191:427
  [-] Connecting to 192.168.245.191:427...
  [+] Connected. Sending...
  [-] Sent packet to 192.168.245.191:427 from 192.168.245.191:39914...
  [+] Done!


Updated the three packages.

Ran the PoC test without any change in the behaviour.  Connection succeeded and no heap error reported.  Note that the other machine was running the pre-update version of the server.

My tentative conclusion is that the fault has been repaired.  Unable to test functionality though.  Leaving that to somebody else.
Comment 14 Herman Viaene 2018-07-24 11:08:21 CEST
MGA5-32 Xfce on Dell Latitude D600
No installation issues.
Running some slptool commands return nothing , ex...
$ slptool findsrvtypes
$ slptool findsrvs service:nfs
Googling brought me to 
http://www.openslp.org/doc/html/UsersGuide/Installation.html
The "Testing" section describes exactly what happens here: if the PC providing netservices (in my case nfs) does not run the slpd service, you get nowhere.
I don't want to use my main desktop PC providing netservices to be involved in testing stuff, so that's the end of the line for now. And I won't even try to run netservices on this test laptop, just browsing is already not so pleasant.

CC: (none) => herman.viaene

Comment 15 Herman Viaene 2018-07-24 11:58:42 CEST
Got my x86-64 laptop with a testpartition to run nfs server and the slpd test version, opened nfs port in MCC and 427/tcp and 427/udp on it.
Opened 427/tcp and 427/udp on this M5 laptop, tested with telnet that the ports where reachable, made the nfs client connection to work OK.
Used the same spltool as above in Comment 4 on both the M5 testing client as well on the serving laptop, both no output on the commands.
Comment 16 Herman Viaene 2018-07-24 14:01:42 CEST
Found out using https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_slp_sl_reg.html that I needed to edit the /etc/slp.reg file on the server adding nfs like in the example given. Now the slptool commands give a correct answer on the serving laptop itself, but not on the client.
Comment 17 Len Lawrence 2018-07-27 08:19:30 CEST
Using Herman'ssuggestions to retread this and confirm his conclusions.

# slptool findsrvs service:service-agent
service:service-agent://192.168.1.103,65535
service:service-agent://192.168.122.1,65535
service:service-agent://192.168.1.3,65535

slpd is running on 192.168.1.3 and .103

# slptool findsrvtypes
# slptool findsrvs service:nfs

NFS is running on .3 and .103 machines and others in the network.
After modifying /etc/slp.reg as indicated by Herman in comment 16
# slptool findsrvtypes
service:ssh.openslp
service:nfs.openslp
But this does not work:
# slptool findsrvs service:nfs
# slptool findsrvs service:ssh

# slptool findsrvs service:ssh.openslp
service:ssh.openslp://192.168.1.103,65535
Note that this discovers only the service on the local host even though the same procedures have been followed on a neighbouring machine.  slpd was restarted after each edit.

So these tests confirm Herman's conclusions and leave us a bit up in the air.  OK or not?
Comment 18 Len Lawrence 2018-07-27 08:26:14 CEST
Re comment 17:

Ran the PoC test again.
Stopped slpd.
$ sudo python openslp-2.0.0-double-free-poc.py
Proof-of-concept heap massager and double-free trigger for openslp-2.0.0 slpd
Run this script before launching slpd and remember to update targetIp variable.
[-] Waiting for multicast service request from slpd...
[+] Got request! Sending reply to 192.168.1.103 427...
[-] Sending first Service Request to 127.0.0.1:427 from 127.0.0.1:53869...
[-] Waiting for response...

Started slpd.

[+] Received 71 bytes from 127.0.0.1:427
[-] Sending  packet to (multicast) 239.255.255.253:427 from 192.168.1.3:36382...
[+] Got request! Sending reply to 192.168.122.1 427...
[+] Received 49 bytes from 192.168.122.1:427
[-] Connecting to 192.168.1.3:427...
[+] Connected. Sending...
[-] Sent packet to 192.168.1.3:427 from 192.168.1.3:57458...
[+] Done!

This looks cleaner so the PoC tests is probably good.
Comment 19 Len Lawrence 2018-08-14 20:25:16 CEST
This has been hanging about a while.  On the basis of a clean intall and the probable good result from the PoC test I am pushing this through.

That can always be undone.  mga5 still needs an OK.

Whiteboard: MGA5TOO => MGA5TOO MGA6-64-OK

Herman Viaene 2018-08-16 21:59:27 CEST

Whiteboard: MGA5TOO MGA6-64-OK => MGA5TOO MGA6-64-OK MGA5-32-OK

Len Lawrence 2018-08-17 02:06:02 CEST

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

Thomas Backlund 2018-08-17 23:31:14 CEST

CC: (none) => tmb
Keywords: (none) => advisory

Comment 20 Mageia Robot 2018-08-18 00:28:40 CEST
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0342.html

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


Note You need to log in before you can comment on or make changes to this bug.