netifera Blog

About the backdoor in netifera

Some of you might be wondering why the netifera distribution includes an executable called ‘backdoor’.

We deliberately chose that name to draw attention to the fact that if you install this feature correctly you will be creating a security vulnerability on your system: Anybody who can execute the backdoor binary will be able to capture and send raw network packets.  We think this risk is minor and acceptable considering that it makes netifera much simpler to launch and use, but it’s disabled by default and should not be enabled without understanding the implications.

We’ll explain all the details of why it exists and how it works, and how large of a security hole it creates so you can decide for yourself if you want to use it or not.

Why do we need it?

Netifera includes functionality which captures network traffic and parses it for interesting information.  On the platforms we currently support (Linux and Mac OS X), special privileges are required to open a network interface and capture packets.

On Linux to capture packets you need to open a special type of socket with the socket system call.  A regular user process cannot access these sockets without elevated privileges:

‘Only processes with effective UID 0 or the CAP_NET_RAW capability may open packet sockets.’

Mac OS X provides the standard BSD interface for capturing packets through a set of devices in the /dev directory:

$ ls -l /dev/bpf*
crw-------  1 root  wheel   23,   0 Nov 23 10:45 /dev/bpf0
crw-------  1 root  wheel   23,   1 Nov 23 11:14 /dev/bpf1
crw-------  1 root  wheel   23,   2 Nov 21 16:52 /dev/bpf2
crw-------  1 root  wheel   23,   3 Nov 21 16:52 /dev/bpf3

Access to these devices is controlled with filesystem permissions and in a typical configuration only the superuser will have permission to open BPF devices.

On both Linux and OS X the problem is the same: We need to access a privileged operating system resource from a regular user process.

How does it work?

Our pcap implementation

When we started implementing sniffing in netifera we didn’t find a useful java library for capturing packets.  We decided to write our own by implementing libpcap in java.  Our version is somewhere between a port of libpcap into java, and a new implementation.  We copied the exact logic for opening capture devices because libpcap covers a lot of special cases and subtleties.  Since java does not directly provide access to the necessary system calls, we use a small (about 300 lines of C code) Java Native Interface library to invoke the raw system calls needed to implement the pcap library.


When netifera attempts to open a network interface for capture, it will fail unless netifera is running as root.  If the attempt fails because of a permission error, netifera will attempt to us the backdoor executable if it is available and installed as setuid root.

The native library executes and communicates with the backdoor binary.

  1. The JNI library ( creates a pair of Unix domain sockets with socketpair() and executes the backdoor binary with one side of the socket pair bound to file descriptor 0.
  2. The backdoor binary opens an instance of the privileged resource and obtains a file descriptor.
  3. The backdoor passes the file descriptor to netifera using a Unix feature for passing file descriptors between processes over a local socket, and then exits.

What are the alternatives?

Always run netifera as root

If netifera is executed as root, then there is no problem to solve since the root user can always open the sockets or devices needed for capturing packets.  We don’t think it’s reasonable to require our users to always run netifera as root, especially considering that we are expecting our users to be very security conscious.

If you prefer to not install the backdoor binary, this is an option that can be used to access sniffing functionality in netifera.

Doesn’t the desktop environment already provide a solution to this problem?

Linux has various graphical wrappers for the sudo and su utilities and Mac OS X has something called Authorization Services.  On both operating systems this can be used to launch an application with root privileges after prompting the user for a password.  So, this would be an easy way to have netifera always launched as the root user.  We are not going to install netifera this way and we don’t recommend that you do it either.  Typing your root password into an arbitrary UI dialog just because it popped up and asked for it makes us a little bit uncomfortable.

An idea for the future

Recently we’ve been discussing a new possible solution to authenticate requests to the backdoor binary.  The way it would work is that the user would choose a password when upon installation which would be hashed and stored in a file owned and readable only by root.  The netifera user interface would prompt the user for this password and send it in requests over the socket it shares with the backdoor utility.  The backdoor executable would use the setuid root privileges to read the password from the file and authenticate the request.


If you install the backdoor binary with setuid privileges you will be able to sniff packets in netifera without needing to run the entire application as root.  The downside is that anybody else who can execute the backdoor binary can also use it to open network devices for sniffing.

Please let us know if you have some idea for solving this problem that we have not thought of, and if it makes sense we’ll implement it.

Bookmark and Share

Tags: , ,

This entry was posted on Tuesday, November 25th, 2008 at 15:07 and is filed under Netifera Architecture. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply