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.
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
Assigning to the registered maintainer.
CC: (none) => marja11Assignee: bugsquad => cooker
Component: RPM Packages => SecurityQA Contact: (none) => security
Fedora has issued an advisory for this on July 19: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/H4WB4SKVDGCKX5FZGDSCL7VOCERVQDS3/
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
Assignee: cooker => qa-bugsWhiteboard: MGA6TOO => MGA6TOO, MGA5TOOStatus: NEW => ASSIGNED
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
CC: (none) => cookerWhiteboard: MGA6TOO, MGA5TOO => MGA5TOOVersion: Cauldron => 6
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
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.
So, in english. Did the patch close the hole?
Created attachment 10289 [details] Possible procedure for PoC test
Re comment 8 - no idea Johnny. Still struggling to understand how to to run this PoC. It is all untrodden ground.
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.
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.
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.
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
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.
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.
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?
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.
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
Whiteboard: MGA5TOO MGA6-64-OK => MGA5TOO MGA6-64-OK MGA5-32-OK
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Keywords: (none) => advisoryCC: (none) => tmb
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0342.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED