This Samba new vulnerability is already being called "Sambacry", while the exploit itself mentions "Eternal Red Samba", announced in twitter (sensationally) as:
Samba bug, the metasploit one-liner to trigger is just:
simple.create_pipe("/path/to/target.so")
Potentially affected Samba versions are from Samba 3.5.0 to 4.5.4/4.5.10/4.4.14.
If your Samba installation meets the configurations described bellow, the fix/upgrade should be done ASAP as there are already exploits, other exploit in python and
metasploit modules out there.
More interestingly enough, there are already add-ons to a know honeypot from the honeynet project, dionaea both to WannaCry and SambaCry plug-ins.
Samba cry seems to be already being (ab)used to install more crypto-miners "EternalMiner" or double down as a malware dropper in the future.
honeypots set up by the team of researchers from Kaspersky Lab have
captured a malware campaign that is exploiting SambaCry vulnerability
to infect Linux computers with cryptocurrency mining software. Another
security researcher, Omri Ben Bassat, independently discovered the
same campaign and named it "EternalMiner."
The advised workaround for systems with Samba installed (which also is present in the CVE notice) before updating it, is adding to smb.conf
:
nt pipe support = no
(and restarting the Samba service)
This is supposed to disable a setting that turns on/off the ability to make anonymous connections to the windows IPC named pipes service. From man samba
:
This global option is used by developers to allow or disallow Windows
NT/2000/XP clients the ability to make connections to NT-specific SMB
IPC$ pipes. As a user, you should never need to override the default.
However from our internal experience, it seems the fix is not compatible with older? Windows versions ( at least some? Windows 7 clients seem to not work with the nt pipe support = no
), and as such the remediation route can go in extreme cases into installing or even compiling Samba.
More specifically, this fix disable shares listing from Windows clients, and if applied they have to manually specify the full path of the share to be able to use it.
Other known workaround is to make sure Samba shares are mounted with the noexec
option. This will prevent the execution of binaries residing on the mounted filesystem.
The official security source code patch is here from the samba.org security page.
Debian already pushed yesterday (24/5) an update out the door, and the corresponding security notice DSA-3860-1 samba
To verify in if the vulnerability is corrected in Centos/RHEL/Fedora and derivates, do:
#rpm -q –changelog samba | grep -i CVE
– resolves: #1450782 – Fix CVE-2017-7494
– resolves: #1405356 – CVE-2016-2125 CVE-2016-2126
– related: #1322687 – Update CVE patchset
There is now an nmap
detection script :samba-vuln-cve-2017-7494.nse
for detecting Samba versions, or a much better nmap
script that checks if the service is vulnerable at http://seclists.org/nmap-dev/2017/q2/att-110/samba-vuln-cve-2017-7494.nse , copy it to /usr/share/nmap/scripts
and then update the nmap
database , or run it as follows:
nmap --script /path/to/samba-vuln-cve-2017-7494.nse -p 445 <target>
About long term measures to protect the SAMBA service: The SMB protocol should never be offered directly to the Internet at large.
It goes also without saying that SMB has always been a convoluted protocol, and that these kind of services ought to be firewalled and restricted to the internal networks [to which they are being served].
When remote access is needed, either to home or specially to corporate networks, those accesses should be better done using VPN technology.
As usual, on this situations the Unix principle of only installing and activating the minimum services required does pay off.
Taken from the exploit itself:
Eternal Red Samba Exploit -- CVE-2017-7494.
Causes vulnerable Samba server to load a shared library in root context.
Credentials are not required if the server has a guest account.
For remote exploit you must have write permissions to at least one share.
Eternal Red will scan the Samba server for shares it can write to.
It will also determine the fullpath of the remote share.
For local exploit provide the full path to your shared library to load.
Your shared library should look something like this
extern bool change_to_root_user(void);
int samba_init_module(void)
{
change_to_root_user();
/* Do what thou wilt */
}
It is also known systems with SELinux enabled are not vulnerable to the exploit.
See 7-Year-Old Samba Flaw Lets Hackers Access Thousands of Linux PCs Remotely
According to the Shodan computer search engine, more than 485,000
Samba-enabled computers exposed port 445 on the Internet, and
according to researchers at Rapid7, more than 104,000 internet-exposed
endpoints appeared to be running vulnerable versions of Samba, out of
which 92,000 are running unsupported versions of Samba.
Since Samba is
the SMB protocol implemented on Linux and UNIX systems, so some
experts are saying it is "Linux version of EternalBlue," used by the
WannaCry ransomware.
...or should I say SambaCry?
Keeping in mind the
number of vulnerable systems and ease of exploiting this
vulnerability, the Samba flaw could be exploited at large scale with
wormable capabilities.
Home networks with network-attached storage
(NAS) devices [that also run Linux] could also be vulnerable to this flaw.
See also A wormable code-execution bug has lurked in Samba for 7 years. Patch now!
The seven-year-old flaw, indexed as CVE-2017-7494, can be reliably
exploited with just one line of code to execute malicious code, as
long as a few conditions are met. Those requirements include
vulnerable computers that:
(a) make file- and printer-sharing port 445
reachable on the Internet,
(b) configure shared files to have write
privileges, and
(c) use known or guessable server paths for those
files.
When those conditions are satisfied, remote attackers can
upload any code of their choosing and cause the server to execute it,
possibly with unfettered root privileges, depending on the vulnerable
platform.
Given the ease and reliability of exploits, this hole is worth
plugging as soon as possible. It's likely only a matter of time until
attackers begin actively targeting it.
Also Rapid 7 - Patching CVE-2017-7494 in Samba: It’s the Circle of Life
And more SambaCry: The Linux Sequel to WannaCry.
Need-to-Know Facts
CVE-2017-7494 has a CVSS Score of 7.5
(CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)3.
Threat Scope
A shodan.io query of "port:445 !os:windows" shows approximately one
million non-Windows hosts that have tcp/445 open to the Internet, more
than half of which exist in the United Arab Emirates (36%) and the
U.S. (16%). While many of these may be running patched versions,
have SELinux protections, or otherwise don't match the necessary
criteria for running the exploit, the possible attack surface for this
vulnerability is large.
P.S. The commit fix in the SAMBA github project appear to be commit 02a76d86db0cbe79fcaf1a500630e24d961fa149
Best Answer
Darling (link) is a project that aims to become analogous to wine.
Currently it only runs some command-line OSX programs, though.As of mid-2019, it can run many command-line programs, and according to their homepage appears to be approaching the point where it can run some rudimentary graphical software as well. It probably won't run what you want just yet, unless it's text-based.As long as the developers of the OS X program released their source code and used cross-platform libraries (such as QT, GTK, X11, GNUStep or WxWidgets) you should be able to re-compile an OS X program for linux. OS X and Linux are much more compatible at the API level than the ABI level.
GNUStep implements the Cocoa APIs of NeXTStep and OS X. It was shockingly complete when I tried it, in terms of how much it seemed capable of doing versus how little seems to use it in the wild. GNUStep only works on the source-code (API) level, so it works if a program is open-source and uses Apple's Cocoa GUI (NOT "Aqua" which is proprietary). It depends on being able to compile and link the code.
Think of the API, or Application Programming Interface, as something like a car's dashboard - everything is visible to the driver of the car, and you can get into someone else's car and find his different dashboard just as easy to figure out.
Think of the ABI, or Application Binary Interface, as the engine of the car - it can vary greatly between makes and models, and you probably won't be able to trade your Chevy engine into a Volvo very easily.
Darling would in this analogy be putting the Chevy engine in a Volvo's chassis, and compiling from source would be like just getting out of your Chevy and getting into the Volvo. One is much simpler to do than the other from a programmers' perspective.
But Apple has some proprietary user interface libraries that no one else has, too. If the developer used one of these (such as Aqua), you'll have to wait and hope that Darling grows up like Wine did, or port it yourself. If there is no source code released, it'd be like if the engine was made so big that it could not fit in the Volvo's engine bay, or designed for connecting to a front wheel drive car where your Volvo was rear wheel drive. Unless someone is an absolutely insane maniac (in the best possible way) who has months of free time and ridiculous amount of dedication, it's not likely to happen.
Additionally, GNUStep is not 100% complete in terms of coverage of the Cocoa API's, so some shoehorning is likely still going to be necessary for complex programs. And GNUStep does not provide an xcode-equivalent build system - that is, if the original developer used the XCode IDE's "build" system exclusively, you may be left writing makefiles for it. This was the most frustrating part for me, since while I have experience with compiling and linking software, it's hard to wrestle useful information out of a format like a .xcodeproj that I have no prior backend experience with.