DISC InfoSec blog

Just before the Christmas weekend – in fact, at about the same time that beleaguered password management service LastPass was admitting that, yes, your password vaults were stolen by criminals after all – we noticed a serious-sounding Linux kernel vulnerability that hit the news.

The alerts came from Trend Micro’s Zero Day Initiative (ZDI), probably best known for buying up zero-day security bugs via the popular Pwn2Own competitions, where bug-bounty hunting teams compete live on stage for potentially large cash prizes.

In return for sponsoring the prize money, the vendors of products ranging from operating systems and browsers to networked printers and internet routers hope to buy up brand new security flaws, so they can fix the holes responsibly. (To collect their prizes, participants have to provide a proper write-up, and agree not to share any information about the flaw until the vendor has had a fair chance to fix it.)

But ZDI doesn’t just deal in competitive bug hunting in its twice-a-year contests, so it also regularly puts out vulnerability notices for zero-days that were disclosed in more conventional ways, like this one, entitled Linux Kernel ksmbd Use-After-Free Remote Code Execution Vulnerability.

Serving Windows computers via Linux

SMB is short for server message block, and it’s the protocol that underpins Windows networking, so almost any Linux server that provides network services to Windows computers will be running software to support SMB.

As you can therefore imagine, SMB-related security bugs, especially ones that can be exploited over the network without the attacker needing to logon first, as is the case here, are potentially serious issues for most large corporate networks.

SMB support is also generally needed in home and small-business NAS (network attached storage) devices, which generally run Linux internally, and provide easy-to-use, plug-it-in-and-go file server features for small networks.

No need to learn Linux yourself, or to set up a full-blown server, or to learn how to configure Linux networking – just plug-and-play with the NAS device, which has SMB support built-in and ready to go for you.

Why the holiday timing?

In this case, the bug wasn’t deliberately disclosed on the night before the night before the night before Christmas in a not-so-ho-ho-ho bid to spoil your festive season by freaking you out.

And it wasn’t reported just before the weekend in a bid to bury bad PR by hoping you’d be vacation-minded enough either to miss the story completely or to shrug it off until the New Year.

The good news is that, as usually happens under the umbrella of responsible disclosure, the date for ZDI’s report was agreeed in advance, presumably when the flaw was disclosed, thus giving the Linux kernel team sufficient time to fix the problem properly, while nevertheless not allowing them to put the issue off indefinitely.

In this case, the bug report is listed as having happened on 2022-07-26, and what ZDI refers to as the “co-ordinated public release of [the] advisory” was set for 2022-12-22, which turns out to be exactly 150 days, if you count old-school style and include the full day at each end.

So, even though this bug has had some dramatic coverage over the holiday weekend, given that it was a remote code execution (RCE) hole in the Linux kernel itself, and came with a so-called CVSS score of 10/10, considered Critical…

…it was patched in the Linux source code within just two days of disclosure, and the fix was accepted and packaged into the official Linux kernel source code in time for the release of Linux 5.15.61, back on 2022-08-17, just 23 days after the report first came in.

In other words, if you’ve updated your Linux kernel any time since then, you’re already safe, no matter what kernel compilation settings you or your distro used. (This includes 24 subsequent updates to the kernel 5.15 series, now at 5.15.85, along with any versions of kernel 6.0, kernel 6.1 and the still-in-candidate-stage kernel 6.2, all of which had their first releases after August 2022.)

Probably not the SMB software you suspect

Also, although it sounds at first glance as though this bug will inevitably affect any Linux server or device supporting Windows networking, that’s not true either.

Most sysadmins, and in our experience most NAS programmers, provide Windows SMB supprt via a long-running and well-respected open source toolkit called Samba, where the name Samba is simply the closest pronounceable word that the original developer, open-source luminary Andrew “Tridge” Tridgell OAM, could find to represent the abbreviation SMB.

Anyone who has used Samba will know that the software runs as a regular application, in what’s known as user space, in other words, without needing its own code running inside the kernel, where even modest bugs could have dangerous repercussions.

Indeed, the main Samba program file is called smbd, where the trailing -D is a typical Unixism standing for daemon, or background process – what Windows admins would call a service.

This bug, as you can see from the ZDI report, is in a kernel module called ksmbd, where the -D denotes a background service, the -SMB- denotes Windows networking support, and the K- means runs in kernel space, i.e. right inside the kernel itself.

At this point, you’re probably asking yourself, “Why bury the complexity of supporting SMB right into the kernel, given that we’ve already got a reliable and well-respected user-space product in the form of Samba, and given that the risks are much greater?”

Why, indeed?

As so often, there seem to be two main reasons: [A] because we can! and [B] because performance.

By pushing what are typically high-level software features down into the kernel, you can often improve performance, though you almost always pay the price of a corresponding, and possibly considerable, decrease in safety and security.

What to do?

• Check if you have a Linux kernel based on any release on or after 5.15.61 (dated 2022-08-17). If so, this bug is fixed in the source code. No matter what kernel compilation options you (or your distro maker) choose, the bug can’t and won’t exist on your system.
• Check if your Linux kernel build even includes ksmbd. Most popular distros neither compile it in, nor build it as a module, so you can’t load it or activate it, even by mistake.
• Check with your vendor if you are using an applicance such as a NAS box or other device that supports connections from Windows computers. Chances are that your NAS device won’t be using ksmbd, even if it still has a kernel version that is vulnerable in theory.
• If you’re using ksmbd out of choice, consider re-evaluating your risk. Make sure you measure the true increase in performance you’ve achieved, and decide whether the payoff is really worth it.

COMMANDS YOU CAN USE TO CHECK YOUR EXPOSURE

Any Linux from 5.15.61 on, or any 6.x, is already patched. 
To check your Linux version:

  $ uname -o -r
  6.1.1 GNU/Linux     

To see if this kernel feature is compiled in, you can dump the 
compile-time configuration of the running kernel:

  $ zcat /proc/config.gz | grep SMB_SERVER
  # CONFIG_SMB_SERVER is not set

If this compile-time configuration setting is unset, or set to 
"n" for no, the feature wasn't built at all.

If it says "y" for yes, then the kernel SMB server is compiled 
right into your kernel, so ensure you have a patched version.

If it says "m" for module, then the kernel build probably 
includes a run-time module that can be loaded on demand.

To see if your kernel has a loadable module available:

  $ /sbin/modprobe --show ksmbd
  modprobe: FATAL: Module ksmbd not found in directory /lib/modules/6.1.1

Note that "--show" means "do not actually do it, just show 
if loading it would actually work or not".

To see if your system has the ksmbd module already active:

  $ lsmod | grep ksmbd

If you see no output, the module wasn’t matched in the list.

To stop the module loading in case it ever shows up, add a 
file with a name such as ksmbd.conf to the directory 
/lib/modules.d or /etc/modules.d with this line in it:

  blacklist ksmbd

Mastering Linux Security and Hardening: Protect your Linux systems from intruders, malware attacks, and other cyber threats

Infosec books | InfoSec tools | InfoSec services

Tags: Linux Security, Mastering Linux Security and Hardening

Microsoft disclosed two Linux privilege escalation flaws, collectively named Nimbuspwn, that could allow conducting various malicious activities.

The Microsoft 365 Defender Research Team has discovered two Linux privilege escalation flaws (tracked as CVE-2022-29799 and CVE-2022-29800) called “Nimbuspwn,” which can be exploited by attackers to conduct various malicious activities, including the deployment of malware.

“The vulnerabilities can be chained together to gain root privileges on Linux systems, allowing attackers to deploy payloads, like a root backdoor, and perform other malicious actions via arbitrary root code execution.” reads the advisory published by Microsoft.

The flaws can be exploited by attackers to achieve root access to the target systems and deploy by more sophisticated threats, such as ransomware.

The flaws reside in the systemd component called networked-dispatcher, which is dispatcher daemon for systemd-networkd connection status changes.

The review of the code flow for networkd-dispatcher revealed multiple security issues, including directory traversal, symlink race, and time-of-check-time-of-use race condition issues.

The researchers started enumerating services that run as root and listen to messages on the System Bus, performing both code reviews and dynamic analysis.

Chaining the issues, an attacker in control of a rogue D-Bus service that can send an arbitrary signal, can deploy backdoors on the compromised final touches.

he researchers were able to develop their own exploit that runs an arbitrary script as root. The exploit also copies /bin/sh to the /tmp directory, sets /tmp/sh as a Set-UID (SUID) executable, and then invokes “/tmp/sh -p”. (the “-p” flag is necessary to force the shell to not drop privileges)

Researchers recommend users of networkd-dispatcher to update their installs.

“To address the specific vulnerabilities at play, Microsoft Defender for Endpoint’s endpoint detection and response (EDR) capabilities detect the directory traversal attack required to leverage Nimbuspwn.” concludes the post.

Mastering Linux Security and Hardening

👇 Please Follow our LI page…

DISC InfoSec

#InfoSecTools and #InfoSectraining

#InfoSecLatestTitles

#InfoSecServices

Tags: Linux Security, Mastering Linux Security and Hardening