Re: [Tails-dev] Tails cert warning
Hello. Yes, this does appear to be on my side and related to OpenDNS. I believe it's being used as the default DNS server for the local network in the building I'm in. When I explicitly set my DNS servers to be something else, the proper certificate started loading. I asked the network admin what was going on. I don't how the Tails site ended up on a blacklist. On Wed, Nov 13, 2013 at 12:41 AM, intrigeri wrote: > Hi Steve, > > Steve Weis wrote (12 Nov 2013 22:59:37 GMT) : > > Hi tails-dev. As I said, I'm getting certificate warnings for > > tails.boum.organd being served a *. > > opendns.com certificate. Here's what I'm seeing: > > http://pastebin.com/y02MsmNm > > > Now that I think about it, my guess is this may be the local network > > operator in my office building using OpenDNS to block the domain. I'll > ask > > them what is up. Here's the dig output I'm seeing: > > It does look like something happening on your side. > Does it happen if you it over Tor (e.g. using the TBB) too? > > Cheers, > -- > intrigeri > | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc > | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc > ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails cert warning
My mistake, Maxim (bcc:ed). Thanks for forwarding to tails-dev. Hi tails-dev. As I said, I'm getting certificate warnings for tails.boum.organd being served a *. opendns.com certificate. Here's what I'm seeing: http://pastebin.com/y02MsmNm Now that I think about it, my guess is this may be the local network operator in my office building using OpenDNS to block the domain. I'll ask them what is up. Here's the dig output I'm seeing: $ dig tails.boum.org ; <<>> DiG 9.8.1-P1 <<>> tails.boum.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22786 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 0 ;; QUESTION SECTION: ;tails.boum.org. IN A ;; ANSWER SECTION: tails.boum.org. 0 IN A 67.215.65.130 ;; AUTHORITY SECTION: org. 162117 IN NS a2.org.afilias-nst.info. org. 162117 IN NS c0.org.afilias-nst.info. org. 162117 IN NS a0.org.afilias-nst.info. org. 162117 IN NS b2.org.afilias-nst.org. org. 162117 IN NS b0.org.afilias-nst.org. org. 162117 IN NS d0.org.afilias-nst.org. ;; Query time: 5 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Nov 12 14:51:21 2013 ;; MSG SIZE rcvd: 186 On Tue, Nov 12, 2013 at 2:37 PM, Maxim Kammerer wrote: > Hi Steve, I am from a different project — CC'ing Tails ML. :) > > Best regards, > Maxim > > On Wed, Nov 13, 2013 at 12:31 AM, Steve Weis wrote: > > Hey Jake and Maxim. Just FYI I was getting a certificate warning for the > > Tails site (http://tails.boum.org/), but now it's suddenly returning the > > right certificate. > > > > It might be because the office building I'm in is using OpenDNS, since > the > > bad cert CN=*.opendns.com. Here's the bad cert that was returned: > > http://pastebin.com/y02MsmNm > > -- > Maxim Kammerer > Liberté Linux: http://dee.su/liberte > ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Hi Maxim. I did not completely power off the system when I tried the test. I did a warm reset and booted to a USB drive. I'm not sure about the inconsistency with the debugging-via-ohci1394 docs. There are two alternative driver stacks (e.g. ieee1394 and firewire-core) and the docs talk about them both interchangeably. It's a bit confusing. The CONFIG_FIREWIRE_OHCI_REMOTE_DMA kernel hacking option may only be relevant to the legacy ohci1394 module. One thought is that it the sbp2 module might be allowed to circumvent whatever filtering is happening. Sbp2 enables full DMA access, and I haven't been able to carry out Firewire DMA attacks via Inception without it. This message talks about sbp2 having physical DMA, yet being filtered: http://lkml.indiana.edu/hypermail/linux/kernel/0802.1/0347.html . The message he's responding to says the new modules make it "a bit harder to use physical DMA, but not impossible". Regardless, a fix is to blacklist these modules from loading automatically. Then users can still opt in to enable Firewire if they need it, but it's not vulnerable by default. You could add the following lines to /etc/modprobe.d/blacklist.conf: """ blacklist firewire_core blacklist firewire_ohci blacklist firewire_sbp2 """ Or just disable Firewire in the kernel by disabling CONFIG_FIREWIRE. On Sun, Oct 14, 2012 at 5:03 AM, Maxim Kammerer wrote: > On Sat, Oct 13, 2012 at 5:18 AM, Maxim Kammerer wrote: > > On Sat, Oct 13, 2012 at 5:04 AM, Steve Weis wrote: > >> I think the kernel is working as expected. Debian and Ubuntu are both > also > >> vulnerable by default, since FireWire modules are loaded automatically. > > > > From Documentation/debugging-via-ohci1394.txt: > > “The alternative firewire-ohci driver in drivers/firewire uses filtered > physical > > DMA by default, which is more secure but not suitable for remote > debugging.” > > There is some more information in 1394 OHCI Spec v1.1 [1, §5.14.2]. > drivers/firewire/ohci.c doesn't touch OHCI1394_PhyReqFilter* registers > at all if CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set, so physical > request DMA should be forwarded to asynchronous request DMA. Could it > be that the kernel does not implement AR DMA correctly? > > There is also something strange when the spec is compared to the older > v1.0 spec [2, §5.13.2]. The older spec does not have a clarification > wrt. what happens on a bus reset, in Table 5-21 (whether it has such a > clarification in §5.13.1, for instance). It has such a clarification > in the newer v1.1 spec, in Table 5-22. Is it possible that when > implementing OHCI 1.0, vendors did not know what to do, and kept the > physReq* registers values even over a soft reset? This is quite > unlikely, of course, but did you try to power off the computer > completely before performing the test? > > [1] > http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/ohci_11.pdf > [2] ftp://ftp.microsoft.com/bussys/1394/OHCI/Released_Specs/OHC1.0.pdf > > -- > Maxim Kammerer > Liberté Linux: http://dee.su/liberte > ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
I think the kernel is working as expected. Debian and Ubuntu are both also vulnerable by default, since FireWire modules are loaded automatically. I can send some fix suggestions if you like. On Oct 12, 2012 7:35 PM, "Maxim Kammerer" wrote: > On Sat, Oct 13, 2012 at 3:15 AM, Steve Weis wrote: > > Hi. I booted Tails' latest release and was able to scrape memory contents > > via FireWire. All the necessary firewire modules are enabled by default > and > > Inception worked out of the box. This would let someone root a machine > > through, say, a daisy chained thunderbolt monitor. > > Thanks for testing! Shouldn't such behavior be classified as a kernel > bug? I can't find anything related on the kernel bugtracker. > > -- > Maxim Kammerer > Liberté Linux: http://dee.su/liberte > ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Hi. I booted Tails' latest release and was able to scrape memory contents via FireWire. All the necessary firewire modules are enabled by default and Inception worked out of the box. This would let someone root a machine through, say, a daisy chained thunderbolt monitor. I'd either remove support from the kernel, blacklist the modules in modprobe, or disable support with a boot param. Iommu should be enabled as well for good measure, although it can be circumvented. Cheers. On Oct 12, 2012 5:48 PM, "Jacob Appelbaum" wrote: > Maxim Kammerer: > > On Sat, Oct 13, 2012 at 1:30 AM, Jacob Appelbaum > > wrote: > >> I would add Thunderbolt to the list as well: > >> > http://www.breaknenter.org/2012/02/adventures-with-daisy-in-thunderbolt-dma-land-hacking-macs-through-the-thunderbolt-interface/ > > > >> > > As far as I can see, all these attacks (PCMCIA, ExpressCard, > > Thunderbolt) rely on attaching to a FireWire interface one way or > > another, and then accessing arbitrary memory via DMA. But such > > ability is (or can be) disabled by default in the newer firewire-ohci > > module, as described in "debugging-via-ohci1394.txt", and even > > discussed on the relevant Tails TODO page. So why disable the > > interfaces? Looks like an overkill to me. > > > > My understanding is that this assumption doesn't actually pan out in > practice. I've cc'ed Steve who may have some more information to > contribute. As I understand things, he found that as predicted, the > default "it is off" doesn't actually always turn DMA off. > > All the best, > Jacob > ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
