Insecurity News

Insecurity News

Article from Issue 90/2008


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.

Figure 1: The cat is neither dead nor alive, until you look in the box.

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 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,

'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

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Securing Your Systems

    We'll show you how the lessons learned in the 1980s movie "The Karate Kid" can be applied to securing your systems.

  • Security Lessons

    Although you give up control of the underlying infrastructure when you use cloud computing, you can still maintain some control over security.

  • Qubes OS

    Most operating systems claim to be secure; however, most fail terribly. Newcomer Qubes OS tries a different approach, relying on a microkernel and pervasive virtualization.

  • Security Lessons

    Are your systems secure against DNS attacks? We'll show you why they matter and help you determine whether you are vulnerable.


    Klaus Knopper is the creator of Knoppix and co-founder of the LinuxTag expo. He currently works as a teacher, programmer, and consultant. If you have a configuration problem, or if you just want to learn more about how Linux works, send your questions to: klaus@linux-magazine. com

comments powered by Disqus
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.

Learn More