Firefox profile seems to leak between DispVMs

[IX4 Svs]

Qubes R3.1, Fedora 23 template, fully updated.

I launch a new disposable Firefox, which creates a new DispVM and displays [disp42] in the Firefox window title. All normal so far.

I hit CTRL+t to open a new Firefox tab and - I can't believe my eyes - the "new tab" page is full of thumbnails of web pages I have visited in other DispVMs, which have long been shut down.

sudo xl list from dom0 confirms disp42 is the only DispVM currently running.

How can such data leakage from one DispVM to another be possible? Yes, I am adamant, 100% certain that I have not visited the web sites showing up in the "new tab" page from the TemplateVM that my DispVM is based upon.

Any thoughts?

Thanks,

Alex

[Chris Laprise]

> --

Perhaps you used firefox for a while in the -dvm... Or you copied a used
firefox profile to it?

Chris

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Does it persist even after you regenerate the DVM template?

$ qvm-create-default-dvm --default-template

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIbBAEBCgAGBQJXZqaPAAoJENtN07w5UDAw1q4P93qCkIHgR9tuHihwKjt7nhIZ
TbW4kErvpKEIyUKxCIXlb8J2Chv+NoEv4oYGwjqnaWIMcQaa4kODZOtxm75IKJft
AHNg+SOWgUqSLvQ8f2dd0Z7E/8kz8xo0svdoiK/OOMD1g38DUCw6S0/jofFfiDUo
I0y9skQW/i/0OBNEyqX9qNl6IjMM+pIlfp5hTV5xqgw7P1Bxli1UlmJC7lxdjxjA
Bw94PMewThF+pnpteQMpmEGlGNlY5eHTgQTPzDppEq0G2M9k1rJaJ2QaUY/GlqMc
k3UCk7AHlA9TZFclAfXYxEvNgdZ8mstb1VnA2AXi4M9b0V/23Y9MZ7RyAgXA1VnA
x6Ca5d4LK+PDN3ElT1g1SX+6NL+CbkbckKMt0pKhfFi8twyiLotbD9BvChQwlFFS
dz85/1MrLepLpAQ2JuDHGU/KkThnUyX+vKgNZFk6zslBZe7iOBEYBgq7Z2Wpwm3G
l1qb91FBNiC9nQ0XY7cBRj5+btqM9BvY7VhujpiUqOyBjLZu17mcw28XqzdLjn6Q
aIQICm0Fi1sUgY45XYNzyp/FSIPj7X2ZaVwm2ZS91UGwvXPQNPglFOz+UjvFJR3X
C0dqnqqO1o78fU8uH98pfrO/4bvZMxbUMgqM70RhtaSs6heoMpRDQtVSnYggW+fH
fZbyHqC3wVsV21kfILw=
=U5LR
-----END PGP SIGNATURE-----

[IX4 Svs]

I have not tried the nuclear option - I was hoping to find the cause of such a massive leak now that it's happening so that it can be fixed for all Qubes users. What logs would I need to look into? Should I start a DispVM in debug mode from dom0's terminal and look at the console output? /var/log/xen/console/guest-disp43.log interestingly says:

[   18.935022] xen:grant_table: Grant tables using version 1 layout
[   18.935022] Using NULL legacy PIC
[   18.935022] PM: noirq restore of devices complete after 0.071 msecs
[   18.935022] PM: early restore of devices complete after 0.040 msecs
[   18.962927] PM: restore of devices complete after 24.821 msecs
[   18.962977] Restarting tasks ... done.
[   19.046997] Setting capacity to 20971520
[   19.260713] EXT4-fs error (device dm-0): ext4_mb_generate_buddy:757: group 49, block bitmap and bg descriptor inconsistent: 2 vs 1 free clusters
[   19.260915] EXT4-fs error (device dm-0): ext4_mb_generate_buddy:757: group 50, block bitmap and bg descriptor inconsistent: 1611 vs 1612 free clusters
[   19.261198] JBD2: Spotted dirty metadata buffer (dev = dm-0, blocknr = 0). There's a risk of filesystem corruption in case of system crash.
[   19.648563] EXT4-fs error (device dm-0): ext4_lookup:1588: inode #927: comm cupsd: deleted inode referenced: 647
[   50.944638] EXT4-fs error (device dm-0): ext4_lookup:1588: inode #927: comm cupsd: deleted inode referenced: 647
[  308.780561] EXT4-fs error (device dm-0): ext4_lookup:1588: inode #524291: comm dnf: deleted inode referenced: 524305

..but I can't think of how filesystem corruption would lead to data leaking between DispVMs.

Alex

 

[raah...@gmail.com]

I have had an issue on mutliple machines (which other users have noted in multiple threads) where the dispvm browser is unable to load due to the profile mysteriously being missing. I wish a dev would address this. The solution is indeed to recreate the default dvm, but there must be a reason for this happening. I wonder if its related to the issue in this thread.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-06-19 12:30, IX4 Svs wrote:
> On Sun, Jun 19, 2016 at 3:05 PM, Andrew David Wong
> <a...@qubes-os.org> wrote:
>
> On 2016-06-18 14:54, IX4 Svs wrote:
>>>> Qubes R3.1, Fedora 23 template, fully updated.
>>>>
>>>> I launch a new disposable Firefox, which creates a new DispVM
>>>> and displays [disp42] in the Firefox window title. All normal
>>>> so far.
>>>>
>>>> I hit CTRL+t to open a new Firefox tab and - I can't believe
>>>> my eyes - the "new tab" page is full of thumbnails of web
>>>> pages I have visited in other DispVMs, which have long been
>>>> shut down.
>>>>
>>>> sudo xl list from dom0 confirms disp42 is the only DispVM
>>>> currently running.
>>>>
>>>> How can such data leakage from one DispVM to another be
>>>> possible? Yes, I am adamant, 100% certain that I have not
>>>> visited the web sites showing up in the "new tab" page from
>>>> the TemplateVM that my DispVM is based upon.
>>>>
>>>> Any thoughts?
>>>>
>>>> Thanks,
>>>>
>>>> Alex
>>>>
>>
>> Does it persist even after you regenerate the DVM template?
>>
>> $ qvm-create-default-dvm --default-template
>

> I have not tried the nuclear option - I was hoping to find the
> cause of such a massive leak now that it's happening so that it can
> be fixed for all Qubes users.

Sorry, I wasn't thinking of that as "the nuclear option." Rather, I
was just trying to help determine whether this phenomenon is isolated
to your specific machine (e.g., perhaps you forgot that you had done
some special configuration that would be overwritten when regenerating
the DVM template) or whether it's a Qubes bug.

Personally, I haven't been able to reproduce this on my own machine
(and I haven't seen anyone else say they can either), so it's not yet
clear whether this affects any other Qubes users. If the phenomenon
were to persist even after you regenerate the DVM template, that would
be significantly more worrisome, since you said you're absolutely sure
you didn't do anything in the TemplateVM on which the DVM template is
based that might cause this.

I've never tried backing up the DVM template (since there's usually no
reason to do so), but I wonder if doing so would allow you to preserve
the current state so that you can try regenerating the template.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXaCe6AAoJENtN07w5UDAwfU4QAJCUFt26MbWKIq7WFM6x5Bxg
3PTQWyhG1paGW2wCLY2Zo6wMnyYL8uGJbXYti8QZGJgciRE9cuJWFAnfOxXs0JT8
gREib7SWIxA5ePBUhDkuN1VcFqrC3Cu9vLXQ1Tn4yChdNKg0DnYNNY3+btXjAkl1
3VOZ/b+PaQkUB8oGJG7zZ/AEO0MrVZ/nX0xRHoSyB/hITe/cpgmvSDfCAhsPEVfN
nadJYQUCsdq/a29TY6BLPshh+5VQPc9HWcxEirVrzUvrphXIFXITAg7JUmNeKc/a
9xvFH6UhvUnh6K5o/n64VGeC4wiiNJ3FvYeB6Cp+lkcvr1eRuLS7iWB5EsJdaGss
BhfdeVL46biUlLuTWklTCqJnjfQ9kfJnNR9C+UZPWDcNK+QTsgH1SA4n7Xp3BpCm
ck6ERiMK1evfzqc6ple8GZ238sR2KQJITe5Ijt5uTSBRnKa4WhjKUyOfaNbCn+HI
RRtI22GW+cTiu9OnaEGHynDYANHcW+Zez9OI/4yRa1g+2Hhd4uJqUd4ntTm7wmnv
LiEgfT0xbJxOnG7Y+8I8AB5918kV4z4WtcSC1R5/Ht7rwdnfp8DzzHUSUz/pMlnT
XIP2TwgC6q3vnd8FgjPXaKZ/S2BLnidwA1Vv8zfC2/2N+olJlUAm/eYK6wpzH//P
YWsRIKndOQwt0ZCK0um3
=T9NM
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-06-20 06:23, raah...@gmail.com wrote:
> I have had an issue on mutliple machines (which other users have
> noted in multiple threads) where the dispvm browser is unable to
> load due to the profile mysteriously being missing. I wish a dev
> would address this. The solution is indeed to recreate the
> default dvm, but there must be a reason for this happening. I
> wonder if its related to the issue in this thread.
>

Thanks for the reports. Tracking here:

https://github.com/QubesOS/qubes-issues/issues/2091

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXaCkQAAoJENtN07w5UDAwp6UQAMYVMIr4tV2UEQ2aHg45fKiK
T6W61ZHvuSRox/xLxU2Qn/6uuwUce5dvgY/cxGmAUwXxb5iHdOF8vFbyNg001y2m
68MfXIAxDIbwkEC+82oMmvu1h2ESCjp0Q8i9C5UvUU4tygIiCNs2ktcM0wxtilAA
wYv6E4568cuVpZeut8mDssAeRVx+sCvHtP1LfrTyvMA30RW5kN/dKxosyebQyS7k
mJcGJpjvTLxQNUwXeTVHD53MUCdrs1htShuls0qtZ+7d6txhxxeaL6i8BNLG+ym3
gSN1bkc+sgimpdyMi5ErLWE1xFjclL4KKYs9ytys61BSQ3xqOEbTV0UrBfAmrJQj
FBrdJCRGMa3W186Z1p7T8vqPT6ytqT3Ogab/tFXw8sqkOckYdj4tSfke4LyVGN2B
HOTuHhm6D4O7gGwyF2UkZzLlj5q0jrzbCj+RDJEYV7tLNdvWWefCtmxj1/w4nNPj
wima932pN5m8NIwpFcJy8XhCFhBXvsfsPYMi5irner+jZNAogLzD1SruUl74JNIt
7+V96YoYDNwrCC3Q2zVfreGn5EaOQ0Uga0s/YPPUYRc0D8OyU12gfBsFxna4VJwC
ZXD0ddY6X2bVMVw17P3sbVGPu3+8+ReIoStvwn2P/xBTVL74tlvA1pVYd3BBXz3R
1cFKgptBqE6SfPKRIIrn
=7LCf
-----END PGP SIGNATURE-----

[Alex]

I installed the latest fedora-23 updates, which refreshed my DispVM savefile- the behavior is now back to normal.

I unfortunately did not think to capture the old state so that it can be studied to understand the set of conditions that led to this unexpected persistence.

If there are any logs I can provide to understand what happened I'll be happy to dig them out.

Thanks

Alex

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-06-18 14:54, IX4 Svs wrote:

This issue is now being tracked here:

https://github.com/QubesOS/qubes-issues/issues/2200

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXl6uHAAoJENtN07w5UDAwpJ8QAI+YMuCE+LmJuqsrFWyq++Sn
LGR+Ug7ZILUfoKypRmtYlYaAZZa7HoB1xyiJSsDtof/YGdmGMGHIUVJsmskr6+by
i+wdVpfpBlnd2kw9UZP2rKNL+PJ1thBxJ3QfFzrHvxp/RHg4C6OGdEcamqPdIYje
7yynSpwIazkRk1r6JJeTqUqBZZ8fGAmfPCbr59QSBXrVaz0gNU/DVO0amXL3DDwN
bFZSrMF0WG16RvuKJMMb7UZlcyxrRjvI+wZNTV6Z9vHUrbxRYuz5dbxT/cNRoI/Q
NOzXtJ15nQxBgeaC+zE7V3OIRwst8cyn8ALXS7fL0PEfM/CMBV59GH7OiSFMycaQ
ksGbHGg7cz8tzQYvIzuEYqvoq8G3mY+uXT9HDGpGuHG13i/6WN/iyW9yvo16u2pu
I/SvYURqqXa0v0KtYtV2NVGVAjQafh3ciJ9DWKhjbLgSanjjUUACKu6z8qL2qNsx
uORK/Xo4Lk5HmpGIbJTBJhcxYnor+DeedTyV3UxLfRcEHJ9h5OYS0w08KGbVyQ/T
r52OeURaF/wXjRgMr0yyAIOcnbpkNG60mZpeqm8Fq4uxGXK+bENE0Ca1jq/ai10Q
OTCiTX52oSFkVBHzksSZaVyuzXtdks0fKjFw36jmurzgsRmyWOODc2RXz3HCV2VO
yomMGY3fWioipeJ0RR7k
=oZJr
-----END PGP SIGNATURE-----