Analyzing security vulnerabilities in Debian.
This will be a slightly longish post about what security vulnerabilities and how to find about them in Debian and what possible steps you could take to minimize fallouts once you know the vulnerabilities.
First of all, repeat after me ‘no software is secure’, actually let’s amend that to ‘no software is secure on the Internet’ for sure and it’s also possible to be compromised even if no network is present.
Let’s go back one more step as to why is software not secure ?
All and any software is written by humans, and as humans even though we try to achieve perfection, there are always something that is over-looked or not tested enough, carelessness, not tested in enough combinations of other software and hardware or simply unknown factors. Apart from software, defective hardware too could lead to security issues as well (see Pentium FOOF bug , the Pentium FDIV bug or the Mars Orbiter mishap). The above three were unintentional and some of the famous hardware bugs which ended costing Intel and various other companies millions and thousands of dollars in recalls, lawsuits, loss of face and reputation. Apart from these you also have crackers and blackhats as Mr. Kevin Mitnick and many others were and are who continue to benefit from flaws in software and hardware.
One thing to note is this happens regularly and irrespective of whether it’s closed source software or FOSS. While closed-source software advocates use most of the time the combination of ‘security by obscurity’ methodology, meaning because the source-code of the software is not published it’s unlikely the bad guys would be able to crack in and around the software. While there are supporters to this, the opposite argument is because the source-code is not known, you can never know or guess how good or bad the code is written. It is very much possible that while the UI (user-interface) looks good, it might also be taken some shortcuts while manipulating, storing or outputting data as that is what most of us are doing with any software. So because it’s not known and vetted by many people it’s possible that unscrupulous individuals may make a lot of money with nobody being wiser.
As the information technology industry matured, cyber criminals started becoming more sophisticated with their attacks which affected companies and individuals and the affected companies and individuals started suing companies like Microsoft and others when the data was compromised or taken/sold without authority, it became imperative for all software vendors to fix the problems the software had.
Then companies started recording the issues into various databases to know as well as future reference, as well as bug trackers but this lead to chaos as there was no central hub for knowing if and when a security vulnerability was found, fixed and if it was fixed, whether it was fixed for all versions, some versions and to which degree it was fixed. There also came a need to categorize such security vulnerabilities into various threat parameters so action could be taken as resources are scarce and such resources always need to be justified between development, support, bugs of all nature + security bugs. The company management looks into various factors (financial and otherwise) and then takes a call of which bugs to fix now and which need to be fixed later. This is true whether the software is FOSS or closed-source software.
All of this confusion resulted in the creation of a centralized database called CVE or Common Vulnerabilities and Exposures. The idea of CVE is and was simple, have a centralized place where security researchers, penetration testers (all good guys) can figure out where software is exploitable. The industry is maturing with companies incentivizing exploits in their software. See Mozilla’s bug bounty program and various Google Security Incentives as examples of companies who are taking active part in minimizing the threat level over longer periods of time. The master list or database of such vulnerabilities can be seen at the CVE List.
Now while that is all nice and good, how does it help in figuring out which software/s have an issue, how to rate it and what to do about it. Enter debsecan. Let’s look at how debsecan describes itself and then we will see how it works :-
[$] aptitude show debsecan
Automatically installed: no
Maintainer: Florian Weimer
Uncompressed Size: 91.1 k
Depends: debconf (>= 0.5) | debconf-2.0, python (>= 2.3), python-apt
Recommends: cron, exim4 | mail-transport-agent
Description: Debian Security Analyzer
debsecan is a tool to generate a list of vulnerabilities which affect a particular Debian installation. debsecan runs on the host which is to
be checked, and downloads vulnerability information over the Internet. It can send mail to interested parties when new vulnerabilities are
discovered or when security updates become available.
So in essence what debsecan will do, it will see the number of packages your system has, the name of the package, the version of the package and then co-relate that with the CVE list, and then show you the list of packages which are known to have security issues. Installing it is pretty simple, just do :-
$ sudo apt-get/aptitude install debsecan
Note :- either use apt-get or aptitude. While I prefer aptitude there are many others who prefer apt-get. You can use either of them at any point of time but not both at the same time.
Once it’s installed simply run :-
$ sudo debsecan
This will generate a small, medium or large list of vulnerabilities depending on number of packages installed on the host machine. The output is something like below (just sharing two entries as this is just to understand)
CVE-2002-2439 cpp-4.7 (low urgency)
CVE-2014-3800 xbmc-bin (low urgency)
This tells me that at two packages have an issue but this is of low urgency. If you would look at the output, you will look the issues are graded from low urgency, remotely exploitable, medium urgency, high urgency. What you should be looking for remotely exploitable, medium to high urgency . Something like :-
$sudo debsecan | grep "remotely exploitable, high urgency"
Output will be similar to something like this (Just sharing couple of entries as well.)
CVE-2008-4392 djbdns (remotely exploitable, high urgency)
CVE-2014-9462 mercurial-common (remotely exploitable, high urgency)
CVE-2014-9462 mercurial (remotely exploitable, high urgency)
Now the real work starts, you have to go to the CVE list, read the offending bug, see if any workarounds have been given in the CVE bug till the time the proper solution to the bug is not found or look for an alternative software which does the same functionality but has less security bugs. Because this is a changing dynamic, you can never be certain if your choice is good because that again depends on if the alternative has been tested, does it have the same feature-set, would it be easily replaceable with minimal training etc. This is one of the reasons why Debian is loved by most System Administrators, for every software the developers and maintainers try to have at least one alternative so in the event a serious security bug is uncovered, you can still use the alternative and work is not stopped.
While I will not go into how security bugs are found simply because it’s a pretty tedious and boring job. You could use test the software using gdb or clang or both one after the other, you could use valgrind to find memory leaks, you could use fuzzy software like AFL to see if something happens and all sorts of testing. You could have a look at phoronix test suite as an example of how painful and stress-inducing these tests are, as you can’t or shouldn’t be using your system whenever one of the above operations are being involved.
While I have been brief about the tools which could be used to find security vulnerabilities, I do hope it generates a bit of awareness and understanding about software security.