A total of five vulnerabilities that could lead to local privilege escalation were recently identified and fixed in the Linux kernel.
Identified by Positive Technologies security researcher Alexander Popov, the high severity bugs resided in the virtual socket implementation of the Linux kernel.
Experts found five vulnerabilities in the Linux kernel, tracked as CVE-2021-26708, that could lead to local privilege escalation.
Positive Technologies researcher Alexander Popov found five high severity vulnerabilities in the Linux kernel that could lead to local privilege escalation.
The Linux kernel vulnerabilities are race conditions that reside in AF_VSOCK implementation, they were implicitly introduced in November 2019 in the commits c0cfa2d8a788fcf4 and 6a2c0962105ae8ce that added VSOCK multi-transport support.
A race condition is the condition of an electronics, software, or other system where the system’s substantive behavior is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when one or more of the possible behaviors is undesirable.
The race conditions stems in wrong locking in net/vmw_vsock/af_vsock.c.
“CONFIG_VSOCKETS and CONFIG_VIRTIO_VSOCKETS are shipped as kernel modules in all major GNU/Linux distributions. The vulnerable modules are automatically loaded when you create a socket for AF_VSOCK. That is available for unprivileged users and user namespaces are not needed for that. These vulnerabilities are race conditions caused by wrong locking in net/vmw_vsock/af_vsock.c.” wrote Popov. “The race conditions were implicitly introduced in November 2019 in the commits c0cfa2d8a788fcf4 and 6a2c0962105ae8ce that added VSOCK multi-transport support. These commits were merged in the Linux kernel v5.5-rc1.”
The issues, collectively tracked as CVE-2021-26708, were introduced in kernel version 5.5 in November 2019, they received a CVSS score of 7.0,
The expert successfully developed a PoC exploit for local privilege escalation on Fedora 33 Server, it could allow bypassing x86_64 platform protections such as SMEP and SMAP.
The patch has been merged into mainline kernel version 5.11-rc7 and backported into affected stable trees.
Popov discovered other Linux kernel flaws in the past, including CVE-2019-18683 and CVE-2017-2636 vulnerabilities.
If you want to receive the weekly Security Affairs Newsletter for free subscribe here.
Follow me on Twitter: @securityaffairs and Facebook
(SecurityAffairs – hacking, Linux)
The post Five privilege escalation flaws fixed in Linux Kernel appeared first on Security Affairs.
Reading Time: ~ 3 min.
Why do so many businesses allow unfettered access to their networks? You’d be shocked by how often it happens. The truth is: your employees don’t need unrestricted access to all parts of our business. This is why the Principle of Least Privilege (POLP) is one of the most important, if overlooked, aspects of a data security plan.
When we say “least privilege”, what we actually mean is “appropriate privilege”, or need-to-know. Basically, this kind of approach assigns zero access by default, and then allows entry as needed. (This is pretty much the opposite of what many of us are taught about network access.) But by embracing this principle, you ensure that network access remains strictly controlled, even as people join the company, move into new roles, leave, etc. Obviously, you want employees to be able to do their jobs; but, by limiting initial access, you can minimize the risk of an internal breach.
If you haven’t already, now is the perfect time to take a look at your network access policies. After all, it’s about protecting your business and customers—not to mention your reputation.
Listen to the podcast: Episode 6 | Shoring Up Your Network Security with Strong Policies to learn more about implementing the Principle of Least Privilege and other network security best practices.
Navigating the difficult conversations around access control
It’s no surprise that employees enjoy taking liberties at the workplace. In fact, Microsoft reports that 67% of users utilize their own devices at work. Consequently, they may push back on POLP policies because it means giving up some freedom, like installing personal software on work computers, using their BYOD in an unauthorized fashion, or having unlimited usage of non-essential applications.
Ultimately, you need to prepare for hard conversations. For example, you’ll have to explain that the goal of Principle of Least Privilege is to provide a more secure workplace for everyone. It’s not a reflection on who your employees are or even their seniority; it’s about security. So, it’s essential for you, the MSP or IT leader, to initiate the dialogue around access control––often and early. And, at the end of the day, it’s your responsibility to implement POLP policies that protect your network.
Firewalls and antivirus aren’t enough
There’s a common misconception in cybersecurity that the firewall and/or antivirus is all you need to stop all network threats. But they don’t protect against internal threats, such as phishing or data theft. This is where access policies are necessary to fill in the gaps.
Here’s a prime example: let’s say you have an employee whose job is data entry and they only need access to a few specific databases. If malware infects that employee’s computer or they click a phishing link, the attack is limited to those database entries. However, if that employee has root access privileges, the infection can quickly spread across all your systems.
Cyberattacks like phishing, ransomware, and botnets are all designed to circumvent firewalls. By following an appropriate privilege model, you can limit the number of people who can bypass your firewall and exploit security gaps in your network.
Tips to achieve least privilege
When it comes to implementing POLP in your business, here are some tips for getting started:
- Conduct a privilege audit. Check all existing accounts, processes, and programs to ensure that they have only enough permissions to do the job.
- Remove open access and start all accounts with low access. Only add specific higher-level access as needed.
- Create separate admin accounts that limit access.
- Superuser accounts should be used for administration or specialized IT employees who need unlimited system access.
- Standard user accounts, sometimes called least privilege user accounts (LUA) or non-privileged accounts, should have a limited set of privileges and should be assigned to everyone else.
- Implement expiring privileges and one-time-use credentials.
- Create a guest network leveraging a VPN for employees and guests.
- Develop and enforce access policies for BYOD or provide your own network-protected devices whenever possible.
- Regularly review updated employee access controls, permissions, and privileges.
- Upgrade your firewalls and ensure they are configured correctly.
- Add other forms of network monitoring, like automated detection and response.
The post Shoring Up Your Network and Security Policies: Least Privilege Models appeared first on Webroot Blog.
Symantec fixed a local privilege escalation security flaw affecting all Symantec Endpoint Protection software versions prior to 14.2 RU2, and allowing attackers to escalate privileges on compromised devices and execute malicious code using SYSTEM privileges. […] BleepingComputer