Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Embedded browser fails to start from docker container

Claudio | Last updated: Nov 25, 2020 11:54PM UTC

Hello, I am trying to run the embedded browser from a fedora docker container as a non-root user, however I am failing to do so. I understand clearly that the sandbox feature is not possible on a container due to technical limitations so I proceeded to disable the functionality via "Project Options > Misc > Allow the embedded browser to run without sandbox". I then proceed to launch the embedded browser, but I am receiving the following error: "Failed to move to new namespace: PID namespace supported, Network namespace supported, but failed: errno = Operation not permitted [262:262:0100/000000.762223:ERROR:zygote_linux.cc{654}] write: Broken pipe (32)" This error would be expected if I were trying to run the browser within the sandbox, but it shouldn't be the case if I choose to disable it. Confirming this is the fact that if I run burp as root user it will behave exactly as one would think: it will fail with the above error with sandbox on and run correctly with sandbox off. The embedded browser check will return successes, except for the first "Checking headless browser", which gives a warning. If I try running the embedded browser manually by launching the executable inside Burp's folder with the --no-sandbox flag, it will also start correctly. It almost seems as if Burp is ignoring the flag disabling the sandbox. I did some test with performance feedback enabled, the id is 3m9xcemupt6qql96rzop:kzuf Let me know if I can provide more information. Thank you, Claudio.

Michelle, PortSwigger Agent | Last updated: Nov 26, 2020 04:40PM UTC

Thanks for your message. We're currently investigating but it would be good to find a bit more about what you are seeing. Does the Render tab display responses properly (e.g. if you have proxied another browser via Burp and are then reviewing the requests and responses)? In Embedded Browser Health Checks, did the warning message give any further detail? Are you able to open the help files? Have you noticed this behavior in earlier versions of Burp?

Claudio | Last updated: Nov 26, 2020 10:07PM UTC

Hello, Does the Render tab display responses properly (e.g. if you have proxied another browser via Burp and are then reviewing the requests and responses)? Yes it does, if I configure another browser to go through Burp it will correctly show requests and responses in the intercept tab, http history etc... In Embedded Browser Health Checks, did the warning message give any further detail? It will say "Unable to created headless browser with sandbox". However, while redoing the health checks I did notice that a browser window pointing to about:blank suddenly popped up for a fraction of a second, to then disappear. The other two following tests are another "Checking headless browser" and "Creating embedded browser documentation window", both of which successful. Are you able to open the help files? In fact, if I go "Help > Burp Suite documentation" the browser window is opening correctly. Have you noticed this behavior in earlier versions of Burp? I have tried a couple of older versions to troubleshoot and they both don't work: 2020_11 has the same behavior 2020_9_2 also fails and has the health check has the same result (popping window included), but the error when launching the embedded browser also adds this: ERROR:nacl_helper_linux.cc NaCl helper process running without a sandbox! Most likely you need to configure your SUID sandbox correctly I have checked and the SUID is configured correctly. I also tried to launch the browser manually and it will start fine. When closed it will print the error above in the shell. Thank you, Claudio.

Michelle, PortSwigger Agent | Last updated: Nov 27, 2020 04:23PM UTC

Thanks for the update. We are still investigating this issue and will speak with our developers.

Claudio | Last updated: Nov 27, 2020 05:12PM UTC

Hi, I tested the new update, 2020.11.2. Behaviour is the same as 2020.11.1. Thank you, Claudio.

Michelle, PortSwigger Agent | Last updated: Dec 01, 2020 08:44AM UTC

Thanks for the update Claudio, I'll speak with the developers.

Michelle, PortSwigger Agent | Last updated: Dec 01, 2020 01:54PM UTC

We've been having a chat about this issue, do you see the same behavior if you run the docker container with the following capabilities? https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities --cap-add=SYS_ADMIN

Claudio | Last updated: Dec 04, 2020 03:47PM UTC

Hello, We have tested with SYS_ADMIN and the browser does open this way. However using this capability is not safe and we would like to have more granular permissions. Thank you, Claudio.

Francesco | Last updated: Dec 04, 2020 11:08PM UTC

Hi, I have the same issue but reading this post I don't think is an issue relative to the docker permission. If so, the embedded browser shouldn't run as root but without SYS_ADMIN capability. I also noticed that the browser in the "Help" page runs perfectly so I would ask to look if the browser call is the same both foor the embedded browser button and the Help Button.

Francesco | Last updated: Dec 05, 2020 02:13AM UTC

Hi, we did a deeper analysis and just wrote some line of code, we then replaced our program with the chrome binary and found the issue: Even if "Allow the embedded browser to run without sandbox" chrome is run without sandbox here is the output: /usr/local/BurpSuiteCommunity/burpbrowser/87.0.4280.66/chrome --user-agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36 --proxy-server=localhost:8080 --proxy-bypass-list=<-loopback> --remote-debugging-port=0 --disable-ipc-flooding-protection --disable-xss-auditor --disable-bundled-ppapi-flash --disable-plugins-discovery --disable-default-apps --disable-prerender-local-predictor --disable-save-password-bubble --disable-sync --disable-audio-output --disable-breakpad --disable-crash-reporter --disable-prerender-local-predictor --disk-cache-size=0 --disable-settings-window --disable-notifications --disable-speech-api --disable-file-system --disable-presentation-api --disable-permissions-api --disable-new-zip-unpacker --disable-media-session-api --disable-popup-blocking --noerrdialogs --no-experiments --no-events --no-first-run --no-default-browser-check --no-pings --no-service-autorun --media-cache-size=0 --autoplay-policy=document-user-activation-required --overscroll-history-navigation=0 --use-fake-device-for-media-stream --dbus-stub --use-mock-keychain --disable-background-networking --disable-sync --ignore-certificate-errors chrome-search://local-ntp/local-ntp.html --user-data-dir=/tmp/burp-browser3777845008902854068 --disable-background-networking --load-extension=/tmp/burp-blank-page-extension1773261616177612367,/tmp/burp-webapp-recorder-extension14366375264561915468 Our tool just read the arguments received by chrome and print it in a file

Francesco | Last updated: Dec 06, 2020 01:47PM UTC

Hi, Here is a workaround that demontrate that both the option "Allow the embedded browser to run without a sandbox" doesen't work or the tick is doing nothing. Just move /usr/local/BurpSuiteCommunity/burpbrowser/87.0.4280.66/chrome to /usr/local/BurpSuiteCommunity/burpbrowser/87.0.4280.66/chrome_old and create /usr/local/BurpSuiteCommunity/burpbrowser/87.0.4280.66/chrome containing: #!/usr/bin/python3 import subprocess import sys subprocess.call(["/usr/local/BurpSuiteCommunity/burpbrowser/87.0.4280.66/chrome_old", "--no-sandbox"]+ sys.argv[1:]) Then: chmod +x chrome and then you can run the embedded browser from the GUI without any problem. This ofcourse forces the chrome binary to be run with --no-sandbox. If you could fix it in the burp source should be amazing.

Michelle, PortSwigger Agent | Last updated: Dec 07, 2020 04:54PM UTC

Hi both Thanks for the updates, we'll take a look through and have a chat with the developers

Michelle, PortSwigger Agent | Last updated: Dec 10, 2020 02:28PM UTC

The developers have taken look into this and it seems SYS_ADMIN is required to allow the namespace change required by the sandbox. Overall security can be tightened a little with --cap-drop=ALL --cap-add=SYS_ADMIN --cap-add=SYS_CHROOT --security-opt=no-new-privileges:true but both SYS_ADMIN and SYS_CHROOT (enabled by default) are required to start the sandbox. However, if we run Chromium without a sandbox, we can tighten up considerably with: --cap-drop=ALL --security-opt=no-new-privileges:true. The two options then have to be weighed up against one another and the risks you are happy with, is --no-sandbox in a constrained container better or worse than using Chromium's sandbox inside a less secure container.

Michelle, PortSwigger Agent | Last updated: Dec 11, 2020 11:28AM UTC

Our developers have also explained that we will only disable the sandbox if the option is set and we don't think the sandbox can be used based on some exploratory checks, which could explain why it appears that the flag is not respected. They do have a ticket to look at changing that behavior so we have linked this thread so we can let you know when there is an update.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.