Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)

[genevieve....@gmail.com]

Sorry but I almost fainted ! (I even took a picture ! I could not believe this MEGA-HUGE security flaw right in front of my eyes )

An installation error prompt this screen :

An unknown error has occurred
This program has encountered an unknown error. You may report the bug below or quit the program. (2 buttons:1st 'Report Bug' 2nd 'Quit')

More info ...
The output below may help determine the cause of the error :
[...]
#System timezone
timezone America/New_York --isUtc
#System bootloader configuration
bootloader --location=mbr
autopart --encrypted --passphrase=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX!!!!!! type=lvm
#Root password
rootpw --lock
#Partition clearing information
[...]

//
WHAT IS THIS ! I could SEE with my own little EYES my OWN "SECURE" PASSPHRASE as a STRING!!! (translated to you as XXXXXXXXXXXXXXXXXXXXXXX!!!!!!!!!!!!!)

Do I need to repeat this?? (sorry but I even took the picture with my finger in front of it so I would not to store my OWN SECURE PASSPHRASE in a picture!!!

I am a dummy but not that dumb... what is this ? Is it a mistake ? Is it supposed to be Qubes OS Untrustable OS or ?? ... Sorry, you are supposed to be good and security expert but you are asking me (THE dumb USER) to report MY OWN PASSPHRASE AS A STRING to help you?? (Such any easy way to get access to my drive! & perhaps use my passphrase to guess other passwords as well...)

I believe, without being on the "receiving" side of this report bug process(would need this to be 100% sure) that your OWN reporting bug system is giving you Qubes Users PASSPHRASE as (clear)STRING in the report ...

Your Report bug => The needed stuff &&& MY DRIVE SECURE PASSPHRASE so everyone can see it!?

This does not look very "secure" too me ... (sorry but lmao)

P-S there is also 'Debug' may take you to tty1 & Button "Debug" (lower right corner of my screen)

Have a nice day
N.B. I will not report this bug "computer" to "computer" as my own Qubes OS drive would not be encrypted at all if everyone at "Qubes OS" has MY own drive password to (de)crypt it. I am very glad your are an opensource software ... If this would have been "Windows" I might not have fainted but I might have an heart attack after reviewing this truly UNSECURED "Report"

[[799]]

Hello,

-------- Original-Nachricht --------

An 29. Nov. 2017, 00:48, schrieb:
Sorry but I almost fainted ! (I even took a picture ! I could not believe this MEGA-HUGE security flaw right in front of my eyes )

(...)

Sorry, you are supposed to be good and security expert but you are asking me (THE dumb USER) to report MY OWN PASSPHRASE AS A STRING to help you??

(...)
----------

Honestly I can't believe that this is true, until you prove this, which might be hard, as even a picture can be simple "ASCII Art".

If you are correct, this would of course mean that Qubes OS can't be trusted.
There should never be the option that a passphrase will be shown unencrypted.

Even worse including this passphrase in an error report which gets saved or transferred to a 3rd party (even if it the Qubes Team) is an absolute no-go.

As mentioned, I don't believe this.

Can you provide more guidance what you have done and what hardware you are using, so that someone can verify this problem, if it is reproducable?

Please also include all hardware specs, so that can also take this in account.

If you are right and if Qubes is Open Source the source code should be analyzed to find this "hidden feature".

But as mentioned, I think this is BS.

[799]

[Unman]

I don't see any grounds for this response.
It's perfectly possible that the installer (not principally written by
Qubes) could mistakenly include a passphrase string. I've seen similar
stuff included in all sorts of error reports in the past.
It doesn't mean that Qubes "can't be trusted"

Also, since this is an installation error, let's not over egg the problem
- it's not as if you're using that password anywhere else, or that you
will use the same password the next time you try to install, is it?

[Genevieve Gauthier]

I do not know how to help you.  I have taken a picture without removing the geotag (authentic picture /w geotag in my own living room.  the picture (one of many) is in my iphone but my own finger is hiding MY OWN PASSPHRASE... I could see it 20/20..  I still have everything I used (my own laptop), my 8gb usbstick (installer) & a 32gb usbstick.  I have removed the tag with exiftool -gps:all -xmp:all crazy.JPG ... as I intended to provide proof without everyone seeing where I am living .. but it shows my finger on my passphrase... :(

1)Now my laptop (the one I have used to copy from one usb with installer to the other) is still there "intact" .. 

2) The usb installer I used I have reformated it to reinstall (because of this bug) .. but it tested fine.  (so any media that tested fine should be ok)

3) The usbstick that I intended to install it on (the 32gb) is still there ... 

What do you need me to do ? I do not expect my authentic/original (with my finger) in front of my password would convince you ... 

Should I need to focus on recreating the same condition that produce the bug (my own) in the first place and take an original picture without my finger to hide this problem (using another password like what? 

Than I am sure with all you superior computer skills you could authenticate my picture as unaltered ... However, are you able to create ANY installation ERROR ?? This would validate with your OWN EYES what I have seen! (100% to authenticate for you)

2nd option :  I believe someone with any strong programming skills should look carefully at the part in Qubes 4.0 rc3 where ANY ERROR in the installation of Qubes 4.0 rc3 and the lines that created this splash screen ('report bug').  This would in my opinion be a far more SUPERIOR way to confirm what I have seen ... (unless you are able to create your own installation error and see it 1ST OPTION)

I could be lying as anyone could be lying. The only way for you to know for sure is to investigate this! I cannot do this myself because I have stopped programming a couple of years ago and my skills are too "limited" to review the code...

3rd option : (try recreating my bug on your/any system to see it for yourself) 

As far as my intuition goes.. the bug happened several times (still the same report to Qubes where I could see my drive PASSWORD ) .. my 8gb tested 100% 

my system is a dell laptop (but that should not have created the problem) 

I try to install from my 8gb 100%tested media to my 32gb usbstick (sandisk 32gb).  My 32gb sandisk was full.  I have numerous pictures because I intended to create a step by step guide to help my friend install Qubes.

3rd option (my technical date) I can see on another picture Local Standard Data : 28.64gb SanDisk Ultra Fit sdb / 0 B free 

I have another picture with the content of this usb stick (partition) : Unknown Iso9660 sdb

I tried to automatically configure partitioning.

I do not have a picture of this but I remember there was a problem.  So, I switched to "I will configure partitioning" (this is where I have a picture of this Iso9660 which I do not even know what it is .. :( 

Then I remember and have a picture of trying to press the "-" button after clicking on this strange partition on my Sandisk 32gb usbstick 

I know I had problem because I have a picture of showing "Click here to create them automatically"  but it never worked

then this splash screen appeared to report this unknown error.  ( I have a picture but my finger is hiding the proof itself!)

I do not know a lot about computer but I have a 20/20 vision.  I tried to read everything so I could understand howto fix it ... then I saw my own PASSWORD after the autopart --encrypted --passphrase (as described)

You would need to provide me guidance .. however, this is the best I can do.  Are you able to create a "full usbstick" like mine with this type of partition (Iso9660) ?? Perhaps if you try to do as I did, you will have the same result and this would be 100% proof.  

Sorry, my computer skills themselves are too low to be able to know where in the code is hidden the report bug of the install in the code itself.. However, with the information I have provided .. I can tell you that I do not have the skills to even know how the programmers themselves programmed this report ! 

If you provide me with simple step and simple questions to try to recreate what I did, I will answer them as well as I can but there is no way to check the code for myself because even if I were to see it I would not know what I would be looking at .. Sorry :( 

I hope this is enough so you can try to "FORCE" a error and see this MEGA-HUGE flaw with your own eyes.  This way, you would believe it without having to rely on "untrusted" data on a qubes-users google group.

  

Have a nice day.  I need to get some sleep but I try to answer you if you have any question (please explain everything if you need something too technical from me to make your own experiment!)

p-s my sata was disabled on my laptop so I could only see my usbstick (I do not know if this will help you or not)

[[799]]

Hello Unman,

It's perfectly possible that the installer (not principally written by

Qubes) could mistakenly include a passphrase string.

As far as I have understand, the problem is not that the password is shown, but that the report with this error mistake and the password could get transferred. I don't want that my password gets transferred in some part of an error report.

I've seen similar stuff included in all sorts of error reports in the past.

This might be true, but this doesn't make this less harmless, if the password is really bundled in an error report that gets transferered somewhere.

It doesn't mean that Qubes "can't be trusted"

Wait, it's not (!) about blaming the Qubes team.

If my understanding is correct, and the password is included in an error report that gets transferred to a 3rd party, this is a really bad thing as something like this should not happen from my understanding.

[799]

[Tom Zander]

On Wednesday, 29 November 2017 08:51:33 CET '[799]' via qubes-users wrote:
> As far as I have understand, the problem is not that the password is
> shown, but that the report with this error mistake and the password could
> get transferred. I don't want that my password gets transferred in some
> part of an error report.

Thats not what the guy wrote. He said that it was showing on screen in an
error dialog.

The problem seems to be that the password is requested from the user and
then kept in memory to be passed to specific tools that do the work while the
installation is ongoing.

Then if the installation goes wrong it prints the log of what has happened
so far, and that contains the password.

I have seen no indication that the password is kept after the installation
has completed and operations are given over to Qubes-OS.

I agree its rather sloppy, but as far as I know the installer has no option
of reporting issues. I don’t even think you connect to the network at all
(did you type your wifi password, I never did).

So, lets allow the devs to fix this without making this into a bigger thing
than it is.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

[Tom Zander]

On Wednesday, 29 November 2017 02:40:01 CET Genevieve Gauthier wrote:
> What do you need me to do ?

Please expain in a little more detail what versions of the software you were
using, what steps we might follow to reproduce the problem.
For instance which screen was the last thing that was on before this error
popped up.

Cheers!

[Unman]

> - cant be trusted" quote came from your previous comment.

I dont think there's any evidence that the error report DOES get sent to
a 3rd party is there? (Qubes? Fedora? NSA?)
There are install logs in /tmp which are stored in RAM, and disappear
after the installation process ends/aborts. The same would likely appply
to this report.

In the Fedora documentation there ARE methods described for getting bug
reports out of the install process, but they require active intervention
from the user (copy to another drive or scp across network). There's no
suggestion that these reports would be automatically submitted.

I've had a quick look through the code and i dont see any mechanism for
passing on bug reports - but it was a very quick look.

I havent seen a bug report from anaconda, but looking at the install
logs there is material that privacy minded individuals might object to
including in there.

Until there's some evidence that the bug report is actually sent off the
system I continue to think this is over egged. Even if it is transferred
to dom0 (IF), it doesnt pose a huge security risk. IF it were copied to
unencrypted /boot that would be an issue.
But just preparing a report that includes a password doesnt seem in
itself to be a major issue.

[genevieve....@gmail.com]

On Wed, 2017-11-29 at 15:59 +0000, Unman wrote:
> In the Fedora documentation there ARE methods described for getting
> bug
> reports out of the install process, but they require active
> intervention
> from the user (copy to another drive or scp across network). There's
> no
> suggestion that these reports would be automatically submitted.
>
> I've had a quick look through the code and i dont see any mechanism
> for
> passing on bug reports - but it was a very quick look.

Interesting & very good to know this but that would have surprise me a
lot from a Qubes OS installation. Have you learned if it is specific to
Qubes 4.0 rc3 (perhaps the installation part has been there for a long
time before this release) ?

3-4 questions remains for me. If you can learn those answer in the
future, I believe this issue would have been truly investigated for me.

With an "active" intervention from the user (or if I had connected to
the internet and submitted my report from my computer to the computer
receiving those reports)

1.1 : Does my passphrase would have been transmitted ? YES/NO ?
1.2 encrypted along the way ? YES/NO ?
2.1 : If YES 1.1, where/who does the passphrase would have been
transmitted/ transmitted to
2.2 : Who would have had access to this information ?


I am not looking for an immediate answer. However, I am still curious
about all this. Such a strange 'Bug Report' to see it like this..
Seems complicated to use those information to comprise the whole system
via dom0 (that's good)

P-S & It means, I can continue my own little project of giving Qubes
usb stick to people around me so they can access their bank account
online without having to worry about being on their "vulnerable" (or
even worst compromised win10 OS) windows OS. Futhermore, I feel you
have made a great job at Qubes OS so it would be simple for me to teach
people how to open a disposable-vm for this purpose and this purpose
only (without really having to learn about Dom0 or about this
fascinating architecture if they are not interessed). Love the Qubes
"color code" BTW. It will make my life very easy when I'll explain to
people which color they must see on their browser to feel more secure
without having to teach to any grandparents about VM, Xen Hypervisor
and Dom0 interaction lol) Just using a linux distro would be superior
I think.. but Qubes and a disposable-vm seems perfect to be just to "go
to the bank online" if you are old and know little about computers. The
cost of this is idea is minimal too (really just having a 32gb usb
media lying around). I do not think those would have been targeted
Qubes user. Qubes does not even need any modification for this
project. I will be able to teach to many people in less than <30
minutes I think with one demonstration during the holidays. Better
safe than sorry and with no money ! Agree ? :-)

Take Care & Thank you

[Andrew David Wong]

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

Hi all,

After checking with the Qubes Security Team, I'm happy to report that
there is no cause for alarm here:

1. For security, networking is always disabled in the Qubes OS
installer, so you would not be able to send that bug report (or
anything else, for that matter), even if you wanted to. Disabling
networking during installation is necessary for Qubes to protect
itself before it creates a NetVM (and hence before the network
stack has been isolated).

2. We agree that sensitive user data, especially passwords, should never
be included in bug reports. The last thing we want is for any third
party (least of all us) to see a Qubes user's private data. In fact,
you can think of the entire Qubes OS Project as working to ensure the
exact opposite. :)

3. Qubes OS uses an installer called Anaconda [1], which generated the
bug report you saw. After it performs an installation, Anaconda saves
the data from that installation in /root/anaconda-ks.cfg. We have
verified that the LUKS (disk encryption) password is not stored in
this file. Only a hash of the user account / screen locker password
is stored there (not the password itself, and not even a hash of the
LUKS password is stored there). We have also filed an upstream bug
report with Fedora about Anaconda including the LUKS password in the
bug report. [2]

[1] https://en.wikipedia.org/wiki/Anaconda_(installer)
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1519895

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

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJaI0jZAAoJENtN07w5UDAwYMsQAKkgoqP4VzitWKissQr9ls2c
kYpXuOCD9WWj9toAg2weK82W8YvCqMBhuuZfO7UUR1qyYE1d3F8g79dvKBDj1tGD
JiNXoaJSPpsjyOpGEMcZAF+5dLtDfZqrfdY6LewpRQ18aIsRy/j3fLOVsnWNTATv
2g1RVRij1Z4nZn4kjr5oP99k+u9z/IBMR9QFo6L4D8+Mxb3mGXOCQqOxVkXuDojP
5vw7b5ICEPbmQRVbylmbuXA2RpQ/I6LPsNR7vELtMoQGyEHN7JHnHlU4sM0tkh8V
qiqG5u6g1cqoZs+SvspFz9xd1idrtx8zFvlZFtAXWDsM7M5pfJCbtTPnKRlk4iEQ
dGabpRYco/+E9fos7k+ypsP3iqh/sLB8mHxkMPcdDdmJTLZYqj7pRUqOX3e+AiRs
QAZ8oOKFMEhmVmKbNWoArE9WNiT7w1zjzywUPuxWN/4nOVcm0TTqnOGGNHP2Ys8C
wqOZ7bOnA089mPR8WNYN8JSHiAqd2JpLJQlmSjUUp4kQWfczaCiRh7CodgInihL9
+R++lcCNAQ2c+T9LeUwwa0ibXYiOHWVewMP9tg1K7fVa7nDZXzn3O7LSyw31FcXF
2eoFusB7Ot+GKeDWTPMlRELy2iEaa46oQc1veE3FoU6s9biYw7wrIKRpwEO5Gpu7
wTfnq1qL23hv5QbnlE/E
=I7ZH
-----END PGP SIGNATURE-----