Frank van Vliet Interview on Linux Security Challenges and Solutions

Frank van Vliet is the author of AuditFile, many security advisories, and recently pointed out configuration errors on apache.org. We thought our readers would be interested in an interview with This email address is being protected from spambots. You need JavaScript enabled to view it. because of the recent paper he and This email address is being protected from spambots. You need JavaScript enabled to view it. released outlining the steps they took to compromise apache.org. Their paper does not point out any new vulnerabilities, it merely shows how simple configuration errors can leave a system susceptible to attack. In this interview Frank explains how he audits a systems security, major pitfalls administrators fall into, and how he attempts to uncover bugs. We believe that everyone can learn something from this interview. Note: Frank uses the alias {}


LinuxSecurity:When and how did you gain interest in security? How did you gain your security knowledge?

Frank: When I finally switched from Windows to Linux, I spent a lot of time studying the Linux kernel source. When I finished that one I knew C enough to start coding on my own. I started working on my first security project called Auditfile. A kernel patch making it possible to restrict file access per process or per binary. This enabled me to run my apache webserver only allowing it to read default libraries (/lib/*, /usr/lib/*), read its configuration files, htdocs (wwwroot) directory, and only allowing it to write to logfiles with no further access. At the same time I took over control of the security focused group RooT66 and I joined ShellOracle . I spent hours reading various texts and joined Buffer0verfl0w security I also got involved with projects like SecNet http://irc.secnet.org (not finished when writing this). I have done some freelance security jobs for small webhosters


LinuxSecurity: When attempting to audit a systems security, what procedure do you follow? Where do you begin? How do you normally gather information? What comes next?

Frank: My approach changes as I gain more knowledge. Currently when checking the security of a system, I start checking the file system (what files are sundown or suidgroup, what files are accessible for what groups, what files are world writable, are their any files with nonpublic information world readable). Next, I try to find out what processes are running as root. Of course the suid root processes are but there are also crontabs or administrators around running binaries so I wrote some tools live monitoring the processes running as root. When having a list of binaries ran as root, I start checking every binary. Are there any known security flaws in it? Are its configuration files and data files accessible by nonroot? If nothing and I am really in the mood and the binary isn't too big I would download the source of it (I really love open-source) and read it to see if I can find any bugs in it.


LinuxSecurity: What are some of the major pitfalls Linux Administrators fall into?

Frank: It is never enough to download all patches and updates and run latest versions of your software. The group Buffer0verfl0w Security I am in is constantly searching for new bugs in software.

Most admins play with things themselves and forget permissions on files or other configuration faults. These things can be like the following backup script:

#!/bin/bash
for file in /home/*
do
tar -czf `echo $file | sed -e 's/\/home\///'`.tar.gz $file
mv $file.tar.gz /verysecuredirectory/backups
done

Which means every home directory will be compressed into targz files in the local directory then they got moved to the /verysecuredirectory/backups. But because most umasks aren't set to make new files 600 and most of the times it makes new files world readable, an attack can gain all directories in /home if it just scans most common directories the root is in for .tar.gz files and very fast copies most of it to his own directories before the scripts move it (most of the time this is while it is still compressing into that tar.gz file and it is already readable.

Besides those race condition bugs like the previous ones, there are also administrators that store backups in world readable.

And there are always the 'can I trust my network' things. Man in the middle attacks are not very common but are very easy to perform, especially when at the same network segment as the box you attack (could be some other way more insecure box previously hacked). In worst case an attacker on the same segment could broadcast arp who-has packets with the ip of the nameserver the attacked box is using has the MAC address of my NIC. That would mean when the attacked box would try to access the nameserver, it will instead contact the box of the attacker and send its name resolving questions. Then the attack can just reply normally except for the kernel.org domain and have those names resolve to the ip of the box of the attacker. Then have it set up just the same ftpserver as on any other ftp kernel.org box and have it search trojaned Linux kernels and then just wait for a new Linux kernel to be published.


LinuxSecurity: Have you exposed any other vulnerabilities, or written any programs related to security?

Frank: Well, I wrote auditfile (still working on a newer version, as always) I mentioned in the beginning of this interview that is at . I found a bug and wrote an exploit for bugzilla https://bugzilla.mozilla.org:443/ and working on some other exploits and tools at the moment.


LinuxSecurity: How do you normally approach finding security vulnerabilities and writing code to exploit them?

Frank: Every language has it's own sets of common bugs the programs can have.

For C/C++ are mostly buffer overflows. The only way to find them is to check every buffer in the program and search for any functions done on that buffer and check everything if there is a possibility to exploit it. I wrote some perl scripts to automate a part of this task which I normally use to find the buffers, sizes of those buffers and possible insecure functions (like strcpy and sprintf) done on those buffers, saving me a lot of time finding normal overflows. The tricky ones require reading from line 1 to like $ (last line).

For perl it are most of the time system or open functions that can be used to execute commands (like system(finger $user) or open($user) where the attacker can set the $user variable). So I normally search for all open, system (system, exec, `, and so on) functions and check arguments to them. Also database functions can be insecure.

I know people sending random feeds to their sendmail deamon and catch crashes then backtrace to see what feed caused it and then work there way back from there to the bug. Perhaps someday when I am that desperate to find a bug in some high profile software I would do a thing like that, until then I just read and most of the time you also learn by reading.


LinuxSecurity: What do you feel is the most important step in keeping a network secure?

Frank: The integrity of the network can be spoiled if only one of the boxes on the network got compromised by a nontrusted person. Most networks get compromised because only one insecure box was on the network.

Administrators may want to consider an Intrusion Detection System to monitor all machines on a network.

The most important step to keep a network secure is to keep all host secure, this can be done by restricting as much as possible from outside to the network (like only http connections to the httpserver and only ftp connections to the ftpserver and so on) and having and IDS monitoring network traffic.


LinuxSecurity: What do you think the most common Linux security vulnerability is? How would you recommend an administrator fix this?

Frank: The possibility of easy exploiting of buffer overflows. Most buffer overflows can be stopped by patches like the nonexecutable stack Linux kernel security hardening patch from the Openwall Project and packetstorm to see my 2.3.99-pre5 version of it) patch for the Linux kernel and compiler addons like stackguard.


LinuxSecurity: Do you think open-source software has the potential for being more or less secure than closed-source software?

Frank: There are two sides to this story, if the same program was available in both open and close sourced version. They are insecure at the same rate. But because you get the source code of the open-source program it is very easy to search for bugs. Then two things happen. The bugs get reported and exploits are made for those bugs. This makes the open source program having less bugs then the same closed source program but also there are more exploits around and there will be more bugs to be found in the future. This doesn't say it is impossible to disassemble the closed source program and find the bugs in that one too. Then the same happens for the close source version but at a slower rate because the source is harder to get and to read (would be ASM instead of easy C or some other fancy language).

Open source software is more secure than closed source because good coders can use disassembling techniques on closed source programs to find vulnerabilities. I would rather have the open source version so it can compiled with stackguard.


LinuxSecurity: What do you think motivates "black hats" to damage/destruct systems?

Frank: It is the kick of gaining access and power motivating the "black hats" to hack systems. The damage and destruct is most of the times done in 2 parts. One part is to make sure they keep their full access and so most binaries are Trojan and so on. This can be because they are mad at the company they just hacked(they wouldn?t pay them for revealing the security bugs they exploited or some other in my opinion lame reason) or just because they really don't care and just want to show off (like the recent DDS attacks).


LinuxSecurity: How do you feel about the mass-media's portrayal of 'hacking'?

Frank: Most media focuses on the things done by stupid kids mass attacking big servers with DDS networks or doing other stupid things. This does take the heat off the real hackers. The real hackers that don't hack and don't want to be disturbed at their work of endless coding and tracing through programs. It was because Hardball and I wanted to make a statement about consideration of configuration. The media got us a little attention, we would still be unknown doing endless coding.


LinuxSecurity: What do you see is in the future for information security?

Frank: I would love to see administrators think twice before installing things on their boxes. Also, having kids on your company network is the last thing you want, especially when they try to trojan your sshdeamon and mess up making some boxes even unusable and forcing to full reinstall of everything because you don't know what was trojanned and what was not.

LinuxSecurity: We would like to take a moment to thank Frank for taking time out of his busy schedule to share some of his experiences with us. If you have any questions reguarding this interview, please feel free to drop us an This email address is being protected from spambots. You need JavaScript enabled to view it.. As always, if you have any ideas for other interviews, or any suggestions, please let us know. We want to serve you!