Undoubtedly, software companies and developers could do much more to secure their code. For instance, bounds checking and better input validation on all code are a good start. Moreover, QA departments absolutely must design tests and dedicate resources to at least verify that proper input validation is in place and that buffers cannot be overflowed. More importantly, comprehensive planning and design to create a secure architecture and utilize secure coding practices are both prudent and seriously lacking.
Even after vulnerabilities are identified, many software vendors are quite slow to respond, and it often takes significant negative feedback and adamant requests from the user community before vendors will allocate resources to fix vulnerabilities and release patches. This is certainly the case with many Linux applications. Subsequently, when software vendors do respond by releasing security patches, they are usually quite important.
It is absolutely critical that all software be patched at the latest level—where security enhancements are included within the patches—and that any unneeded software be disabled or removed. This is particularly important for network listening applications, but can be true for any software installed on a machine. Just as with hardware and drivers, the more software installed on a machine, the more opportunities attackers have to find vulnerabilities and escalate their privilege.
Ideally, machines should have the lowest profile possible by having as few daemons as possible. Additionally, all daemons (especially network-listening daemons) should have as few permissions allotted to them as permissible while still allowing them to function. This recommendation is contrary to the current trend in Linux distributions as they try to compete with Windows-based servers and desktops by installing an ever-increasing number of applications by default. It is never a good idea to use a default Linux install (if given a choice). Instead, perform a custom installation providing only needed software applications.
Depending on how the software was installed, the ways to remove it will differ. For software that was automatically installed using the respective package manager that comes with the operating system (Yast for Suse, Yum for Red Hat, apt-get for Debian- based systems, and so on), using the same package manager to remove it is probably the best way to go. For RPM systems, you can use the rpm command with the -e flag. The -e stands for erase.
For other software that was compiled and installed manually, you will need to remove it manually, unless the installation tool includes a method for uninstalling it. Regardless, in Linux, removing software is as simple as deleting the binaries, their exclusive libraries, and any startup files that refer to them.
Published on Sat 22 February 2014 by Macy Leftwing in Security with tag(s): exploits