github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #3968] chromium: save location bypass and code execution #2480

New issue

Closed

opened 2026-05-05 09:09:57 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 09:09:57 -06:00

Owner

Originally created by @ghost on GitHub (Feb 9, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3968

Bug and expected behavior

When using a Firejailed Chromium (default profile) it's possible to bypass the save location restriction and save files to desktop, or any other location, and to execute whatever file has been downloaded without any prompts.

What did you expect to happen?

For it not to be possible to execute the file.

Reproduce
Steps to reproduce the behavior:

Launch Chromium without Firejail enabled and select 'Desktop' as the default save location.
Close Chromium and re-launch Firejailed.
Right click and 'save as' any .torrent/.txt/.pdf/.png/.jpg or other file to 'Desktop'. On checking 'Desktop' The file will not be saved, but...
Click 'open' from Chromium downloads section and the 'non-existant' file will launch with the appropriate handler (Qbittorrent, Pinta, Imagemagick etc)

Environment

Linux distribution Xubuntu 20.04.2
Firejail version 0.9.62

Additional context
If the default system handler for the downloaded file is a snap package, then the file will be executed using the next available, 'non-snap' program instead.

eg: My default video player is VLC (installed from snap) but when I try this with a video file, the video opens with MediaInfo instead.

Also, even though the file isn't saved, if Chromiums save menu is opened again, Chromium file manager shows the file as being on the desktop.

The file can also being executed by entering the file path in the address bar. eg: filename is "pic1.jpg" and default save location is 'Desktop' so entering file:///home/user/Desktop/pic1.jpg in the address bar again executes the file.

I'm not sure if Firejail can prevent this, as the file isn't actually saved, but it doesn't seem right that the file is executed or that an alternate program is found when the default handler is an apparently un-usable snap.

Originally created by @ghost on GitHub (Feb 9, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/3968 **Bug and expected behavior** When using a Firejailed Chromium (default profile) it's possible to bypass the save location restriction and save files to desktop, or any other location, and to execute whatever file has been downloaded without any prompts. - What did you expect to happen? For it not to be possible to execute the file. **Reproduce** Steps to reproduce the behavior: 1. Launch Chromium without Firejail enabled and select 'Desktop' as the default save location. 2. Close Chromium and re-launch Firejailed. 3. Right click and 'save as' any .torrent/.txt/.pdf/.png/.jpg or other file to 'Desktop'. On checking 'Desktop' The file will not be saved, but... 4. Click 'open' from Chromium downloads section and the 'non-existant' file will launch with the appropriate handler (Qbittorrent, Pinta, Imagemagick etc) **Environment** - Linux distribution Xubuntu 20.04.2 - Firejail version 0.9.62 **Additional context** If the default system handler for the downloaded file is a snap package, then the file will be executed using the next available, 'non-snap' program instead. eg: My default video player is VLC (installed from snap) but when I try this with a video file, the video opens with MediaInfo instead. Also, even though the file isn't saved, if Chromiums save menu is opened again, Chromium file manager shows the file as being on the desktop. The file can also being executed by entering the file path in the address bar. eg: filename is "pic1.jpg" and default save location is 'Desktop' so entering file:///home/user/Desktop/pic1.jpg in the address bar again executes the file. I'm not sure if Firejail can prevent this, as the file isn't actually saved, but it doesn't seem right that the file is executed or that an alternate program is found when the default handler is an apparently un-usable snap.

gitea-mirror

2026-05-05 09:09:57 -06:00

closed this issue
added the
stale

needinfo

old-version
labels

gitea-mirror commented

2026-05-05 09:10:00 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Feb 11, 2021):

This is expected.
Default Chromium and Firefox profiles do not have private-bin set.

The file is indeed saved, it is however only in RAM and will be deleted on sandbox exit.

Not sure about the Snap part. Personally I'd remove that 😉 .

@SkewedZeppelin commented on GitHub (Feb 11, 2021): This is expected. Default Chromium and Firefox profiles do not have `private-bin` set. The file is indeed saved, it is however only in RAM and will be deleted on sandbox exit. Not sure about the Snap part. Personally I'd remove that :wink: .

gitea-mirror commented

2026-05-05 09:10:01 -06:00

Author

Owner

@ghost commented on GitHub (Feb 11, 2021):

Please update your firejail package, the 0.9.62 version is vulnerable to this. You can use the PPA maintained by one of our collaborators if the official repo's you use are not (yet) updated. The current chromium profiles block access to ${DESKTOP}, contrary to those in 0.9.62.

Opening stuff with the system default launchers is considered a feature. If those launchers are themselves sandboxed by firejail they'll inherit the chromium sandbox options and might or might not work as expected. If you prefer to disable that feature you could blacklist /usr/bin/xdg-open.

+1 for NOT using snap (and flatpak for that matter). As our man page states they use their own sandboxing technology and are not supported.

@ghost commented on GitHub (Feb 11, 2021): Please update your firejail package, the 0.9.62 version is vulnerable to [this](https://github.com/netblue30/firejail#security-vulnerabilities). You can use the [PPA](https://launchpad.net/~deki/+archive/ubuntu/firejail) maintained by one of our collaborators if the official repo's you use are not (yet) updated. The current chromium profiles block access to ${DESKTOP}, contrary to those in 0.9.62. Opening stuff with the system default launchers is considered a _feature._ If those launchers are themselves sandboxed by firejail they'll inherit the chromium sandbox options and might or might not work as expected. If you prefer to disable that _feature_ you could `blacklist /usr/bin/xdg-open`. +1 for NOT using snap (and flatpak for that matter). As our man page states they use their own sandboxing technology and are not supported.

gitea-mirror commented

2026-05-05 09:10:01 -06:00

Author

Owner

@ghost commented on GitHub (Feb 12, 2021):

I'm not a fan of snap myself, I'm doing a reinstall soon and wont be using it again. Ok np, I'll close this then.

@ghost commented on GitHub (Feb 12, 2021): I'm not a fan of snap myself, I'm doing a reinstall soon and wont be using it again. Ok np, I'll close this then.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2480

No description provided.

Rows
Columns