Sequoia Vulnerability

Hello!

I learned of a vulnerability found in the Linux Kernel recently. It was released by the Qualys community:

From what I saw in some Brazilian forums, it seems that the correction should only be done via Kernel patch.

As it affects all systems built after the 2014 Kernel release, I believe it affects all Zorin releases. Is there a way to set up a procedure for us, Zorin users?

2 Likes

A procedure is unneeded as the Zorin Group will roll through a patch that will arrive and give an alert on your system updater.

From what I have read of this vulnerability (after you posted your O.P.), I would not be overly concerned.
The malicious hacker would need direct access to your machine (not telnet), and would have to create a new partition. For that kind of activity, either your computer was stolen or you are living with a hacker.

2 Likes

My husband can attest that one :rofl:

2 Likes

Understood.

But is there any way for an external attacker to gain access to directories through the Kernel, so that he can change some characters and get the administrator privilege?

Because as much as it doesn't know the directory structure of a specific user, it can change the characters of a Linux system directory path (like /usr/share/, or /home/documents... ) and get the privilege. Or nothing to see?

Anyway... the correction of this vulnerability must be done directly in the Kernel, so just wait for the update of both the Kernel and the Systems.

There is no way that I can see - since as pointed out above, the malicious actor needs access to the physical machine in order to create a new separate partition on your drive from which to launch their attack.
https://www.qualys.com/2021/07/20/cve-2021-33909/sequoia-local-privilege-escalation-linux.txt
In order to create the partition from afar, you would need to already have Root Access.

Please keep in mind, Qaylays is a company selling Security.
That said, they also list:

Are there any mitigations for this vulnerability?
The following mitigations prevent only our specific exploit from working (but other exploitation techniques may exist); to completely fix this vulnerability, the kernel must be patched.
-Set /proc/sys/kernel/unprivileged_userns_clone to 0, to prevent an attacker from mounting a long directory in a user namespace. However, the attacker may mount a long directory via FUSE instead; we have not fully explored this possibility, because we accidentally stumbled upon CVE-2021-33910 in systemd: if an attacker FUSE-mounts a long directory (longer than 8MB), then systemd exhausts its stack, crashes, and therefore crashes the entire operating system (a kernel panic).
-Set /proc/sys/kernel/unprivileged_bpf_disabled to 1, to prevent an attacker from loading an eBPF program into the kernel. However, the attacker may corrupt other vmalloc()ated objects instead (for example, thread stacks), but we have not investigated this possibility.

2 Likes