Insecurity News
Insecurity News
copy_from_user_mmap_sem()
We've all been there; in fact, many of us have been there recently. You wake up to find email from Bugtraq or Full-Disclosure, or perhaps a notification from your vendor about a security update – a security update that affects almost all your systems, and for which exploit code has been publicly available for several days [1]. Of course, I easily could launch into the power of open source and talk about how quickly the Linux kernel team fixed the vulnerability, allowing vendors to push out updates in a timely manner. Or I could talk about the importance of inventorying your systems and having a patch-management system in place so that they can be patched promptly. But the point is this: All systems are vulnerable, all the time. Let me repeat that just to make sure you don't think I made a mistake: All systems are vulnerable, all the time.
Security flaws are a lot like Schrödinger's cat: neither dead nor alive until you look [2] (Figure 1). Do security vulnerabilities appear out of the ether as if by magic when someone observes them, in effect collapsing the quantum probability state of the vulnerability in question to a known state? That is to say, as long as no entity recognizes the security vulnerability (and more importantly, as long as no one has exploit code for it), the vulnerability doesn't really exist. This also is known as the "tree falling in a forest" theory of information security.
Alternatively, one could argue that even though you don't know for sure when the isotope will decay, triggering the poison gas vial to release it, it will decay eventually, and probably sooner than you'd like! The reality is that a modern system has so much code installed and running that it is likely that some exploitable vulnerability will be found and used to compromise the system. So, what can you do?
Plan for Failure
Much like the old saying "plan for the worst but hope for the best," you should plan for failures in your security systems. All the standard advice about hardening systems, layering security, and limiting access and privileges where possible is still good advice, but it largely fails to answer the question: What do you do when your security fails?
Better System Design and Configuration
Because it is almost inevitable that your systems will be vulnerable at some point – most likely for a period of time during which there is public access to exploit code – your system probably will be compromised. A perfect example of this is seifried.org. I had SELinux enabled, which prevents all manner of security vulnerabilities from being exploited but also prevents a lot of third-party, web-based software from working properly. After fighting SELinux for some time, I gave up and disabled it.
This was my first mistake for two reasons. First, by disabling SELinux, I made my system much easier to break into and also reduced the amount of logging that would occur if someone did break in. If you must turn SELinux off, at least use permissive mode, which logs violations.
My second mistake was classic administrative laziness. To ease system administration, I had established SSH trust relationships between my hosts and also enabled sudo access without having it prompt for a password on my machines.
In effect, once an attacker broke into a system and gained access to the administrative account, they would have access to all of my systems. Thus, when one of my systems was compromised, I ended up having to rebuild all of them because I was pretty sure they all had been modified. Often, this design flaw also occurs with firewalls and other security mechanisms: Organizations implement a hard shell of exterior security but fail to implement any internal security, leaving a soft chewy center for attackers to feast upon.
Break-in Tip: MySQL
One commonly used method to reset a lost MySQL root password is to use the --skip-grant-tables option, which loads the database with no protection at all. If you must use this method, use --skip_networking as well, to allow only local connections. Local users would still be able to connect, so make sure you boot all of them off, too.
Perhaps a better method is to use the --init-file: "Read SQL statements from this file at startup. Each statement must be on a single line and should not include comments."
So all you need to do is create a text (reset-password.txt) file with an SQL statement that will change root's password,
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('MyNewPassword');
and then start mysqld with the --init-file [filename] option and, once loaded, simply restart MySQL normally and log in with your new password.
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs