heads up, qubes 3.2 still vuln to cve-2016-4484 (minor severity)
pixel fairy
wanted to give users without AEM or sed a heads up to fix their grub file or add a boot password if this concerns them.
pixel fairy
> reported here, https://github.com/QubesOS/qubes-issues/issues/2907
>
> wanted to give users without AEM or sed a heads up to fix their grub file or add a boot password if this concerns them.
to fix it with grub, (adapted from https://www.qubes-os.org/doc/usb/)
1. Open the file /etc/default/grub in dom0.
2. Find the line that begins with GRUB_CMDLINE_LINUX.
3. Add rd.shell=0 to that line.
4. Save and close the file.
5. Run the command grub2-mkconfig -o /boot/grub2/grub.cfg in dom0.
6. Reboot.
qubester
at risk?
pixel fairy
> So, to exploit this, someone would need physical access to the computer
> at risk?
physical or any network available OOB. heres an example of what can go wrong https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5689
on a simpler level, you dont want someone compromising that plain text part of your drive, maybe your workstation at the office. this way, they really would need physical access to remove your drive and compromise that boot sector.
or, if you have a laptop, you can use other means, like glittery nail polish to see if anyone physically entered your laptop. of course, there may be other vulns, so its still good to have anti aem, or sed.
yreb-qusw
> any network available OOB
sorry what would be an example of this ? "out of band" ?
I'm not clear what SED is , :)
I don't really see any docs on ?initializing AEM , I do see that it
says to :
---
In Dom0 install anti-evil-maid:
sudo qubes-dom0-update anti-evil-maid
---
I personally have no USB-VM , would my Bios need to be configured
some particular way, beyond what it already is with 3.2 booting and stable
I have about zero concern on malware from USB drives, maybe I
shouldn't , but seems far -fetched in my case. So, maybe I don't need
AEM depending on what "network OOB" would mean .....
regards
pixel fairy
> On 07/14/2017 05:40 PM, pixel fairy wrote:
> > any network available OOB
>
> sorry what would be an example of this ? "out of band" ?
yes. ipmi, idrac etc. these usually have a vnc interface to the "console" you'd normally have from the attached keyboard, mouse, and monitor. so this exploit would work on those. usually these interfaces exist on bussiness class hardware, like vpro on some laptops. you may be able to disable it in bios.
this is not the intel M.E. (management engine), though its functionally related.
>
> I'm not clear what SED is , :)
self encrypting drive
https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption
> I don't really see any docs on ?initializing AEM , I do see that it
> says to :
>
> ---
> In Dom0 install anti-evil-maid:
>
> sudo qubes-dom0-update anti-evil-maid
> ---
>
> I personally have no USB-VM , would my Bios need to be configured
> some particular way, beyond what it already is with 3.2 booting and stable
yes, you would need the iommu enabled. for intel, this is called vt-d
> I have about zero concern on malware from USB drives, maybe I
> shouldn't , but seems far -fetched in my case. So, maybe I don't need
sometimes its the firmware, sometimes its the devices themselves. for example, you wouldn't want a web cam, gps, or microscope available to just any appvm.
for block devices qubes already filters usb to use those those safely, but i suspect sys-usb is safer than dom0 doing it. dont know exactly how that works.
then theres the malicious hub devices like rubber ducky, bash bunny etc. dont know the likelyhood of you running into that.
> AEM depending on what "network OOB" would mean .....
sys-usb is easy enough that anyone with an iommu should use it, unless you only have like 4 gigs of ram.
AEM is more work, and has its trade offs.
> regards
yreb-qusw
> ---
> In Dom0 install anti-evil-maid:
>
> sudo qubes-dom0-update anti-evil-maid
> ---
more to it, I thought, it mentioned it's better to install via a USB Drive?
What would be the "trade off" and/or How would I disable it , if it
somehow messes up my Qubes install?
pixel fairy
> On 07/16/2017 01:27 AM, pixel fairy wrote:
> > ---
> > In Dom0 install anti-evil-maid:
> >
> > sudo qubes-dom0-update anti-evil-maid
> > ---
> Doesn't sound like 'more work' just doing the above, perhaps there is
> more to it, I thought, it mentioned it's better to install via a USB Drive?
https://github.com/QubesOS/qubes-antievilmaid/blob/master/anti-evil-maid/README
as you can see, its a lot of steps, and only some laptops are compatible. there are even new laptops, like the system76 lemur7 (i7 skylake), that cant do AEM.
ideally you can boot from a non usb external device, such as an sd card in your purse or wallet. if you do use usb, then you have to disable hiding the usb controller for a bit, which gives your attacker a window of opportunity for the kinds of things AEM is meant to detect.
this is a small windows of opportunity, but there is the theoretical case that a clueless attacker with only a short time boots from their own device, the attack fails because usb is locked (and they may not even know this) and your laptop is ok. whereas if AEM needed that usb controller enabled to function, the attack would succeed, or at least succeed enough to trip AEM.
> What would be the "trade off" and/or How would I disable it , if it
> somehow messes up my Qubes install?
the most obvious trade off is needing your boot device to boot your laptop. so, you must protect this device. you'll probably want more than one of them in case one is lost or damaged, so you have to protect multiple devices. this is fine for cyborgs with implanted, bootable usb devices. but, for the rest of us, its something you must consider carefully in your threat model.
a more thorough discussion of all this in the background blog post, https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html
if it doesnt work, you wont be able to boot. youd have to reinstall qubes and start over. if you want to disable it, you might be able to make a new passphrase for luks that doesnt need the keyfile on your aem device. there may be other steps required, but i havent tried it.
cooloutac
like pixel said you either can use a usb stick like a yubikey to boot, or use a usbvm don't think you can do both. so in most cases a home desktop pc probably would just use usbvm. but if you someone that travels with a laptop, that might be accessible to others, you might want to boot with usb key.
aem can be used on both but without usb key if using usbvm, but should note aem only notifies you that something happened, like pixel said it doesn't stop the attack, like secure boot would in case of hacking teams insyde bios attack. Also the only true option then would be to buy all new hardware if such a compromise did happen. But some people upgrade their hardware every two years anyways. If you careful you can last that long.
yreb-qusw
after I posted that, all the steps, I'd probably end up breaking the
machine or locking myself out of it .....
pixel fairy
> So, If I haven't already, I should have secure boot enabled? ; I saw
> after I posted that, all the steps, I'd probably end up breaking the
> machine or locking myself out of it .....
you should definitely put a password on your bios and make a usb qube.
i would only do AEM if your comfortable with installation, backup and recovery, or dont have anything important on that machine yet. preferably set aside a couple days to work out any kinks.
yreb-qusw
really can't imagine any physical security issues, unless , a USB
device remotely got infected somehow , though , I almost never use any
USB drives.
I have so many pw's between all my encrypted drives (on which I re-use
the same pw :) ), that I hesitate to add potential disaster level
pw's unless it really adds something .....
SO, for the purposes to this AMT or remote attacks on a Qubes system
, would enabling 'secure boot' without a admin pw make sense, and
you recommmeding a admin AND user pw with the 'secure boot' , I
thought there was some issue with Qubes booting with 'secure boot'
enabled ??
sorry, if this is too simple, or the paragraph rambles......
cooloutac
secure boot isn't supported on qubes unfortunately. Hacking teams insyde bios exploit could be used remotely according to experts, so secure boot would actually defend against something like that remotely as well. I hope people get over the anti microsoft and redhat notions about it. Richard Stallman gives it the ok in its current state, so why spite.
And ya AEM seems complicated to setup so unless you travel alot and are worried about evil maids or someone breaking into your computer, a usbvm is probably more practical.
yreb-qusw
>
>
> secure boot isn't supported on qubes unfortunately. Hacking teams insyde bios exploit could be used remotely according to experts, so secure boot would actually defend against something like that remotely as well. I hope people get over the anti microsoft and redhat notions about it. Richard Stallman gives it the ok in its current state, so why spite.
>
> And ya AEM seems complicated to setup so unless you travel alot and are worried about evil maids or someone breaking into your computer, a usbvm is probably more practical.
>
your Qubes machine?
no evil maids here, but I guess there is/was talk of remote exploits
and or USB drives of possible uncertain cleanliness, that might
also be protected by AEM ?
in my case, last time the USBVM thing , or my attempted implementation,
rather, nearly cause a meltdown, but since I've the PS2 adapter,
personaly, I'm also avoiding the USBVM ..... I suppose overall, I'm
still safer than running Windows 10 :) aren't I ...
or other Ubuntu distros....
cooloutac
aem doesn't protect anything, its just an alert if something was compromised. Secure boot on the other hand will actually prevent an exploit. From reading other users experience aem also seems buggy so I don't know how reliable it is. People on here have gotten false positives.
yreb-qusw
Q4.0 or will it be 3.2 be 'upgradeable' ?
Guesstimate when does it turn into "stable" ?
3) re: security advisorys, is there ever any suggestion what to do about
them?
.....or just keep upgrading dom0 and magically some of them get fixed ?
seem like obvious questions to me , sorry if they are basic
yreb-qusw
yreb-qusw
Ted Brenner
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ddaade3b-1f22-3030-2dc9-e07e76a41269%40riseup.net.
yreb-qusw
> On Thu, Aug 17, 2017 at 1:23 AM, yreb-qusw <yre...@riseup.net> wrote:
>
>> On 08/15/2017 05:13 PM, yreb-qusw wrote:
>>
>>> Q4.0 upgrade path ? am I eventually going to have to reinstall as Q4.0
>>> or will it be 3.2 be 'upgradeable' ?
>>>
>>
>>
> <https://www.qubes-os.org/doc/version-scheme/#release-schedule>has a
> maximum of 3 candidates. So that would be 15 weeks before stable? RC1 was
> July 31st. So stable could be November 13th at the latest? This is my best
> guess.
>
withOUT reinstalling , would you happen to know?