Newly Discovered Vulnerability Raises Fears Of Another WannaCry (reuters.com)
A newly found flaw in widely used networking software leaves tens of thousands of computers potentially vulnerable to an attack similar to that caused by WannaCry, which infected more than 300,000 computers worldwide, cybersecurity researchers said on Thursday. From a Reuters report: The U.S. Department of Homeland Security on Wednesday announced the vulnerability, which could be exploited to take control of an affected computer, and urged users and administrators to apply a patch. Rebekah Brown of Rapid7, a cybersecurity company, told Reuters that there were no signs yet of attackers exploiting the vulnerability in the 12 hours since its discovery was announced. But she said it had taken researchers only 15 minutes to develop malware that made use of the hole. "This one seems to be very, very easy to exploit," she said. Rapid7 said it had found more than 100,000 computers running vulnerable versions of the software, Samba, free networking software developed for Linux and Unix computers.
https://gcn.com/articles/2017/...
https://www.samba.org/samba/se...
https://www.samba.org/samba/security/CVE-2017-7494.html
===========
Description
===========
All versions of Samba from 3.5.0 onwards are vulnerable to a remote
code execution vulnerability, allowing a malicious client to upload a
shared library to a writable share, and then cause the server to load
and execute it.
==========
Workaround
==========
Add the parameter:
nt pipe support = no
to the [global] section of your smb.conf and restart smbd. This
prevents clients from accessing any named pipe endpoints. Note this
can disable some expected functionality for Windows clients.
Actually, it's a completely optional daemon that runs on top of Linux to support Windows clients from Linux or let Linux be a client for Windows drive sharing. It's not part of the OS, it's not mandatory to run with the OS, it's not related to the running of an all-Linux network, and it's based on specifications from the Windows folks.
Yup. But it IS very widely used. Though hopefully it's only very, very rarely exposed to the internet.
Don't disappoint your bird dog. Go to the range.
This one is on Linux, but it's not as bad as the headline makes it seem. You need write access to a shared drive over Samba for it to be effective. Wannacry iirc could attack clients, not just servers, and write access wasn't necessary.
I'll be honest, if you're giving remote anonymous write access to your Samba share on the open internet, you should probably stop doing that. Figure out another way to achieve that goal.
"First they came for the slanderers and i said nothing."
For these critical info, a quick search on Google news got me this.
Extract:
All versions of Samba from 3.5.0 onwards are vulnerable to a remote code execution vulnerability, allowing a malicious client to upload a shared library to a writable share, and then cause the server to load and execute it. A patch addressing this defect has been posted to http://www.samba.org/samba/security/ Additionally, Samba 4.6.4, 4.5.10 and 4.4.14 have been issued as security releases to correct the defect. Patches against older Samba versions are available at http://samba.org/samba/patches.... Samba vendors and administrators running affected versions are advised to upgrade or apply the patch as soon as possible.
The vulnerability has a lot of prerequisites:
- You need write access to a shared
- You need to know the underlying directory structure
- You end up with a shell as user "nobody"
Sure it's bad, but it's not WannaCry bad. At best you get a shell to execute some replication code, at worst you get nothing (modern SELinux, Solaris etc refuse execution rights to nobody).
Custom electronics and digital signage for your business: www.evcircuits.com
Yes, that is the core of the bug. However, I can offer some explanation into how it happened.
There are 2 subsystems involved here.
(1). Load a shared library module and execute it.
This has many uses inside Samba.
(2). Allow a client request on an RPC pipe to be routed to an external process or library.
This allows Samba to be built without embedding all the named pipe services inside it, which makes it a smaller binary for embedded vendors.
Unfortunately an old commit connected the two subsystems together, re-using the shared library module existing code to find and load the service the client was asking for. There was insufficient sanitization of the requesting name which caused the problem.
The commit happened in 2009, before we had two-engineer design and review practices and the full regression test suite we now use.
Eventually I want to remove the ability to load any shared modules containing more than one path component. This has to be done carefully however to avoid breaking existing configured systems that may depend on this.
If you did a minimal install and installed all your stuff manually, never installed samba, you are safe. BUT just to make sure, issue the command: smbstatus
If you get an output other than -bash: smbstatus: command not found, double validate if it is running.
Using systemd:
systemctl status smb
If you get an output different than Unit smb.service could not be found., you can assume samba is installed. You either make sure it is disabled (systemctl disable smb), or you update it.
FWIW, it looks like running lsof -i will tell unix users what ports are open. If port 445 is open, you might want to kill smbd while you sort things out. Purportedly adding "nt pipe support = no" to your smb.conf file and restarting smbd might allow some samba capability while still stopping the threat. See
https://www.samba.org/samba/se...
Note: If this advice turns your system into a quivering ball of protoplasm, Don't blame me. I'm only the messenger.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
Though hopefully it's only very, very rarely exposed to the internet
Shodan only lists 485000 instances of samba exposing port 445 to the internet. ...
Don't assume Linux admins are immune to stupid.