Reply to thread

Message

<blockquote data-quote="Victor M" data-source="post: 1085645" data-attributes="member: 96560">a. It is written in the old style unix coding practice. It relies on an army of helpers in /bin, especially on initialization. Although the included Apparmor profile lists them out, thus identifying them and constrains the app bundle. It does not help that an attacker has access to this army of utilities, significantly easing her attack.b. A snap or flatpak or docker just bundles the correct libraries and correct utilities an app requires. It protects the Integrity of the app itself. And the virtualization of a snap makes it impossible to modify that bundle. But who says the attacker has to modify the bundle? Firefox has a big @{HOME}/snap/firefox directory where it stores it&#039;s scripts and settings. My red team has demonstrated that they can gain persistance there and setup monitoring.c. There exists a directory named StartupCache inside Firefox&#039;s settings directory. In there is a bin cache file that supposedly stores multiple startup scripts, ready to be extracted and run. This arrangement cannot be protected by Apparmor, which relies on having discrete script files and program files which Apparmor can either allow or disallow. Having them all stored in a single bin cache is just un-securable.Lets face it, you are at risk when you use the Ubuntu bundled Firefox even with it&#039;s bundled Apparmor profile. The attack technique demonstrated is probably not unique; other seasoned attackers would have arrived at the same approach. Use a properly defined Apprmor profile for your browser and make sure it constrains any program/script execution inside the browser&#039;s own settings directory, where an attacker will probably first land. I just wrote one for Chrome.</blockquote>

[QUOTE="Victor M, post: 1085645, member: 96560"] a. It is written in the old style unix coding practice. It relies on an army of helpers in /bin, especially on initialization. Although the included Apparmor profile lists them out, thus identifying them and constrains the app bundle. It does not help that an attacker has access to this army of utilities, significantly easing her attack. b. A snap or flatpak or docker just bundles the correct libraries and correct utilities an app requires. It protects the Integrity of the app itself. And the virtualization of a snap makes it impossible to modify that bundle. But who says the attacker has to modify the bundle? Firefox has a big @{HOME}/snap/firefox directory where it stores it's scripts and settings. My red team has demonstrated that they can gain persistance there and setup monitoring. c. There exists a directory named StartupCache inside Firefox's settings directory. In there is a bin cache file that supposedly stores multiple startup scripts, ready to be extracted and run. This arrangement cannot be protected by Apparmor, which relies on having discrete script files and program files which Apparmor can either allow or disallow. Having them all stored in a single bin cache is just un-securable. Lets face it, you are at risk when you use the Ubuntu bundled Firefox even with it's bundled Apparmor profile. The attack technique demonstrated is probably not unique; other seasoned attackers would have arrived at the same approach. Use a properly defined Apprmor profile for your browser and make sure it constrains any program/script execution inside the browser's own settings directory, where an attacker will probably first land. I just wrote one for Chrome. [/QUOTE]

Verification