subject:"\[qubes\-users\] Why are Ethernet and WiFi in sys\-net..\?"

> Wow. Not even 4 GB of compiled drivers for the WiFi. You are saying it's 4
> GB of raw plaintext source code..?
>
> WOW
>
> That's INSANELY complex.

Apologies, I spoke a bit hastily.  What was seeing was 4 million Git
objects, not 4G of data (although it may be).  And that included all
branches and all the history of the repo, so it's not a fair measure.

(In my defense, back in my day we used "rcs" and we got along just fine. 
Then we switched to "sccs."  Then "cvs." Then "svn."  Then "git."  One
needs a version control system just to keep track of the version control
system that is currently in vogue.)

I just checked out the master branch and it clocked in at 917 meg.  Still
not exactly lightweight.  No single directly was above a Megabyte.  There
is just lots and lots and lots of directories.  :)

Plus, the source tree contains filesystem implementations, tools, etc., etc..

Within the master branch, drivers/net/wireless clocks in at 34 meg
(getting a bit more reasonable, lol).

Some stats: the total line count of all the .c and .h files under
drivers/net/wireless is just over a million lines of code.  There were
1310 .c/.h files, which averages out to 770 LOC per .c/.h file.

They represent device support for 15 different vendors (and no doubt
supporting more brands of similar devices, with OEM rebranding and such).

Somewhere in the neighbor of under 250 different device variations
supported (although that is a rather clumsy measure based upon defines in
Makefiles; I'm getting tired, lol).

An example of the biggest files and their lines-of-code:

  28721 ./broadcom/brcm80211/brcmsmac/phy/phy_n.c
  12061 ./intel/ipw2x00/ipw2200.c
  10630 ./broadcom/brcm80211/brcmsmac/phy/phytbl_n.c
  10318 ./broadcom/b43/radio_2056.c
   8646 ./intel/ipw2x00/ipw2100.c
   8231 ./ath/ath10k/wmi.c
   8224 ./cisco/airo.c
   8139 ./broadcom/brcm80211/brcmsmac/main.c
   8066 ./ath/ath10k/mac.c
   8027 ./ralink/rt2x00/rt2800lib.c
   7018 ./broadcom/brcm80211/brcmfmac/cfg80211.c
   6873 ./intel/iwlegacy/4965-mac.c
   6726 ./broadcom/b43/phy_n.c
   6652 ./ath/ath10k/wmi.h
   6575 ./ti/wlcore/main.c
   6348 ./marvell/mwl8k.c
   6334 ./realtek/rtl8xxxu/rtl8xxxu_core.c
   5872 ./broadcom/b43/main.c
   5594 ./intel/iwlegacy/common.c
   5511 ./ath/ath9k/ar9003_eeprom.c
   5247 ./broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
   4843 ./realtek/rtlwifi/rtl8821ae/phy.c
   4706 ./ath/wcn36xx/hal.h
   4572 ./realtek/rtlwifi/rtl8821ae/table.c
   4549 ./atmel/atmel.c
   4337 ./marvell/mwifiex/cfg80211.c
   4305 ./broadcom/brcm80211/brcmfmac/sdio.c
   4230 ./intel/iwlwifi/mvm/mac80211.c
   4170 ./ath/ath6kl/wmi.c
   4143 ./realtek/rtlwifi/rtl8821ae/hw.c
   4097 ./intel/iwlwifi/mvm/rs.c
   4062 ./broadcom/b43legacy/main.c
   4046 ./intersil/hostap/hostap_ioctl.c
   4036 ./ath/ath6kl/cfg80211.c
   4008 ./intel/iwlwifi/dvm/commands.h
   3965 ./ath/ath5k/phy.c
   3959 ./intel/iwlegacy/3945-mac.c
   3878 ./broadcom/b43/tables_nphy.c
   3861 ./realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
   3819 ./realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
   3774 ./rndis_wlan.c
   3626 ./realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
   3594 ./realtek/rtlwifi/rtl8192de/phy.c
   3576 ./ath/ath10k/wmi-tlv.c
   3370 ./intel/iwlegacy/commands.h
   3180 ./ath/ath9k/ar9002_initvals.h
   2456 ./broadcom/b43/tables_lpphy.c

Some of the bigger files seem to be tables used for radio communication,
possibly DSP-like tables to drive things (and nary a comment to be seen),
and (thankfully) not so much binary chunks of proprietary code.

Others are large in order to interface with (and/or implement?) complex
modem command sets.  And probably many other reasons.  But that's a quick
sampling of the fun.

Similar to my hasty comments on the code size, my complaining about how
the code was structured turns out not to be specific to the wireless, but
is a common approach for kernel configuration and drivers in general.

But it's safe to say the complexity is an order of magnitude greater than
for ethernet.

> A bit like how people have said phone basebands are incredibly complex,
> not to mention, closed source.

I've come to think of basebands (in phones, for example) as like ISP's, a
bit beyond your control, and as things that should be compartmentalized
hardware-wise and treated as potentially hostile.  Sadly, I think many
phones today aren't implemented in that spirit.

One horrific example of getting things completely backwards (allowing the
baseband to freely probe around and modify the phone's memory, ostensibly
in the name of support, I suppose :S) is the "Samsung backdoor":

http://redmine.replicant.us/projects/replicant/wiki/SamsungGalaxyBackdoor

Replicant, a stripped-down non-proprietary fork of Android, tries to
isolate and not play well with that baseband feature, effectively treating
it as potentially hostile.  Sad that it's necessary.

"Our free software replacement for the incriminated binary is Samsung-RIL
which relies on libsamsung-ipc: both are used in Replicant.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

> Please read if you haven't already:
>
> http://invisiblethingslab.com/resources/2014/Software_compartmentalization_vs_physical_separation.pdf
>
> 2 big takeaways:
>
> 2. The Physical Gateway needs to be secure not only from attacks from the
> Internet but also attacks from the client appVM.

Haven't read the paper yet (will definitely do it), but that's a very
intriguing point.

> 1. A typical networking stack presents a huge attack surface.

In response to the original poster (and for my own curiosity), I was going
to take a look at the Wireless drivers for the athlon 5k cards (no CPU on
board).

Google landed me at the Linux wireless driver site, so I went to grab a
Git clone of the latest wireless driver source.  Four gigabytes! 
Yeeeouch.  So I ^C'd that, and will just go digging through the drivers in
the kernel source tree instead when I get a chance.

(Maybe a lot of that is firmware blobs or something, I don't know; I'll
take a look in more detail when I get a chance.  But regardless, the
attack surface must be big.)

The WiFi stuff is hard to navigate, a lot of shared common code, endless
configuration files with definitions that enable/disable certain chunks of
code for different chipsets and cards and features, and so forth.

I had trouble even finding the relevant any relevant .c file, so much of
it was configuration macros.  Most of the code seemed to live in many,
many different .h files instead.

My head hurt, so I went to bed, lol.

Needless to say, none of that increased my confidence in WiFi.  Ethernet
is far simpler, and thus, IMO, safer.

(When I do take a look at the code, probably tonight, I'll post a
comparison on lines-of-code between a typical WiFi driver and Ethernet
driver.  I wouldn't be surprised to see a 10:1 ratio, if it's even
possible to find enough separated code to do a comparison.)

As a quick binary module comparison, and not necessarily a fair one (as
the WiFi stuff no doubt drags in other modules):

Ethernet driver for a 3com card:

/net/ethernet/3com$ size 3c59x.ko
   textdata bss dec hex filename
  415112968  49   44528adf0 3c59x.ko

Ethernet driver for an ath5k card:

/net/wireless/ath/ath5k$ size ath5k.ko
  text data bss dec hex filename
 1535451529   8  155082   25dca ath5k.ko

ath5k.ko has a number of undefined symbols relating to ieee80211 (WPA2),
so just *one* of the modules it would depend upon is this:

/net/mac80211# size mac80211.ko
   textdata bss dec hex filename
 529986   53348  64  583398   8e6e6 mac80211.ko

Oh, and also this, just for WPA:

/net/wireless# size *.ko
   textdata bss dec hex filename
 380654   713953656  455705   6f419 cfg80211.ko
   36881088   0477612a8 lib80211_crypt_ccmp.ko
   66961168   078641eb8 lib80211_crypt_tkip.ko
   2166 968   03134 c3e lib80211_crypt_wep.ko
   2132 992   43128 c38 lib80211.ko

(Other than net/netfilter, net/wireless is the largest sub directory in
the net driver module hierarchhy.)

The Wireless drives no doubt bring in many other modules for the other
encyrptions and features.  (The Ethernet stuff likely brings in other
stuff as well, but probably the same core ethernet dependencies are also
required by the wireless stuff)

>From that very quick comparison, it's a minimum of 26x (!) more code just
for the ath5k+WPA2 support, versus the driver for a 3com ethernet card.

Cheers,

JJ

-- 
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/6008c7066cc61d8632f3473c35f3e146.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

2016-09-26 Thread neilhardley

Very useful info, but what I meant is whether the Ethernet drivers/firmware etc 
are more secure than the WiFi ones.

I wasn't really talking things like RF leakage etc.

-- 
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/ecbd7136-a6f1-4bcf-b7c5-8a830ee3c7fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

> And yes, by all means, I will use Whonix's system rather than my own
> custom script.

I agree that Whonix is a key component. A NetVM that ensures *all* your
traffic goes through Tor, with no leakage, as well as doing secure DNS
lookups for you, is a big security plus.

They've also put a fair bit of work into the iptables (i.e. firewall)
configuration of the sys-whonix Network VM. Something I had expected of
Qubes, and a bit more on par with what Tails does.

And Whonix is more of an open sourced "configuration" rather than a code
base. It just ties other established pieces together solidly, and
configures them well. And you're free to check it out and put together
yourself, no coding required.

In System, Global Settings, it's good to make sys-whonix your Update VM as
well, reducing MITM risk during the update process. As well as making it
your Clock VM, to avoid clock synchronization leaks.

(apt-get-transport tor is slightly preferable, since it goes directly to
Debian's hidden service, encrypted of course, for updates. But hopefully
package signing would reduce any risk for dodgy exit nodes and the like
when using sys-whonix for updates.)

It's worth noting that using whonix does increase the number of trusted
parties from two (Fedora + Qubes devs) to four (Fedora + Qubes + Debian +
Whonix devs). More repositories/updates for potential threats or bugs.
But where all are open source, that's probably not a big additional
security risk. The benefit far outweighs the risks, IMO.

Cheers,

--
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/9b6ce2e7b0a256e05bad31d067da1cbf.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

> Well, entr0py, you are correct.
>
> It does indeed come down, to either Xen, or my networking stack.
>
> Let me ask... what is the security like for Ethernet..?

Anything going over a wire is going to have a far shorter RF leakage range
than WiFi.  Unless your threat actor is in the house or next door,
ethernet is hard to beat for security (and simplicity).

WiFi protocols are (obviously) over the air, which is inherently more
vulnerable. Plus they're more complex, and complexity is no friend of
security.

WiFi (protocols and hardware itself) is a pretty juicy target for NSA and
state actors, so you know a lot of effort is being put into that. 
Ethernet is pretty well-established and boring as compared to WiFi.

https://en.wikipedia.org/wiki/Wireless_security

That being said, there is an argument that since WiFi is encrypted by
default (usually), and Ethernet isn't, WiFi may be considered more secure
in that aspect.  But you can certainly (as discussed before) make sure
everything going over the ethernet cable is encrypted.

But WiFi has had a pretty bad track record of security (WEP, WPA, WPS all
considered crackable), so I'd stick with wired.  If you're paranoid, make
sure your cable runs are short and RF-shielded.

WPA2 (a.k.a 802.11i) is considered secure for the long run; but given the
complexity, and the aggressiveness of state actors and crooks to put
backdoors and bugs into the protocols and hardware, I'd stick with
ethernet.

Broadcasting and security don't mix, even with encryption.

If someone sneaks onto your ethernet, they'll have to it by tapping into
an existing wire, picking up RF leakage, or plugging into your cable
modem.  Pretty noticeable and containable.

If someone sneaks onto your WiFi network somehow, you likely won't notice.

A few points about WiFi routers:

- Often the admin pages are just http, not https.  So anyone on your
network (legitimately, or not) can snag the cable modem credentials and
later reconfigure you modem to redirect traffic to themselves, or
whatever.

- Make sure your admin password is long, random, and unique.  Only
administer it or change the password when WiFi is off and you're the only
one connected on ethernet.

- Turn off SSID broadcast.  Users can type in the network name (something
non-guessable, not just "linksys" or "dlink",lol).

- While Mac address spoofing is easy, it still can't hurt to turn on Mac
authentication, so only listed Mac addresses are permitted on the network.
 If they can't otherwise snoop on the network, they won't know *which* Mac
addresses to spoof, so it could help a bit.

- I also turn off DHCP serving (for both WiFi and ethernet).  It's not
that inconvenient to manually type in the address, gateway, DNS.  I use an
unusual IP address range as well.  None of those necessarily add
significantly to security, but they sure don't hurt, especially for the
less sophisticated threat.

And don't use your ISP's DNS.  It's trivial for a small-time
privately-owned provider (or the NSA tapping into the same) to hijack DNS
and send you to a spoofed site.

Google's 8.8.8.8/8.8.4.4 is quite popular, if you trust google inherently.
 (I don't.)  Open DNS's 8.26.56.26 is also popular, but it does redirect
to ads for unrecognized sites, which isn't particularly cool.

I prefer using my commercial VPN provider's DNS server.  If I can't trust
the VPN provider, my security is toast anyway, so I might as well trust
their DNS too.  :)  To me, a good commercial VPN provider is one of the
few "stakes in the ground" you have to place and trust.

(Also, I connect to my VPN provider by IP address, which I verify several
different ways, rather than by DNS lookup.)

Also, if you run whonix or Tor, it can do the DNS resolution for you over
Tor, which is great for security and preventing DNS leakage.

If you do serve up DHCP from your cable modem, put in your preferred DNS
server there, so any clients automatically use it.

But in general, don't use WiFi if you're concerned at all about security.  :)

> Let's say I connected to my home router via Ethernet, and also served out
> the Tor connection to a 2nd laptop, over Ethernet.
>
> In this setup, there is no WiFi at all.
>
> Would that make things more secure..?

I would say yes, unless there's someone nearby who can pick up leaking RF
from your ethernet connection, a fairly rare and manageable threat.

I turn on WiFi when friends, family, my kids, are over, or for casual
browsing (with a VPN layer on top).  But never for anything work related
or personal.  Otherwise it's off.  (Some modems have a button to do that;
but make sure it's not a WPS configuration button, because that's
insecure.)

Interestingly, I noticed my FM radio, tuned to around 100 Mhz (go figure)
picks up Ethernet noise.  It's a good ghetto way to see how leaky your
cables might be.  For my wiring, moving a foot or so away from the cable,
and you don't hear anything.

(I have one VOIP phone which just screams RF noise in the 100 mhz range.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

2016-09-26 Thread neilhardley

And yes, by all means, I will use Whonix's system rather than my own custom 
script.

I originally created my own, because I saw that Whonix didn't have VT-D.

But then I learned that VT-D is nowhere near as good as I thought.

I originally thought VT-D isolates the devices from the Net VM itself. But in 
fact, VT-D only keeps the devices inside of Net VM... and the security of Net 
VM itself is still dependent on Xen.

So... yes I will definitely look into using Whonix for this rather than my 
own script.

But just to re-iterate my previous question.. do you think Ethernet is any more 
secure than WiFi.

In your answer, you explicitly say to get rid of WiFi, due to security 
problems... But how about Ethernet..?

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/9774f4fb-2cfd-4848-887e-1a8dcce18c62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

2016-09-26 Thread neilhardley

Well, entr0py, you are correct.

It does indeed come down, to either Xen, or my networking stack.

Let me ask... what is the security like for Ethernet..?

Let's say I connected to my home router via Ethernet, and also served out the 
Tor connection to a 2nd laptop, over Ethernet.

In this setup, there is no WiFi at all.

Would that make things more secure..?

-- 
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/7fc44baf-ea60-485d-93c9-faa06fb04bde%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

> OK, so the main takeaway from your answer:
>
> "The card doesn't have a host CPU and so it doesn't require a firmware
> source"
>
> that seems like the most interesting
>
> the driver would still need to be bug-free though
>
> who knows whether any of these have even been audited

I think the wireless drivers are fairly well reviewed, and from a quick
glace, there seems to be a lot of code sharing/reuse between drivers.  I
plan to look a bit closer at the ath5k driver when I get a chance to see
the nature of that hardware.

A couple of other points:

- This may go without saying, but any USB-based networking device, and all
security bets are off (right Andrew? :) ).  While PCI is an electrical
specification and hardware protocol, USB is a far more (overly) complex
protocol that out of necessity requires a USB controller, which is, of
course, a CPU in its own right.  Which, if compromised, could suddenly
pretend to be a keyboard and send you to a malware site to load up, when
you're not looking.  :)

- More importantly, by separating out your laptop from Qubes, I think you
might be *increasing* your risk, not decreasing it:

I believe one of the common threat models is, for example, a state actor
backdoor placed in your NIC that is activated by a special sequence of
data that could be present in a web page you're coaxed to (or faked with a
MITM tampering), or in an email sent to you, or whatever.

When your NIC sees the magic string "GiveMeYourStuff", it starts DMA'ing
around and sending off the contents of memory, including any keys, disk
cache, data, whatever.  Not good.

The NIC in sys-net sees that magic string, and it sends away sys-net's
memory.  No big deal.  That's boring, stock stuff that's mostly the same
on any Qubes setup.  There's nothing of use there.

Of course, it could tamper with the net connection content as well, but
with Tor (in another VM), that won't buy the attacker anything but seeing
encrypted traffic.  The VM isolation has done its job.

And, in fact, since sys-net is *only* seeing encrypted Tor traffic, it
shouldn't be possible for it ever see that "GiveMeYourStuff" magic string
that was on a web site or email, but its triply-encrypted Tor version.

(Now, if someone unilaterally blasts a packet with that magic string right
to your IP address, your sys-net compromised-NIC is going to see it and do
its thing, regardless of other tor traffic going on.  This occurs at the
hardware level, before iptables gets to do its thing, too, so no help
there.  Thus, you really do need that sys-net isolation.)

Now, the more interesting part: your laptop.  It's connected to the Qubes
box via ethernet and internet sharing, also has a NSA/orgcrime backdoor'd
NIC installed at the cooperative manufacturer's factory, or through mail
interdiction.

You go to read your Google Groups but the page is intercepted/redirected
to the attacker's page.  Or you're sent an email with the magic string in
it.  Or you read my sneakily malicious post that includes the magic words
"GiveMeYourStuff."

While that string arrives in sys-net and sys-tor on Qubes encrypted, once
it passes through tor and is decrypted, it is passed cleartext over the
crossover ethernet cable to your laptop's NIC.  It sees "GiveMeYourStuff"
at the hardware level, in the clear, and takes its cue to DMA through your
Laptop's memory, phoning home (conveniently over your Tor connection,
which doesn't hurt the attacker, since it comes out of the Tor exit node
to be sent to the attacker's site decrypted).

By separating out your Laptop from Qubes, you're failing to protect your
laptop's NIC (and thus your whole non-VM'd laptop).

The *content* you send and receive from your laptop will be encrypted in
transit, which is good.  But any attacks on your laptop NIC from dodgy
sites or phishing or magic email are still as much present as if your
laptop were directly on the Internet.  In effect, it *is* directly on the
Internet, just with a path between
sys-tor->guard->relay->relay->exit-node->Internet Site encrypted during
transport.

It provides you privacy, and protection against MITM in the Tor Network,
but it doesn't provide protection from the Internet at large.

All NIC's, including the Laptop, need to be isolated in a sys-net VM of
some sort.

Now, unless your laptop has one of those CPU-less NIC's (unlikely) or you
manage to find a NIC for your laptop that isn't USB (challenging) and that
doesn't have a CPU or other processor on it (such as those listed on that
Wiki page), you probably avoid that threat.  That's a lot of "if's."

Running Tor or TorBrowserBundle on the laptop itself could mitigate that
risk, since the laptop's NIC would only be seeing encrypted traffic, and
not open to that threat model.

Your setup seems to be premised upon the tethered connection providing the
Tor functionality.  Unless you somehow isolate your laptop NIC or get one
with no CPU/processor, you're better off keeping Tor/Tbb on the laptop,
not the Qubes gateway

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

I guess the only other thing I would add is.

With Firefox, you have a page "Security Advisories", which lists the history of 
Firefox exploits.

I wonder if such a thing exists for WiFi drivers + firmware.

Or even a list of any major audits of WiFi drivers + firmware.

If there is some really easy way to see which WiFi devices are the most secure.

Something like "security advisories", but for WiFi devices.

But I guess if no eyeballs are even looking at the code, then no one will find 
any bugs.

Ultimately, what's needed is a Truecrypt-style major audit.

If we could crowd-fund an audit of a major WiFi chip(s), that may be the key.

-- 
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/6848617d-b373-48f5-b103-eb3b634dde65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

OK, so the main takeaway from your answer:

"The card doesn't have a host CPU and so it doesn't require a firmware source"

that seems like the most interesting

the driver would still need to be bug-free though

who knows whether any of these have even been audited

thanks for your replies though... very detailed and very useful

-- 
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/91ed9119-b5dd-49bd-9152-f141d126c3ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

> Yeah... and surely this is exactly what can happen, no..?
>
> We had 2 Xen exploits in the last 1 year.

I expect those exploits have caused a lot more scrutiny of the code, so
hopefully such exploits won't be heard of again.  Qubes devs are moving
away from PVM which should avoid the threat of such exploits as well, from
my understanding.

> Surely a compromised sys-net can just run a Xen exploit, and can then
> breach into any other VM, including dom0.
>
> This is the whole reason why I decided to use 2 laptops.. because Xen is
> not secure.

Well, if you're going with that assumption, then you best get Tor off
Xen/Qubes all together, so your Qubes box is only seeing encrypted
traffic.  But then, do you trust your laptop more so?  And if so, why are
you using Qubes at all?

You're going to end up with a string of four or five PC's before you're
done, and probably no more secure.  I jest, but only somewhat.  :)

You have to start trust somewhere, and I think Qubes/Xen is one of the
most promising and secure systems available (even Snowden seems to agree).

Xen has had two significant bugs.  How many times have devices/systems
been compromised by the NSA or other state actors and crooks?  I'm
guessing the number has several more digits than the number "2."

> So, I think the solution is to simply use a WiFi and Ethernet that do NOT
> have any bugs in the first place.

And I'd like a government, police force, courts, business, and social
world with zero corruption and zero crooks.  The government can backdoor
everything it wants in such a perfect world.  I think such expectations
are about as realistic as finding a completely safe NIC.

It's not just bugs you need to worry about, but gear that is intentionally
compromised by NSA or organized crime at the factory, or in transit, both
of which are realities.

And if the NSA puts a backdoor in place, with the best of intentions, that
doesn't mean that crooks (or spurned LOVINT users), inside or outside of
the NSA, can't abuse it.  Frankly, I'm coming to the opinion that NSA and
other state actors have broken the tech world so badly that I no longer
want to be part of it.  I just can't promise security to potential clients
any more, nor can I guarantee my own security 100%.

I might switch to an industry where you don't need to leverage trade
secrets and proprietary code.  It's hard/impossible to build any tech
business while completely hacked.  If I were a welder, for example, I
could care less about surveillance/hacking.

I've recently switched from web programming to more simple hardware-based
development projects to keep my sanity going forward.  And some of the
gadgets are designed to address such security issues, like an open-source
strongly encrypted keyboard with corresponding Linux driver.  But I might
just end up switching industries all together.

People who fight the hacking too much, sometimes meet with untimely and
unfortunate ends.  :S

A tradesman can't work and do his job well if someone has busted all his
tools.  And that's where we are/will-be with computers and
networking/Internet today.

/endrant

> As far as I can tell, networking firmware in Linux is actually implemented
> in Linux, and not installed on the actual device itself.

I wouldn't say that's true.  There's device drivers that live on Linux,
and there's Firmware that lives on the card (and can be uploaded from
Linux, with some cards).

Even with a card that can receive firmware, what exactly is on the card
receiving the firmware update?  A CPU running some bootloader, potentially
compromised by the NSA or orgcrime.  So there's no guarantees there.  And
who's to say there isn't some secondary circuitry splitting off the signal
and sending it to an attacker's server, outside the domain of the
firmware.

> Therefore, so long as the driver was open source, then surely it can be
> audited for any DMA bugs.

If the driver *and* firmware were open source, which is even more rare. 
And again, unless the firmware is flashed with a JTAG or some other
direct-write method, there has to be some cpu+bootloader to receive the
firmware from the Linux driver, which is free to muck with the firmware
(or quietly ignore it) if the bootloader were compromised.

The newer the hardware (esp. with U.S. based companies), the more likely I
would say that state-sponsored compromise would be present.  The oldest,
dumbest cards might be the safest.  But a more interesting point below:

> Here is a comparison of open source wireless drivers
>
> https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers

That's a great resource.

The one thing that caught my eye were the devices with the [3] footnotes:

"The card doesn't have a host CPU and so it doesn't require a firmware
source"

That's what I'm talkin' 'bout.  :)  To me, that seems like the most
promising route.

Not to say that such cards don't have *some* CPU or other backdoor.  But
it might be possible to verify if this is/isn't the

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

> If your Tor is running in another appVM, such as whonix-gw does, the worst
> a sys-net compromise could do is redirect the *encrypted* Tor traffic from
> whonix-gw, which isn't terribly useful for the attacker.

Oh, I should mention, as you asked in your original question, that yes, a
compromised sys-net could absolutely and trivially reveal your IP,
regardless of whether Tor is running in sys-net or another AppVM.

All the attacker has to do is fling a single packet to their server
(bypassing Tor), and they have your address.  "ping" would do the trick.

But if Tor is in a separate AppVM, any data going into sys-net is
triply-encrypted, and the content is safe from an attacker who has
compromised sys-net.  (If Tor is running in sys-net, the traffic coming in
from the VM isn't Tor-encrypted, obviously, and far more visible, HTTPS
notwithstanding.)

JJ

-- 
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/b4db5a08cca0cef35d47c814c9121326.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

> OK, but I have already built the script. I have it running in Net VM. It
> works.
>
> I am NOT asking you to make an alternative system.
>
> I am simply asking whether an attack on the WiFi/Ethernet in the Net VM
> could also end up messing up my Tor script.
>
> Look at the question again:
>
> http://imgur.com/a/CTbLk

As mentioned, if sys-net is compromised by a NIC attack, anything running
in it is vulnerable, including the ability to modify/replace tor or tweak
the iptables to redirect all traffic intended for tor, unencrypted (other
than HTTPS encryption), to the attacker's server.

It's MITM-vulnerable for non-HTTPS connections.  And given that HTTPS
isn't secure against state actors or anyone corrupt with CA abilities,
losing the Tor layer, even with HTTPS, could be disastrous. Not great.

If your Tor is running in another appVM, such as whonix-gw does, the worst
a sys-net compromise could do is redirect the *encrypted* Tor traffic from
whonix-gw, which isn't terribly useful for the attacker.

Tor traffic is encrypted three layers deep (one might say, like an onion
:) ), with three separate public keys, for three different Tor relays. 
Unless the attacker has the private keys for those three relays (which are
randomly chosen by Tor in its vm), there's not a lot they can do with the
traffic, other than be aware of it, block/DDOS it, or correlate traffic if
they control enough entry/exit nodes.

(Now, if the compromised sys-net can somehow otherwise breach other
AppVM's or dom0, you're screwed.  But that's a given anyway, and hopefully
impossible after the latest patch against a recent and real such
vulnerability :)  And if it were possible, it would be a different attack
vector all together, since sys-whonix [for example] has no PCI devices to
be susceptible to a DMA attack.)

This discussion brought to mind another potential attack vector, in the
case of a compromised sys-net: If sys-net were compromised due to a NIC
attack of some form, it could present any fraudulent windows it wants
(e.g. password prompts) in dom0.

So make sure your sys-net has a unique and noticeable color assigned to
it, and pay heed to your window border colors.  (I guess that's the main
point of the window border coloring, is to clue in the user to attacks of
this nature.)

It could also replace/redirect the update server in sys-net, but package
signing should catch and prevent harm from that.

Digressing a bit, but related: if you ever see failed fetches during
"apt-get update," especially for security package lists, I'd recommend you
interrupt and run again.  Apparently upstream blocking of security updates
is one way attackers can leverage known vulnerabilities.  (And the fact
you're need to update a security package list is a huge "tell" that you
suffer from that vulnerability.)

More than once I've seen package lists update fine, but certain security
package list updates fail.  It could just be a transient error on the
server, but given that it's a known attack vector, it can't help be
cautious.

I'd highly recommend using apt-transport-tor, which gets packages direct
from debian, through an encrypted connection:

https://guardianproject.info/2016/07/31/howto-get-all-your-debian-packages-via-tor-onion-services/

Cheers

JJ

-- 
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/4f610b3190edc47beeb97e4a7664a132.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

> I'm pretty sure that can be done fairly simply, out-of-the-box via
> NetworkManager, not requiring a script:

Oh, and another good tip, is to make another NetworkManager show up in a
secondary VM (other than just from sys-net), you can manually add
"network-manager" (and check it) as a service in the Qubes VM Manager
(under the services tab).  That's how you get a VPN ProxyVM configured and
running, for example:

https://www.qubes-os.org/doc/vpn/

Works great!  I was using OpenVPN from the command-line and with config
files, until I realized NetworkManager would do it all for me in a more
integrated fashion.

Cheers

JJ

-- 
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/6f3796d4647939c594dfe348b1676721.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

> In terms of "hotspot" terminology, what it does is, quote from author of
> the script:
>
> "it bridges the two interfaces but uses NAT to achieve it"

Ah, so it sets up some iptable nat rules (and maybe tweaks torrc to allow
it to listen on a non-local interface; although iptables could do that
redirection, too.)

I'd generally call that "tethering" or "internet connection sharing." 
"HotSpot" implies public shared WiFi to me.

I'm pretty sure that can be done fairly simply, out-of-the-box via
NetworkManager, not requiring a script:

https://wiki.archlinux.org/index.php/NetworkManager#Sharing_internet_connection_over_Ethernet

Although if you're tunneling into another VM, it might not be that
straight forward.  Some good info and examples on such tunneling here:

https://www.qubes-os.org/doc/qubes-firewall/

And redirecting into Tor might not be doable solely from the
NetworkManager, not sure.  Although if you install Qubes-whonix, whose
gateway (sys-whonix) redirects *all* traffic over Tor, you could probably
get everything running just with GUI configuration, no scripting required.
 (Less maintenance, more reliability.)

https://www.whonix.org/wiki/Qubes

Cheers

JJ

-- 
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/aa8cdd60b636376a3622e33a0db75ad8.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

In terms of "hotspot" terminology, what it does is, quote from author of the 
script:

"it bridges the two interfaces but uses NAT to achieve it"

-- 
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/6b5e42ea-e2dc-420d-933a-3c591b75639d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

NET VM
--
--
- WiFi device-
--
- Ethernet device-
--
- Tor ethernet hotspot script-
--
--
-
-
-Ethernet crossover cable
-
-
LAPTOP 2-
---
- -
- -
- -
-   Web browser, apps etc -
- -
- -
- -
- -
---


Question:

Could a DMA attack on WiFi device or Ethernet device then take over the entire 
Net VM, modify my Tor script, and then do whatever, like, leak my real IP, pass 
all data to the hacker, etc?

-- 
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/c53c0456-5878-43d3-93cf-3fc692cd5ea8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

OK.. here we go This is my question with a DIAGRAM to help you visualise it:

http://imgur.com/a/CTbLk

-- 
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/e5651253-3453-4fa4-8795-1639d599e62f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

> OK, it's the original poster here.
> The consensus so far is that anything I run inside sys-net should be
> vulnerable, and that it is advised not to run programs in sys-net.
>
> So, in this case, how am I supposed to run my Ethernet Tor hotspot..?

I think you're going to have be more specific about what "ethernet tor
hostpot" means.  Hotspots are typically publicly accessible WiFi internet
access points.  ("Ethernet" to me implies wired, so hotspot makes a bit
less sense.)

> I had somebody write me a script that lets Qubes connect by WiFi to my
> home router, and then serve out an Ethernet hotspot that runs everything
> through Tor.
> The program works fine, but yes, it does run within sys-net.

"serve out an ethernet hotspot" and "runs everything through tor" are
confusing phrases to me.  Are you running a Tor Relay?  Or a Wifi hotspot
that sends things through Tor?  Again, if you're more specific about what
you're doing, you'll get better responses.

If you are running a network-facing service, such as a WiFi hotspot or a
gateway into your system for yourself, sys-net would indeed be a
reasonable place locate such a service.

At the very least, if you're handling incoming connections, you'll need
some port forwarding in sys-net to another VM that provides the service.

If you are running a WiFi hotspot that forwards things through the Tor
network, I'd run tor in another VM and forward the requests from sys-net
with iptables.  Tor isn't exactly a monster, but it's certainly a hacking
target for NSA and organized crooks, so I'd lean towards having it out of
sys-net.

Frankly, if you're just looking for a good personal VPN style thing, I'd
take a closer look at that streisand link I posted earlier, and leave your
personal home Qubes system out of it.  $5/mo for a server to run streisand
to eliminate incoming connections on your home system, is well worth it.

Unless I completely misunderstand what you're trying to achieve, which is
entirely possible.

JJ

-- 
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/1eeeb93551d30e346fd18edf451df272.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?

OK, it's the original poster here.

The consensus so far is that anything I run inside sys-net should be 
vulnerable, and that it is advised not to run programs in sys-net.

So, in this case, how am I supposed to run my Ethernet Tor hotspot..?

I had somebody write me a script that lets Qubes connect by WiFi to my home 
router, and then serve out an Ethernet hotspot that runs everything through Tor.

The program works fine, but yes, it does run within sys-net.

-- 
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/62d3ca97-2e26-41a8-90e3-4b50f28be1d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?