Re: [qubes-users] New Foreshadow exploits CPU bug

2018-08-21 Thread 'Leo Gaspard' via qubes-users
On 08/21/2018 11:39 AM, taii...@gmx.com wrote:
> SGX is another ME service slash intel marketing gimmick invented for DRM
> not security.
> 
> If the person who purchased the computer can't examine the VM's running
> on it then they are not owning it simply licensing it which is why SGX
> is a bad technology and people shouldn't buy x86.
Consider you want to deploy your things in the cloud, eg. because it's
less expensive. Then I guess you would actually like to not have to
trust the cloud provider :)

You still have to trust Intel for actually doing what they promise, but
you have to trust the processor manufacturer at some point anyway.

Not saying SGX actually meets its promises, though, just reacting to
your second paragraph. There are use cases for having the person who
owns a computer not being able to examine VM's running on it. Whether
you want or not to use or have them is a different question.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b3d6a5d2-215b-ac7e-28b5-d50b01ff77b3%40leo.gaspard.ninja.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Critical PGP bugs. Do they possibly affect Split-GPG in Qubes?

2018-05-16 Thread 'Leo Gaspard' via qubes-users
On 05/16/2018 11:20 PM, Ilpo Järvinen wrote:
> On Wed, 16 May 2018, taii...@gmx.com wrote:
> 
>> On 05/15/2018 01:22 AM, john wrote:
>>
>>> On 05/14/18 14:58, Ángel wrote:
 This paper is most interesting for the discovery of multiple ways email
 client leak information on visualization.
 (not clearly stated in the paper: some of them are already fixed, while
 in other cases the developers are still working on providing them)

 Luckily, with Qubes it is easy to set a firewall rule so that your email
 AppVM can only contact with your email server.
 NB that some of these leaks are dns-based, so ideally you would not
 allow it to perform any dns query, either.

 Best regards

>>> can you give an example to the steps to   make such a fw rule,   if
>>> it's that simple  please ?
>> I would suggest simply only allowing the ports you need for your email
>> client.
> 
> It's much less secure approach than blocking all but the email server 
> address. With a port filter, the attacker only needs to use that same 
> port for the attack to succeed.

That's true, except HTML engines like the ones used by this attack
should disallow eg. loading an image from port 25.

For instance, firefox blocks at least ports 993 and 587, the only two
that should be used by a reasonably recent and secure email setup.

So that's not a solution against an arbitrary attacker, but that's a
solution against the currently-spoken-about attack.

BTW, if you really want to protect yourself from an arbitrary attacker,
you'll want to protect against an attacker that has root on your email
VM. And that means
 1/ setting firewall rules in the FirewallVM, not in the email VM, as
the latter could just be removed by the attacker
 2/ all kinds of hardening against side-channels for compromised VM
communication, that are currently not possible with Xen (and possibly
not even with any widely-spread hypervisor, as that would likely entail
a huge performance cost)

Another solution for 2/ could be to never run the email VM at the same
time as another potentially-compromised VM, but that very much restricts
what you can do. And that can maybe (now that's all hypothetical) still
be by-passed with side-channels through eg. LVM's thin pool allocator,
as IIRC Qubes4 uses LVM thin pools as storage backend. (still haven't
migrated…)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/436c6811-9ca0-bd0b-0c21-f2097248d43c%40leo.gaspard.ninja.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Critical PGP bugs. Do they possibly affect Split-GPG in Qubes?

2018-05-14 Thread 'Leo Gaspard' via qubes-users
On 05/14/2018 02:45 PM, mossy wrote:
> embargo broken early, attack/vulnerability details here --
> https://efail.de/
> 
> (and yes it seems like disabling HTML will mitigate the most
> reliable/least complex attacks)

Incidentally, the GnuPG press release, that raises the point that the
paper may not be totally correct:

https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060334.html

Also if I understand correctly the latest exchanges from the GnuPG ML,
Enigmail 2.0 is safe from attack except for 3DES ciphertext, so the
attack could there only turn enigmail as a 3DES-ciphertext-decrypting
oracle.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e69a90c3-0c95-2ece-a356-d2e860b74276%40leo.gaspard.ninja.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Critical PGP bugs. Do they possibly affect Split-GPG in Qubes?

2018-05-14 Thread 'Leo Gaspard' via qubes-users
I can't tell for sure for not having read the paper, but it sounds like
too much hype for vulnerabilities not so important:

https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060317.html

https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html
(Werner being the maintainer of GnuPG)

So I wouldn't worry about (but why not disable automatic
decryption/verification of incoming emails in the meantime, doesn't cost
much)


On 05/14/2018 10:33 AM, magionemagi...@gmail.com wrote:
> I know that right now details are sketchy but the advice of disabling PGP is 
> sound at least until we get to know more information, especially since it's 
> coming from reputable researchers and the EFF (links below but I guess 
> everybody here already knows about that), so obviously that there is ground 
> for worry. 
> 
> Do any of the Qubes users or devs know more at present about this issue or 
> have advice to provide, aside from waiting for the publication of the 
> research paper tomorrow morning (15th of May) and stopping using Split-GPG 
> for the time being as a precaution?
> 
> https://www.eff.org/deeplinks/2018/05/attention-pgp-users-new-vulnerabilities-require-you-take-action-now
> 
> https://arstechnica.com/information-technology/2018/05/critical-pgp-and-smime-bugs-can-reveal-encrypted-e-mails-uninstall-now/
> 
> Thanks.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/55413b21-14d9-b470-37c1-55433c1db6cf%40leo.gaspard.ninja.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: R4.0 drops USB data

2018-03-08 Thread Leo Gaspard
On 03/08/2018 02:12 PM, Ed wrote:
> [...]
> 
> Are you passing the device through to another VM?
> 
> The USB pass-through method has given me issues in the past for devices
> that use a lot of bandwidth (webcams), though you are saying data is
> lost after only a few bytes, I still might be suspect of the USB
> passthrough system in qubes...
> 
> So if you ARE passing through you might want to try running the scanner
> software directly from sys-usb to see if you can eliminate the USB
> passthrough as a source of problems.

Oh, I thought it was a hardware issue, but did hit the same issue (on
R3.2, haven't tried R4 yet). FWIW, [1] references this issue along with
a potential workaround.

That said, running still more things in sys-usb just increases once
again the attack surface to sys-usb, which is already way too high imo,
so that workaround isn't perfect…


[1] https://github.com/QubesOS/qubes-issues/issues/2594

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/405d23b9-a58c-4047-ff17-7817dcfac239%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: porting to ARM

2018-01-12 Thread Leo Gaspard
On 01/12/2018 12:45 PM, 'awokd' via qubes-users wrote:
> On Fri, January 12, 2018 8:59 am, Ph.T wrote:
>> . my initial motivation for ARM was that
>> intel seemed more prone to #spectre than ARM;
>> https://developer.arm.com/support/security-update
>> "majority of Arm processors are not impacted
>> by any variation of this side-channel speculation mechanism."
> 
> AMD is less prone than Intel too. :)

The vast majority of ARM processors that are not impacted by spectre is
the one that doesn't do speculative execution, afaik. So that's
basically all the “embedded” ones you wouldn't want on a desktop
computer because they are too slow. Then hopefully I'm not thinking of
some processors that would be both unaffected by spectre and
performant... :)

>> and is ARM saddled with ME or SMM? ...not sure.
> 
> It has https://www.arm.com/products/security-on-arm/trustzone, but I don't
> know if owner controlled implementations are available or not.

I don't know TrustZone, but TrustZone-M (on Cortex-M's, embedded world
processors) you can choose what code runs in the TrustZone-M (which is
quite the point) [1]. A quick google search also makes me think with
TrustZone-A too (the “performance” branch of ARM), eg. on RPi, you can
run custom code in it [2], though I haven't read the full paper.

That said, for security reasons it is necessary to lock down the secure
OS in order to prevent offline modification, as it would pave the way
towards evil maid attacks. [3] seems to give ways to do that. And so
manufacturers could, if they wanted to, decide to just sell the chips
with locked-down secure OSes, not giving any way for the user to change
them.


[1]
https://link.springer.com/chapter/10.1007/978-3-319-66332-6_12?no-access=true

[2] https://arxiv.org/pdf/1605.07763.pdf

[3]
https://www.sbs.ox.ac.uk/cybersecurity-capacity/system/files/ARM%20Security%20Technology.pdf

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e2595cd9-1d69-0430-5a02-d1b2c01c6cf7%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.


POWER9 (was: Re: [qubes-users] Re: porting to ARM)

2018-01-10 Thread Leo Gaspard
Am I the only one to notice you brought up POWER/TALOS something like
five times in the last week, even when the thread originally had nothing
to do with it (like this one)?

I get it you're enthusiastic about an open processor getting actually
used (unlike RISCV) (and must say I am too), but it's not really an
option for Qubes (which is the topic of the mailing list), so long as
no-one has ported Qubes to it (and unless you have a lot of money I
don't see anyone deciding to port Qubes to POWER only based on your
assertions).

However, even with open hardware design, all problems are not solved.
For once, there is no real checking of whether the product you buy
actually matches the specification you received. (And the main issue
with Intel ME or Meltdown/Spectre is actually that the implementation
doesn't match the spec, as the spec is safe.)

For instance, I recently heard of a paper at a cryptographers'
conference (don't have the reference, sorry), where researchers designed
a hardware implementation of AES that worked perfectly, then changed
three wires, and had a hardware implementation that still worked
perfectly -- until you change a bit the frequency, and then the
encryption is utterly broken. Three wires at 14nm on modern systems with
the 8G transistors of POWER9, good luck to spot them.

Oh, and also contrarily to what you say POWER9 is not more
owner-controlled than amd64, at least according to the specification
(and as stated before the implementation does not necessarily match the
information you are given).

That said, the two big advantages of POWER9 (or RISCV) to me are that it
democratizes the idea of open hardware, and that bugs in it could maybe
be found more easily than if it was closed-source (even though it's
doubtful Meltdown/Spectre would have been found more easily were the
implementation open -- the fact that POWER9 is also vulnerable to them
is an element of proof towards that). As the chip is actually not really
possible to check, it doesn't help with voluntarily inserted backdoors.

Just my 2¢ :)
Leo


On 01/11/2018 01:25 AM, taii...@gmx.com wrote:
> On 01/10/2018 05:34 PM, Vít Šesták wrote:
> 
>> Maybe absence of suitable hardware is the reason why we don't have it.
> The target I imagine would be ARM servers with performance ARM CPU's
> such as the ones from Gigabyte running AppliedMicro CPU's.
> 
> Unlike the high performance POWER these ARM CPU's suck at single
> threaded tasks and are not owner controlled like POWER AFAIK so I don't
> think it is worth it.
> The only reason to do so would be the already available xen vs no xen
> ATM for POWER - but you could definitely do it and it would run qubes
> satisfactory.
> 
> And yes ARM has a kind of IOMMU, I believe it is called GIC-v3 but not
> available on the average ARM stuff like a laptop or phone.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5bb92339-c4a1-3229-f086-29e089b1d578%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Mozilla

2017-12-27 Thread Leo Gaspard
On 12/27/2017 07:38 PM, taii...@gmx.com wrote:
> On 12/26/2017 06:34 PM, Leo Gaspard wrote:
> 
>> (disclaimer: I once was an intern for Mozilla, though I do not have any
>> bond with Mozilla right now)
>>
>> tl;dr: please do google for “looking glass” and “mozilla”
>>
>> Erhm. This is a *really* biased way of putting things. They did push an
>> (opt-out) study through the (opt-out, iirc) studies subsystem, that did
>> have the ability to alter page content.
>>
>> That said, the add-on was not programmed to not show up in the ‘add-on’
>> screen (that I know of), it was just a regular opt-out shield study.
> No one wanted that dumb addon and most users aren't going to opt-out -
> that is why "opt out" systems are a scam; what mozilla did was
> incredibly wrong and I can't believe you are sticking up for them
> without even receiving a full time wage from mozilla.
> 
> How many things does the average person need to keep track of when it
> comes to opting out? did you know that if you get in to an accident and
> need blood transfusions the local hospital may give you synthetic blood
> that increases the chance of dying? guess you had better opt-out of that...

Once again, I'm not saying anyone wanted that add-on. But not opting-out
of it caused no harm, nor was it meant to cause harm. I'd rather follow
Hanlon's razor and never attribute to malice that which is adequately
explained by stupidity, but that's only my opinion. That's basically all
I was saying.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bd285322-4207-d5a3-005e-da4854a6ed6c%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.


Mozilla (was: Re: [qubes-users] Password security/disposable vm security)

2017-12-26 Thread Leo Gaspard
On 12/26/2017 03:25 PM, 'Tom Zander' via qubes-users wrote:>>
"Personally, I' d avoid thunderbird and anything from mozilla, but thats
>> just me."
>> Do they have a bad track record(I planned on researching my apps later
>> =p).
> 
> Just last month they added an invisible plugin in their binary builds which 
> was programmed to not show up in the 'add-on' screen and had the ability to 
> alter page content.
> Someone didn't actually program it well enough and the whole thing got 
> leaked and after a lot of heat, a lot of bad press they eventually 
> apologised.
> 
> I'm more concerned that they tried then how they failed.
> It leaves a bad taste in my mouth.
> 
> Google for "looking glass" and "mozilla" if you want to know more.

(disclaimer: I once was an intern for Mozilla, though I do not have any
bond with Mozilla right now)

tl;dr: please do google for “looking glass” and “mozilla”

Erhm. This is a *really* biased way of putting things. They did push an
(opt-out) study through the (opt-out, iirc) studies subsystem, that did
have the ability to alter page content.

That said, the add-on was not programmed to not show up in the ‘add-on’
screen (that I know of), it was just a regular opt-out shield study.

Now, the handling of this particular instance has indeed been stupid:
this study was actually no study, but a promotional event organized with
the Mr. Robot series (which explains the ability to alter page content,
though I'm obviously not saying anyone wanted it), and in addition to
this it appeared with the suspicious “My reality is different than
yours” message, which made some users think they had been infected by
some virus.

So I'm not saying this was not a particularly stupid action and that
they did not end up with woefully bad press (especially damaging given
they had just outed Firefox 57 and its long-awaited changes), but it's
nowhere near as bad as what you imply, ie. that they would already have
willingly pushed a malicious add-on.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/421f892b-2758-d853-1bea-33b9e1bc24f1%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Suggestions (for forum posts)

2017-12-03 Thread Leo Gaspard
On 12/03/2017 04:02 AM, Andrew David Wong wrote:>> No, a Google Account
is not required. Many people who use the
>> Qubes mailing lists never create one. If you're subscribed to one
>> of the lists, you should be receiving every message sent to that
>> list. (Of course, you won't retroactively receive emails that were
>> sent to the list before you subscribed.)
> 
>>> Really? I must be doing something wrong. I had origonally sent a
>>> message to qubes-users+subscr...@googlegroups.com and got a
>>> confirmation message but I dont get any messages except some of
>>> the responses to my posts that I sent to
>>> qubes-users@googlegroups.com I will read the mailing list page
>>> again because I think I have missed an important detail
> 
> I just tried to search for your email address in the list of
> qubes-users subscribers, and it's not there. So, it looks like your
> address was never successfully subscribed, or it was unsubscribed at
> some point. I recommend that you try to subscribe again.

Hmm, just a suggestion: if people aren't expected to Cc: everyone
involved in a thread when replying, maybe it'd be better to set the
google groups to only allow incoming messages from subscribed email
addresses only? The error message is not very informative, but it would
avoid issues like this one, by forcing people to subscribe before asking
questions? Then it's less user-friendly, so there's a choice to be made,
if it hasn't been made already.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2bcba28b-42ad-85bc-ab29-e34f3efc2d6d%40gaspard.ninja.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes support Secure Boot

2017-12-02 Thread Leo Gaspard
On 12/02/2017 03:11 AM, taii...@gmx.com wrote:
> On 11/23/2017 07:55 AM, Leo Gaspard wrote:
> 
>> Can you please avoid ranting against secure boot once again?
>>
>> Secure boot is *not* useless. It *does* bring security benefits,
>> although not as good as measured boot with a TPM: it requires an
>> additional flaw somewhere in the {BIOS, bootloader} to bypass, instead
>> of just coming in and replacing a non-encrypted element of the bootchain
>> by taking the hard disk out of its case without ever being noticed. So
>> if you have no TPM, using secure boot is a definitive security
>> enhancement.
> The "linux" SB (ie: red hat signed grub) is only for signed grub it
> doesn't sign the kernel or the initramfs, one can also mess with the
> BIOS or ME which is well within the skill level of a state attacker such
> as the MSS.

Ugh. Red Hat signed grub is not at all the only secure boot available
for linux: YOU CAN REPLACE THE KEYS IN YOUR UEFI WITH YOUR OWN. (sorry
for yelling but I think I've written it one too many times, maybe this
way it'll better stand out)

Please check [1] if you want to know how to do it by yourself.

As for signing the kernel or the initramfs, grub can also check the
signature of the kernel and initramfs, see [2] also (which does exactly
the same thing as secure boot except here grub is directly included in
the BIOS, so there is no need for signing it)

> There are also a variety of SB exploits/bypasses.
Of course there always will be flaws on systems, but does it mean you
shouldn't try to harden everything possible? Flaws can most often be
fixed, non-existent feature cannot

> Irregardless it'll be what eventually kills linux on the desktop for the
> average person after the vendors stop including the linux signing key
> (SB 2.0 specs don't obligate them to allow for owner control or even the
> inclusion of the second key unlike SB 1.0 specs), if you desire such
> features it would be much better to simply use a bios-embedded GRUB2 via
> coreboot which supports kernel/initramfs signing features.

Now you are just designing a future you don't like and state “that's
what will happen”. Sorry if I'm no seer, but for the desktop I haven't
owned yet a computer that doesn't allow one to change the keys, and thus
see no reason to believe what you are saying.

Also, libre/coreboot is a nice way to have a level of security
equivalent to secureboot (maybe slightly better because there is one
less step in the boot chain, thus one less possibility of flaw). But
then coreboot is not available/working on all hardware platforms, while
SB is, and the two bring equivalent security.

> "Secure" Boot is a MS trojan horse.

There is no argument to support this assertion. Please once again stop
spreading FUD.


[1]
https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot

[2] https://libreboot.org/docs/gnulinux/grub_hardening.html

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/16f4d3dd-df08-5af6-4c64-8e29f9bc94e7%40gaspard.ninja.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes support Secure Boot

2017-11-23 Thread Leo Gaspard
On 11/23/2017 03:35 AM, taii...@gmx.com wrote:
> On 11/22/2017 07:25 PM, xeph...@gmail.com wrote:
>> This is quite late, but now that UEFI is supported...is secure boot? 
>> Wasn't quite sure what key or signature to import.
> Why are all the newbies here so obsessed with a microsoft technology?
> 
> Just shut it off, it provides no benefit to you. If their code is so
> great and beneficial to you why not simply install windows 10? they say
> it is safe and secure just like SB 2.0...
> 
> [... more of the same]

Can you please avoid ranting against secure boot once again?

Secure boot is *not* useless. It *does* bring security benefits,
although not as good as measured boot with a TPM: it requires an
additional flaw somewhere in the {BIOS, bootloader} to bypass, instead
of just coming in and replacing a non-encrypted element of the bootchain
by taking the hard disk out of its case without ever being noticed. So
if you have no TPM, using secure boot is a definitive security enhancement.

That said, to answer the original question, Qubes doesn't support secure
boot out of the box yet as far as I can tell.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8753bf33-356b-33e7-85e8-c4c542c92226%40gaspard.ninja.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes & Quantum decryption Immunity

2017-11-12 Thread Leo Gaspard
On 11/12/2017 10:43 AM, Yuraeitha wrote:
>> As for quantum networks, they are slightly more obtainable than, say, 
>> moon rockets.
>
> [...]
> Given the fiber internet network might be able to carry these signals, it's 
> not farfetched to imagine we'll start to have portions of Quantum internet in 
> less than 10 years. It's a cheap technology too. While sure such research 
> costs a lot to do, the technology itself should be relatively cheap, and a 
> lot of the quantum computing research costs come from universities whom give 
> away their research fore free mostly now a days (Open Science movement, kinda 
> like Open Source movement).
> [...]

The issue with all current quantum-physics-based encryption that I know
of is that it requires a direct fiber link between the source and the
destination. Also, the segment length is currently about ~4-5km if I
remember correctly, though it may just as well have changed since a few
years ago.

But this direct fiber link means quantum-physics-based encryption will
never be end-to-end between you and the website you are visiting. And if
this quantum-physics-based encryption is terminated by eg. your ISP (the
only one you have a physical fiber link to), then your ISP could use the
exact same techniques as before to spy on you.

Basically, quantum-physics-based encryption is nice in that it is
demonstrably secure (modulo Bell's inequalities, last time I checked on
this is getting quite old, so I'm not sure about every detail). But its
constraints of use are really huge, so it is not likely to ever get in
your house unless you're at the head of a billion-dollar-level entity,
be it a state or a company.

> I've wondered for a good while if splitting up an symmetric encrypted file in 
> multiple of parts, say for example minimum two parts, and send one over the 
> internet, and carry the other on yourself in person, that if only one part is 
> stolen (for example someone steal your laptop with sensitive competitive 
> business trade secrets), then it's still uncrackable? However it's mostly 
> been a fun thought experiment, I never managed to confirm it, but I imagine 
> businesses or even government agencies would want to use such approaches if 
> its applicable?   If it isn't already.
Such a scheme is Vernam cipher. It is the only other provably secure
cryptographic system that I know of (all the others are based on “we
think this problem is hard, so let's prove the cryptosystem is at least
as hard as this problem”).

Basically to encrypt a N-bit-long message, you generate a N-bit key
(with perfect randomness, which is a point where the issue usually
lies), you xor it with your message, and to decrypt the message you just
xor again the encrypted message with the key. You could then just send
the key and the encrypted message through the two means.

Funnily enough, Vernam ciphers are actually the basis for
quantum-physics-based encryption. The quantum channel is only used to
generate the random N-bit key in way so that it is shared by the two
protagonists and no eavesdropper could get a reasonable amount of bits
without being detected (in which case the transmission can be cancelled
without ever using the key)

Cheers & hope that helps,
Leo

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/966f5e22-8a2c-6386-c2b5-ea2dcafb7eb7%40gaspard.ninja.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Is there a way to use secure boot with qubes?

2017-11-11 Thread Leo Gaspard
On 11/09/2017 12:27 PM, blacklight wrote:
> On Wednesday, 8 November 2017 20:52:14 UTC, Guerlan  wrote:
>> My computer complains about bad signature when I try to install qubes. Is 
>> there a way to install it without disabling secure boot? Does qubes support 
>> secure boot? Is there a way to install qubes keys on the BIOS? Why did it 
>> reject the keys?
> 
> the question is more that if secureboot supports qubes, rather than the 
> otherway around.  to be supported by secureboot, one would need to buy a very 
> expensive license from microsoft, something qubes is not able afford atm.

This is wrong.

On many computer UEFIs, you can add additional root keys. Qubes could
have a Qubes key available that people can add in their UEFI settings,
and sign the kernels etc. with it.

As far as I know that's not yet the case though, so you'd have to do the
signing yourself. A bit sad for people without TPM, but I guess the
development effort is better spent elsewhere.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7da30d3a-5c30-6881-00aa-36df770591c7%40gaspard.ninja.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

2017-09-19 Thread Leo Gaspard
On 09/19/2017 02:23 PM, taii...@gmx.com wrote:> It is impossible to have
storage communication between VM's, that would
> be a separate security issue.
> On timing attacks or w/e - you may be able to avoid cross communication
> by putting every AppVM on a separate core of a many core CPU such as an
> Opteron 6386 (16 cores)

Putting every AppVM on a separate core of a many core CPU could help a
bit, but CPU's usually have separate L1, maybe L2 caches, but I don't
know of any CPU with a non-shared-between-cores L3 cache. So basing the
attack on timing the L3 cache may still work.

Then, here we're going pretty far in the sophisticated tracking
strategy, like “things currently being proposed at conferences,” so
maybe it's out of the threat model (or maybe not, depends on your threat
model).

As to browser fingerprinting, I'd personally rather use a distinct
distribution for the “anonymous” part, just to make timing updates (A
upgraded this day and B too and all their upgrades are always on the
same day that is not the one of the release of the distribution, thus
A=B) harder. Then, again it's against someone specifically targeting
you, I don't think qubes is widespread enough to make trackers even try
to perform such deductions (yet). That said this last sentence is just
gut feeling.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a4de7982-66ce-f472-dc48-7c0421efe056%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

2017-09-18 Thread Leo Gaspard
On 09/18/2017 09:27 PM, jes...@gmail.com wrote:
> Thank you Micah and Michał, but I am not actually asking about a standard as 
> strong as 100% bulletproof anonymity or anything. I really am just concerned 
> about whether any of the methods on that list that I linked to would be 
> enough to leak cookie-like reference data between two separate Qubes security 
> domains.

Cookie-like reference data between two separate Qubes security domains
cannot happen. This would mean one VM is able to influence the hard disk
of another, which would be a vulnerability in Qubes.

> Being tracked as I browse around *in* a given security domain is entirely my 
> problem of course, and I understand that. My only concern is working to 
> ensure that to an outside observer such as webservers and ad networks nothing 
> short of the shared IP address (and via Tor or VPN or different IPs honestly 
> allocated to different domains perhaps not even that) can act as a reliable 
> indicator that web browsing activity in one Qubes security domain is "linked" 
> to activity from another security domain via any secretly stored cookie-like 
> reference identifiers that get somehow leaked across domains.

What can however happen is things like hardware fingerprinting through
the browser, like CPU frequency measurements.

Also, Qubes doesn't guarantee two VMs can't talk together, so if you
have at the same time a browser in two VMs in two websites they may be
able to talk together using such side channels (timing the cache,
ultra-low-level stuff like that).

So even though supercookies and the like aren't shared in Qubes, if you
use an insufficiently anonymising web browser, a web site may be able to
fingerprint your hardware through the browser (Qubes/Xen does nothing to
prevent that for performance reasons), and then to link your hardware to
different identities you used to browse different pages in different VMs.

I don't know of any website that would try to talk to others through
side-channels, but I seem to remember articles on hardware
fingerprinting (esp. the cpu frequency and drift, iirc) through JS from
a few years back, so I guess against state-of-the-art tracking systems
Qubes will not be enough.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1720ec21-6433-8a0c-02bc-aeb17336fb8c%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Options for securing /boot

2017-09-08 Thread Leo Gaspard
On 09/08/2017 04:51 AM, taii...@gmx.com wrote:
> One can use coreboot with grub's kernel signing features on an owner
> controlled non PSP/ME PC such as the Lenovo G505 (laptop) or KCMA-D8
> (workstation), then after coreboot is working you enable the flash write
> restriction so that it can't be flashed internally (an attacker would
> have to have physical access for around 10mins to reflash) - this is
> technically superior to "secure boot" as it is owner controlled by you
> instead of microsoft.

Just a datapoint: secure boot is *not* microsoft-controlled (unless you
assume the manufacturer put in some kind of backdoor, in which case
you're screwed anyway).

Secure boot *by default* runs with keys owned by microsoft. You can (and
should) replace them with a key you own and you use to sign new GRUBs,
if you want to. The option to do so is usually somewhere in the BIOS menu.

Once you have removed microsoft's golden key and put your own instead,
there is no longer any link between your secure boot and microsoft.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4f6892f2-e515-75f5-e93d-d77d3e5df29a%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Options for securing /boot

2017-08-29 Thread Leo Gaspard
On 08/29/2017 04:01 PM, cooloutac wrote:
> On Monday, August 28, 2017 at 6:36:08 PM UTC-4, Leo Gaspard wrote:
>> Just encrypting /boot would bring little, as it would still be possible
>> to modify the unencrypted part of GRUB (that decrypts /boot) to have it
>> overwrite the /boot with malicious kernel images (or even to not use the
>> ones provided).
>>
>> The options I know of are (from IMO strongest to weakest):
>>  * AEM, for knowing when someone tampered with /boot
>>  * SecureBoot, for restricting the allowed-to-boot images (I don't know
>> about its ease of use with qubes, though)
>>  * locking your bootloader with a password and disallow external boot
>>
>> I'd think having all these protections at the same time would be best,
>> using secureboot mostly to avoid having to ditch the laptop after AEM
>> says it's no longer trustworthy (because it may stop the attacker before
>> it can even make the laptop no longer trustworthy).
> 
> secureboot can do more then restricting boot images,  it can restrict 
> unsigned drivers too.  Thats the part Joanna doesn't like because she does 
> not trust who will maintain the list of signed drivers.  I say I'm already 
> putting just as much trust into alot of other things like my banks ssl cert 
> when connecting to my bank account.
> 
> We are already trusting everything coming from upstream when we update...

Well it can, but the issue with secureboot I remember reading about in
the AEM post [1] is that it assumes no security vulnerability in all the
bootchain (which could be used to trick eg. grub to run another image
than the one you expect it to), while AEM only assumes no security
vulnerability in the TPM.

That's why I was putting secureboot forward only as a limited way to
prevent malicious modifications, in parallel with AEM, that would still
be used as a more secure way of checking secureboot worked correctly.

[1] https://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7f3bc3ea-d715-5630-bdd5-8eb1d1047086%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Options for securing /boot

2017-08-28 Thread Leo Gaspard
Just encrypting /boot would bring little, as it would still be possible
to modify the unencrypted part of GRUB (that decrypts /boot) to have it
overwrite the /boot with malicious kernel images (or even to not use the
ones provided).

The options I know of are (from IMO strongest to weakest):
 * AEM, for knowing when someone tampered with /boot
 * SecureBoot, for restricting the allowed-to-boot images (I don't know
about its ease of use with qubes, though)
 * locking your bootloader with a password and disallow external boot

I'd think having all these protections at the same time would be best,
using secureboot mostly to avoid having to ditch the laptop after AEM
says it's no longer trustworthy (because it may stop the attacker before
it can even make the laptop no longer trustworthy).


On 08/28/2017 09:48 PM, Unman wrote:
> On Sat, Aug 26, 2017 at 08:39:23AM -0700, 
> cyberian@national.shitposting.agency wrote:
>> Does Qubes offer a method of securing /boot? not just against USB evil maid 
>> attacks, but from tampering in general?
>>
>> for example, while a laptop is off, what would stop a malicious user from 
>> live booting to an arbitrary distro and altering kernel or xen images 
>> located on the unencrypted /boot partition?
>>
>> Does qubes offer options for encrypting /boot?
>>
> 
> The Fedora installer wont allow an encrypted boot partition, but there's
> nothing stopping you from encrypting /boot after installation. You will,
> of course, have to reconfigure grub to decrypt the new /boot, but that's
> straightforward.
> 
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3bb3a4b8-f63d-5ccd-bdbb-7905c725901e%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: remote code execution via UDP packets (CVE-2016-10229) in the context of Qubes // and kernel update recommendations

2017-04-14 Thread Leo Gaspard
On 04/14/2017 06:00 AM, Reg Tiangha wrote:
> On 04/13/2017 09:33 PM, cooloutac wrote:
>> On Thursday, April 13, 2017 at 11:26:07 PM UTC-4, cooloutac wrote:
>>> So probably the kernels are not actually vulnerable, They fixed it a year 
>>> ago with patches,  and with Qubes you assume this sort of priv escl thing 
>>> regardless which is why they don't even bother with sudo.
>> Actually when it comes to redhat they claim the code was never there to 
>> exploit.  But redhat might not apply to fedora kernel so I'm kind of curious 
>> myself now.
>>
> For those who are concerned, this is what is currently in the Qubes
> repository for dom0:
> 
> current:  kernel-4.4.38, kernel-qubes-vm-4.4.38
> 
> current-testing: kernel-4.4.55, kernel-qubes-vm-4.4.55
> 
> 
> From what I can tell, the Qubes Kernel is built from the stock kernel
> source, so if this bug was fixed months ago, you could probably install
> either and be fine (assuming you're running R3.2).
> [...]

According to [1], linux <= 4.4.60 is affected. The patch was but on
4.5-rc1 branch on Dec. 15, but this doesn't mean it got backported to
older kernels as it was not tagged as a security issue before (eg.
debian's DSA mentioned "A regression in the UDP implementation prevented
freeradius and some other applications from receiving data." as the
reason for their backporting the patch, if I read correctly)

Which, unless fedora's (or qubes') kernel has been using a patch for
this despite it not being tagged as a security issue until now, would
mean qubes' current kernels are all vulnerable.

HTH,
Leo


[1] https://nvd.nist.gov/vuln/detail/CVE-2016-10229

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/86219df3-c3a2-bcfd-196a-5dec6b714cec%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature