Users of GNS3 need to keep in mind that it is a tool designed to be used for experimentation/learning not for managing Virtual Machines or appliances in a production environment.
The demographic of GNS3 users is very broad, ranging from the networking student, through to the systems administrators in large corporations.
GNS3 is designed for allowing full control via the GUI. We have prioritised making GNS3 as user friendly as possible, as opposed to hardening the application against every possible security threat. Although our focus is not currently on application security, we do encourage contributions of this nature to the project and understand this is an extremely important part of our the application’s development.
This document aims to cover the possible attack vectors and security considerations every good administrator should consider, before installing/using GNS3.
The choice of making GNS3 useable without the need of a VM and multi platform offers a powerful solution to users even with low resources computers but increases the attack surface.
The best is to consider that if someone has access to a running GNS3 server, he has access to the account where the server is running. We try to limit that, but due to the nature of the experimentation running in GNS3 the gns3 server has powerful control on the account.
If you found a security issue please report it to [email protected]
If you want to use PGP you can also mail:
Please give us some times to solve the issue before public publications. The project is partially run by volunteers on their free time especially the publication of the package on various distribution.
We also provide nightly build: https://sourceforge.net/projects/gns-3/files/Nightly%20Builds/ but we recommend using stable releases.
For linux see: Installation on Linux
Please do not use any third party download sites as they might inject malicious code into the installer.
Windows versions are signed with a GNS3 certificate.
GNS3 is open source and you can access the source code and audit it. The whole development process is transparent and you can follow it live on our repositories.
GNS3 is splitted in two parts: The GUI and a server. The server is controlled via HTTP by the GUI. The server is responsible for starting the emulators. The server by default when started by the GUI is protected by an HTTP basic auth using a random password.
When the GNS3 server is run on a local computer, it has access to the entire filesystem. This allow users to use images located in different locations of the file system.
To summarize; if the GNS3 server process is compromised, it will have access to the entire file system.
Depending on your computer configuration, or the topologies where you are running any appliances, it is possible to access to your physical network. It is not possible to prevent this, as GNS3 requires network access for certain use cases.
Also when an emulator starts, often the it will expose it's console to the network via the same IP as the GNS3 server. With physical equipment, this is the equivalent to having physical access to the serial port of a device.
Due to limitation of some emulators, the virtual network listen on all IPs. This means you can inject packet inside and exploit a security hole in a running image.
GNS3 is a wrapper on proprietary and open source technologies. This means the security level depends of the security of each technologies.
The main danger is a rogue image trying to take control of your computer by a process escalation.
WARNINGUse images only from trusted sources
Ubridge is the part of GNS3 running as root in order to allow injection of packet in the computer network interface. Because it’s running as root it’s the main risk of privilege escalation. On Linux and Windows we have limited permission to access to the network, but on OSX ubridge as full access. The code is short, open source and easy to audit. If you want to help on security it’s a good starting point.
We control VirtualBox with their official command line tool. The dangers are limited to securitys hole in VirtualBox itself. Due to the fact Oracle as full time developers on this product. We can consider this technology safe if you use the last release.
We control VMware with their official command line tool (VIX) and a program for us to create network bridges: ubridge. The dangers are limited to security holes in VMware itself or ubridge. Due to the fact VMware as full time developers on this product we can consider this technology safe if you use the last release.
IOU from CISCO is just a Linux binary. This mean any binary could be run as an IOU. Don't use IOU images from unknown sources.
We control Dynamips via the Dynamips hypervisor. Dynamips is a reverse of the hardware use in some CISCO gears. Due to the fact it's a complex process the probability of a way to make an fake IOS and taking control of the process is high. But it's complex because it means modifying a real IOS to add this.
It’s perhaps also possible to crash the generic switch/hub with special crafted packets.
We control Qemu with their official command line tool. The dangers are limited to security holes in Qemu itself. Due to the fact Qemu is a big and active community and companies using it for production stuff we can consider this technology safe as long as you use the last release and follow Qemu recommendation.
For x86 running Qemu without KVM could lead to security problem because this part is not audited.
KVM uses a kernel extension, make sure the kernel is up to date.
We control VPCS by the VPCS command line tool. We have discovered issue in some release with the inputs, the probability of a possible process escalation is considered high until someone conduct a full audit of the source code.
We control docker via the Docker API. Due to the fact Docker is a big and active community and companies using it for production stuff, we can consider this technology safe as long as you use the last release.
Docker using kernel extension, make sure the kernel is up to date.
For injecting packet into your physical network we use winpcap or npcap on Windows. Use the last version to avoid trouble.
To analyze captured packet we provide Wireshark. Use the last version to avoid trouble.
The GNS3 VM allow you to run emulator in an isolated and standard environment. You can improve the VM security by changing its password and adding authentication to the GNS3 server (but this require to not using the GNS3 VM control of the GUI and configure the VM as manual remote server).
With the GNS3 VM you have the same security level offered by Unetlab or Cisco VIRL.
It's common to see users running GNS3 as root or Windows Administrator. We recommend to avoid that unless you absolutely need it. Even if you want to ignore this security problem this could also lead to bugs (VirtualBox and VMware don't like that).
Starting from version 1.4 the ability to run VirtualBox has a different user has been removed because this option created too much corner case for security and was too hard to be correctly used by users.
We do our best to workaround OS limitation to avoid the usage of GNS3 as root.
GNS3 could be run on a remote computer. Don't do that on an untrusted network. In the current state of GNS3 the security level for this is low because you can brute force the server (see the improvement sections) or just get access to the emulator consoles.
When the server starts by default the user can only access the images and project directory. If you want a full access to the filesystem like what we do when use on your local computer, you need to start the server with the --local flag.
We recommend the use of a VPN tunnel to protect your communication. You can use SSL or SSH to protect GNS3 communication but the emulator console will be available to the world. A VPN will offer you security for GNS3 and the emulators.
At the beginning GNS3 was a tool for learning Cisco on your own computer. GNS3 evolved and the server can be shared between multiple users but with limitations:
You have the same security problems than when you share a physical lab between students. A bad user could cut a cable and connect it to someone else’s console...
Antivirus are designed with a standard user in mind. GNS3 build virtual network and capture stuff on this network. This behavior exists only in a small amount of software (GNS3, VirtualBox, VMware, Hyper-V) and the fact GNS3 make virtual network between different technologies is unique.
Also GNS3 is a kind of a hypervisor managing multiple processes. The communication with these process is made via TCP sockets. Sometimes “smart” firewalls see that as an attack.
GNS3 is open source; you can audit our code and even rebuild your own binaries.
If you want to improve the security here some issue where we need help.
In order to avoid an attack from a different user of the computer, we can protect the server with a rate limiter. It's usable for external connections and not required for a local server because by default we listen only on the loopback interface.
One improvement is to reduce the attack surface by turning off unused modules like IOU.
Though we haven’t tested it yet,running a GNS3 server in a dedicated container can protect the user.
To avoid a user consuming all the resources in a shared environment.
Create a notion of users in GNS3 and set users as owner of a project and prevent other users to access to it.
A way for admin to limit the list of qemu accessible binaries in order to prevent people to use unexpected programs.
By default most emulators support only telnet for remote access. An improvement could be to expose console via the API (like in the docker remote API). This allow to use the GNS3 authentication to protect the console access.
Restrict how emulator listen for packets.
Reported by Hacker House https://www.myhackerhouse.com/gns-3-ubridge-local-privilege-escalation-attack-0day/
Fixed in 1.5.4 and 2.0.0 releases
The first point to check is the images. When you download an image from an unknow website, you take additional risk, though it's the same risk when you download any program for your computer.
By running emulators in a VM, like the GNS3 VM on a single user computer, you can avoid most of the issues.