Ubuntu 20.04 - Quest Container not setting up correctly

[levi-blodgett]

Describe the bug Currently running on an Ubuntu 20.04 AWS instance, when you do a default EMBA installation with 1.3.0 tag the quest container does not work as intended.

To Reproduce Steps to reproduce the behavior:

1. Clone v1.3.0 of the EMBA repo
2. Default EMBA installation: sudo ./installer.sh -d
3. Use any firmware
4. Start EMBA with the following parameters: sudo ./emba -l /logs -f /absolute/path/to/emba/firmware -p ./scan-profiles/default-scan.emba (I don't think the params matter really, but these are the ones I used)
5. See error:

   
   [+] Dependency check
   =================================================================

[*] Network connection: Internet connection - not ok [-] ERROR: Quest container has no internet connection!

**Expected behavior**
EMBA run passes dependency check on a clean installation.

**Desktop (please complete the following information):**
- OS: Ubuntu 20.04.2 LTS
- EMBA version: v1.3.0 tag
- Installation method: default with up to date docker image, `sudo ./installer.sh -d`

**Priority issue**
Are you already a [Sponsor]? - N

**Additional context**
I really can't find any documentation on the quest container and what it is responsible for, if someone could point me in the right direction I could try to solve this.

[Sponsor]: https://github.com/sponsors/e-m-b-a

[levi-blodgett]

It is also possible this could be happening on other OSes, but I don't have the ability to test those right now so would need someone else to confirm if the installer sets up the quest container properly.

[m-1-k-3]

We improved the online check since the last release. Could you please test the latest master?

[BenediktMKuehne]

The Quest container is a separate container for the Q-modules, which require internet connection. Currently, @m-1-k-3 is working on a fix where the container doesn't work correctly behind a proxy. Might this also be the case here?

[levi-blodgett]

We improved the online check since the last release. Could you please test the latest master?

This was it, I figured that the tagged versions were what should be used like "stable" releases, but didn't realize that since there is just the one tag of the docker image that the master branch should probably always be used, and that the master branch is always supposed to be stable.

Would either of you be opposed if I opened up an MR for updating some of the documentation from what I have learned?

---

This is a separate question for clarification that I couldn't really understand from the docs, specifically about dangers of running full emulation:

If I am running EMBA with full emulation, which components of my setup have potential to be harmed?

Example setup:

• A server where sudo ./installer.sh -d has been ran inside an up to date EMBA repo on master branch.

User calls EMBA with:

• sudo ./emba -l ./logs -f ./firmware -p ./scan-profiles/default-scan-emulation.emba

Which would be in danger of being harmed, the server (host?), the network the server is hosted on, and/or the docker image that EMBA is running inside of?

From the docs it seems like the server (host?) is in danger of being harmed, but I am not sure why that is the case if the docker image is the one executing EMBA and doing the pentesting. If anyone is able to explain, I would like to add a version of that explanation into the docs.

[m-1-k-3]

This was it, I figured that the tagged versions were what should be used like "stable" releases, but didn't realize that since there is just the one tag of the docker image that the master branch should probably always be used, and that the master branch is always supposed to be stable.

Would either of you be opposed if I opened up an MR for updating some of the documentation from what I have learned?

Does it work to open a PR for the Wiki? If so, please do it.

This is a separate question for clarification that I couldn't really understand from the docs, specifically about dangers of running full emulation:

If I am running EMBA with full emulation, which components of my setup have potential to be harmed?

Which would be in danger of being harmed, the server (host?), the network the server is hosted on, and/or the docker image that EMBA is running inside of?

From the docs it seems like the server (host?) is in danger of being harmed, but I am not sure why that is the case if the docker image is the one executing EMBA and doing the pentesting. If anyone is able to explain, I would like to add a version of that explanation into the docs.

The EMBA docker container is mostly read-only, the network (which is currently used for CVE-search) is isolated and the container is destroyed after execution. Nevertheless, the container is running in privileged mode and ...

... we have two emulation environments available in EMBA:

• 1st: User-mode emulation is primarly used for improving the SBOM, vulnerability and exploit detection. In this mode you are directly running untrusted code from the firmware in the docker container (within a chroot user-mode qemu). This could result in a breakout of the chroot, compromise of the container, escape from the container or attack your report and finally as a worst case szenario your host.
• 2nd: System-mode emulation is used to boot the complete firmware in qemu. which is also untrusted and can be used to perform further attacks in the qemu environment. Again, as worst case szenario an attacker could use a manipulated firmware to perform further attacks.

[m-1-k-3]

Closing now - open it again if needed