During a pentest I found a way to add arbitrary iptables firewall rules to a server. These rules get applied by way of the iptables-restore command, and I've been wondering whether there is any way to execute commands by manipulating the input.

My starting point is the following, which will output the help for iptables-restore:

printf '*filter\n--help\n' | iptables-restore --test

So I know that options are executed as expected. Now, the man page mentions a --modprobe=command option, which is described as:


When adding or inserting rules into a chain, use command to load any necessary modules (targets, match extensions, etc).

Great, I thought, I can execute a command by providing a non-existent target and coaxing iptables into probing for it. I've tried the following (and variants thereof):

printf '*filter\n--modprobe=/some/command -A INPUT -j sometarget\n' | iptables-restore --test

But this just gives an error without attempting to execute /some/command:

iptables-restore v1.4.12: Couldn't load target `sometarget':No such file or directory

I've also tried using a module which exists but isn't currently loaded, but the module gets loaded successfully without calling the custom modprobe command.

Any hints or suggestions on where to go next (or any other routes I could investigate) would be greatly appreciated!

Edit: --modprobe seems to be out of the question, so the question becomes: are there any other potential exploits possible by passing malicious rules to iptables?

2 Answers 2


The --modprobe option is part of the command line syntax of the iptables-restore command. It isn't something that iptables-restore parses as input.

So if there's a sudo rule that allows you to run iptables-restore with arbitrary arguments, you can pass --modprobe=/bin/sh or variants thereof. But if all you can do is pass input to iptables-restore, then this particular method doesn't allow arbitrary code execution.

Note that I do not assert that iptables-restore doesn't allow arbitrary code execution in some other way. In particular, if you can control the environment but not the command line options, export MODPROBE_OPTIONS='-d ~/malicious_modules' (in combination with a rule that triggers the loading of a module) looks promising, but I haven't tried it. And of course modifying firewall rules can cause all kinds of havoc (starting from trivial DoSes and building on from there — often services restricted to localhost would be dangerous if exposed to the whole Internet).

  • Thanks for the response! Interestingly, iptables-restore definitely parses the --modprobe option to some extent, because it gives the error no command specified if the command argument is left out. Regarding your last point, unfortunately I can only modify the firewall rules through a web interface, so tampering with the environment isn't possible.
    – morphics
    Commented May 17, 2013 at 13:05
  • I stand corrected, the no command specified error is coming from iptables itself, but iptables-restore is reporting it as though it were its own error. So I suppose the question becomes whether iptables --modprobe=command can be used to our advantage.
    – morphics
    Commented May 17, 2013 at 13:35
  • modprobe is only invoked directly to load the ip_tables or ip6_tables modules. Those modules load the others as required. As noted by Gilles, --modprobe isn't part of the configuration input, see the "COMMAND" section of the iptables man page for the list, which confusingly does include -h and -V. Read the command4() function in iptables.c for more details. Commented May 17, 2013 at 13:48

Depending on what modules are available, you might be able to use xt_sysrq for some fun.

  • Thanks, that's actually quite interesting. I wasn't aware of that particular module, it's definitely worth a look; powering down the server would make a beautiful PoC!
    – morphics
    Commented May 18, 2013 at 21:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .