I don't recommend running untrusted Python scripts (or any untrusted code) as root.

If you're looking for an "exploit," why not just use the shell escape?

mininet> sh rm /etc/passwd

By design, Mininet runs as root and permits shell escapes, but it can be run in a container or VM if you wish greater isolation. Usually people run it in a VM.

However, I would consider a patch to make it possible to run Mininet as a non-root user, if you are interested in putting one together.

Yes, i totally agree that a user shouldn't run untrusted scripts, and some mininet REPL function is designed for command execution(such as the sh).
However, i focus about the __init__ in Controller.
what i want so say is that in __init__ of controller, that suggested to be some kind of IP check and PORT check. because that developer don't know what happened is the mininet library, he my use an user input as the IP and PORT in __init__ with out any kind of defence. that could cause command execution. and those developer's machine may get compromised.
To make the mininet library safer and more people could use it without worrying about security problems , i just suggest to add some kind of check in __init__ function.
The easiest regex could solve the possible risk of command execution :）

examples of checking IP
checking if IP is a domain name:
^(?=^.{3,255}$)[a-zA-Z0-9][-a-zA-Z0-9]{0,62}(\.[a-zA-Z0-9][-a-zA-Z0-9]{0,62})+$
checking if IP is an IP:
((2[0-4]\d|25[0-5]|[01]?\d\d?)\.){3}(2[0-4]\d|25[0-5]|[01]?\d\d?)
a simple check by regex for IP and PORT param could make the mininet library safer :)

thanks for your hard working for mininet, and hope the mininet could be better and better :)

If a developer what to write his UI website for creating SDN network, I think depending the developer to check the user-input of IP and PORT is not so practical...... cause many developers will simplely pass the user input to the __init__ of Controller......And that may cause problems.

To avoid these kind of problem from the root...... it's better perform a check in __init__ ......
thanks : )

I'm not convinced that input vetting makes it any more secure, and it makes the code more complicated, which can make it harder to understand and less reliable.

However, feel free to submit a pull request if you think it's actually useful.

As I noted, since Mininet currently runs as root the best idea is to run it in its own VM (or on a dedicated bare metal server) and that's what we recommend.

It's also possible to run Mininet in a container with virtual root rather than real root. However, since it shares the same kernel it's not particularly secure (though it may help prevent some accidental errors - see below.)

It may also be possible to make Mininet run with more granular capabilities; at the minimum, it would need to be able to create network namespaces and to add interfaces in both the root and host namespaces.

At the end of the day, you're running a Python script with root access, so you shouldn't accept untrusted input. Or code for that matter:

# XXX Don't try this "typo" at home
s1.cmd('rm -rf /tmp/foo /*')

yep, i see that people should run mininet in virtual machine. However, one may run it on his server to create a SDN environment, that may cause proplem .
maybe because i majored in cyber security, so i am more sensitive to some kind of problems. : )
All right, I will submit a pull request these days to make it safer : )

I don't understand how the changes you suggest would somehow "make it safer?"

I'm also a bit unclear on how would you "exploit" this without either 1) running malicious/untrusted code as root (as in your example) or 2) accepting malicious/untrusted user input (including command line arguments or environment variables) into a script running as root?

Are you expecting that a rogue DNS server could be used to exploit this somehow, or ??? Perhaps you can provide an example which doesn't require untrusted user input (including environment variables, command line options, configuration files, etc.) and/or untrusted code?

That being said, I think the right approach for IP addresses in the long run (e.g. Mininet 3.x) might be to make them first class objects which are also interoperable with strings (perhaps a subclass of string or something.) The "simple" fix would be to vet input, but that isn't scalable and makes the code harder to read and understand. We could also add type annotations to Mininet (which is also now compatible with Python 3) and possibly use a type checker to the code check.

As I noted before, making Mininet's permissions requirements more granular might be useful. I also think that we should have systematic error checking and recovery, which we don't currently have.

Probably the most important thing to realize is that this isn't really a bug - it is an intentional implementation choice to make the code simpler and easier to understand. Mininet is basically a root shell, so you shouldn't pass untrusted input to it, and you shouldn't run untrusted scripts. If you want better isolation, the best practice for now is probably to run it in a VM, dedicated server, or container.

wouldn't it be sufficient to simply apply this small change?

-listening = self.cmd( "echo A | telnet -e A %s %d" % ( self.ip, self.port ) )
+listening = self.cmd( "echo A | telnet -e A '%s' '%d'" % ( self.ip, self.port ) )

wouldn't it be sufficient to simply apply this small change?

-listening = self.cmd( "echo A | telnet -e A %s %d" % ( self.ip, self.port ) )
+listening = self.cmd( "echo A | telnet -e A '%s' '%d'" % ( self.ip, self.port ) )

when trying your exploit with this patch, i get

$ sudo python3 exploit.py
Adding controller
Unable to contact the remote controller at 127.0.0.1;id>/tmp/youarehacked;#:6653