View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006666||Kali Linux||Kali Package Bug||public||2020-08-20 14:07||2021-03-08 16:49|
|Summary||0006666: chrome-sandbox in burpsuite 2020.8 fails when installed via APT in Kali|
Burpsuite 2020.8, when installed from the downloaded 64-bit installer from here [https://portswigger.net/burp/releases/professional-community-2020-8?requestededition=community] sets the SUID bit on <Burp_Install_Path>/burpbrowser/84.0.4147.105/chrome-sandbox but the Kali APT package does not.
Instead, the Kali apt package installs a large binary at /usr/bin/burpsuite and does not install the burpbrowser until first use for the kali user into ~/.BurpSuite/burpbrowser. When it does, it fails to set the SUID bit on ~/.BurpSuite/burpbrowser/84.0.4147.105/chrome-sandbox.
As a result, an error message appears when you try to launch the embedded browser: "net.portswigger.devtools.client.aj: Refusing to start browser as your current configuration does not support running without sandbox."
From PortSwigger support:
"Root permissions are required to properly configure the embedded browser sandbox:
sudo chown root:root /home/kali/<Burp_Installation_Folder>/burpbrowser/84.0.4147.105/chrome-sandbox && sudo chmod u+s /home/kali/<Burp_Installation_Folder>/burpbrowser/84.0.4147.105/chrome-sandbox
It sounds like when you've used apt install you would need to carry out the manual steps post-install but you may not have seen the dialog that informs you of this. I hope this helps."
|Steps To Reproduce|
Hello, would someone please take a look at this and respond? I opened this up 6 months ago today and there has been no action or response. Additionally, there is a new issue that is extremely closely related to this one that has emerged in the very latest update to burpsuite 2021.2.1.
I am willing to help with testing, or provide any additional data that may be needed.
Thank you so much!
There isn't a whole lot we can do here - we as a distro aren't supposed to touch files in the user's directory. Perhaps upstream could add a message about changing these permissions as a user?
The included browser is also x86_64 only, which means the package is now broken on arm64.
Yes, I see what you're saying. I did some testing and discovered that essentially the Kali apt package is just putting the jar file into /usr/bin. Because if I download the jar "installer" from Portswigger, I get the same behavior. On first run, it installs the burpbrowser folder to ~/.BurpSuite/burpbrowser. So in this sense it's an upstream issue with their jar installer.
However, there is also a platform installer for "Linux 64-bit". When the installer is run as root, it installs by default to /opt/BurpSuiteCommunity and the browser is installed (at installation time, not first-run) to /opt/BurpSuiteCommunity/burpbrowser, and the suid bit is properly set on chrome-sandbox. See attached screenshot.
You mentioned that arm64 is a concern, and I realize it's important for kali packages to be platform independent, but perhaps the .sh installer could be used instead of the jar installer? I don't know if Portswigger has any intentions of supporting other architectures or if they provide source code to distributions?
In any case, maybe they would agree to install the burpbrowser in a non-user location, such as /usr/share/burpsuite or /opt/burpsuite so distributions can follow best practices if they were asked. Then the permissions could be set correctly from the beginning.
So, I just tested this (mostly because I'm an arm person) and I was able to move their chrome install out of the way, and symlink /usr/lib/chromium to their versioned directory, and create a symlink from chromium to chrome, and everything works as expected. The chromium-sandbox package installs the sandbox binary with the suid bit already.
We've talked to them before about this, but there hasn't been much movement on the issue.
Thanks, @steev, that's good to know. Would it help if I asked them about this as a ticket so they know there is some more interest on it? Do you have a communication or ticket # I could reference? I'd really like to see this happen.
OS-74160 you have old burp and kali. is issue on newest versions too? why use old image of kali to test anyway?
HI there, @c0d2f3f5. I can see the how you might be confused. When I first opened this issue, back in August 2020, this was the newest version of Kali and Burp available. I have actually kept up to data on everything, but the issue still persists. Today, in March 21 I am currently using Kali 2021.1 with Burp 2021.2.1-0kali1 and nothing has changed. I don't believe there is a way for me to update the issue with new version information besides adding more notes like this.
|2020-08-20 14:07||OS-74160||New Issue|
|2020-08-27 07:26||sbrun||Assigned To||=> sbrun|
|2020-08-27 07:26||sbrun||Status||new => assigned|
|2020-12-01 10:48||g0tmi1k||Priority||high => normal|
|2020-12-01 10:50||g0tmi1k||Severity||major => minor|
|2021-02-28 18:18||OS-74160||Note Added: 0014255|
|2021-02-28 23:33||steev||Note Added: 0014256|
|2021-03-01 03:41||OS-74160||File Added: burpsuite_2021-02-28_19-40.png|
|2021-03-01 03:41||OS-74160||Note Added: 0014257|
|2021-03-03 16:39||steev||Note Added: 0014267|
|2021-03-03 18:09||OS-74160||Note Added: 0014268|
|2021-03-08 13:05||c0d2f3f5||Note Added: 0014288|
|2021-03-08 16:49||OS-74160||Note Added: 0014290|