Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

whonix-gw-15 allows leaking of ip #5629

Closed
bugreporter123456 opened this issue Feb 7, 2020 · 9 comments
Closed

whonix-gw-15 allows leaking of ip #5629

bugreporter123456 opened this issue Feb 7, 2020 · 9 comments
Labels
C: Whonix This issue impacts Qubes-Whonix P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. privacy This issue pertains to data or information privacy through technological means. R: not applicable E.g., help/support requests, questions, discussions, "not a bug," not enough info, not actionable. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.

Comments

@bugreporter123456
Copy link

Qubes OS version:

R4.0

Affected component(s) or functionality:

whonix-gw in default configuration and every vm connected to it.


Steps to reproduce the behavior:

1.create 2 vm's one connected to sys-whonix and the other connected to sys-firewall
2.install and run teamviewer on both.
3.get the same ID on both despite having different ip adresses.

Expected or desired behavior:

1.create 2 vm's one connected to sys-whonix and the other connected to sys-firewall
2.install and run teamviewer on both.
3.get the different id's or have teamviewer not work because tor dont like udp and have your packets dropped because of this.

Actual behavior:

1.create 2 vm's one connected to sys-whonix and the other connected to sys-firewall
2.install and run teamviewer on both.
3.get the same ID on both despite having different ip adresses.

General notes:

whonix-gw-15 should ether torify or drop in default connection.


I have consulted the following relevant documentation:

https://www.qubes-os.org/doc/whonix/
https://www.whonix.org/wiki/Corridor
https://www.whonix.org/wiki/Multiple_Whonix-Workstation#Qubes-Whonix

I am aware of the following related, non-duplicate issues:

I dont know what exactly this section is for.

@bugreporter123456
Copy link
Author

bugreporter123456 commented Feb 13, 2020

on each one individually.
they are not supposed to see each other, since they are on different vm's, one should have been for an anonym purpose.
the number is not random, instead given from the teamviewer server.
it may be have to do with UDP.

My uneducated guess would be that whonix-gw passed the UDP traffic directly.

I was today able to replicate this.

@andrewdavidwong andrewdavidwong added C: Whonix This issue impacts Qubes-Whonix P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. privacy This issue pertains to data or information privacy through technological means. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. labels Feb 15, 2020
@andrewdavidwong andrewdavidwong added this to the Release 4.0 updates milestone Feb 15, 2020
@andrewdavidwong
Copy link
Member

FYI @adrelanos

@adrelanos
Copy link
Member

  • A) debian-10 based DispVMs behind sys-firewall (no Tor)
  • B) debian-10 based DispVMs behind sys-firewall (no Tor)
  • Will get the same ID.
  • This was a baseline test, unrelated to Whonix, to make sure the same ID if same IP assumption is true.
  • Ok as expected.

  • A) debian-10 based DispVM behind sys-firewall (no Tor)
  • B) whonix-ws-15 based DispVM behind sys-whonix
  • These IDs were different.
  • Therefore we don't have evidence of a clearnet leak.
  • Ok as expected.

  • A) whonix-ws based DispVM behind sys-whonix
  • B) whonix-ws based DispVM behind sys-whonix
  • Will get same ID.
  • This isn't nice. After installing teamviewer_amd64.deb there is a process running /opt/teamviewer/tv_bin/teamviewerd -d as root. It also opens a local listener. It might be using raw sockets to communicate despite there being iptables rules?
  • But actually enabling networking between two qubes should require changes in firewall VM (here: sys-whonix)? There could be T466 Qubes sys-whonix does not do its job as Qubes FirewallVM? @marmarek

  • A) whonix-ws based DispVM behind sys-whonix-1
  • B) whonix-ws based DispVM behind sys-whonix-2
  • Will get different ID.
  • Ok as expected.

@marmarek
Copy link
Member

I wonder if it isn't because of some template property - some unique id there (/etc/machine-id?). But then in the last test you'd get the same ID too. Can you confirm the last test was using the samoe whonix-ws template?
I also assume you install teamviewer in a DispVM, not template right? Otherwise it could generate its ID during installation and share it with child VMs.
Does two VMs connected to the same sys-whonix have guarantee to use different exit nodes? Or only different circuits? Or maybe not even that?

@adrelanos
Copy link
Member

adrelanos commented Feb 17, 2020 via email

@unman
Copy link
Member

unman commented Feb 17, 2020

I've seen this claim before and I think it's bogus. I dont think it has anything to do with "leaking IP" address, or "raw sockets", although I do think that TeamViewer is a security risk I wouldn't touch.
I don't think it has anything to do with IP address because TeamViewer works with clients that repeatedly change their IP address, and is intended to work with clients behind NAT, e.g a single client in a large corporate network. Just a moment's thought would tell you that. (And indeed, if you change your IP address you can still use TeamViewer sessions just fine).
So let's not go jumping to conclusions on flimsy evidence. My guess is that @marmarek is right.

Take a look at the actual interchange involved in a TeamViewer session and (amongst other stuff) you see this:

2020/02/17 03:01:14.526 11527 136435699255040 S   IdentifyRequest: ID = 0, IC = -1519897813, IsTemporaryID = 0, InitiativeGUID = 4f34cda4-cb57-4275-9443-674342cff7b3, CanStoreGUID = 1, MIDHistory = {-1519897813_346f0d2bb_c2c07e713ad653a7|l4916690911a44ba585e92c73c17e54da:00163e5e6c00:08cc391cdac94d7c9601df975e9be5e4|alinux024916690911a44ba585e92c73c17e54da:00163e5e6c00:08cc391cdac94d7c9601df975e9be5e4}, MIDv = 0, MaxSupportedMIDv = 2, RebootHash = {24196f67-eb01-a48a-a0ea-7f1a8c6a1277}, MIDFlags = 16, MIDForceUpdateFlags = 0, AttractionGUID = 00000000-0000-0000-0000-000000000000, TerminalServerIDsInToken = 1

Well, some of that looks familiar ( in format, if not detail):
l4916690911a44ba585e92c73c17e54da: that's /etc/machine-id
00163e5e6c00: That's MAC address
08cc391cdac94d7c9601df975e9be5e4 : blkid of the root disk

If I change those can I get a different ID? Yes, change both MAC and blkid, and I get a new ID on the same qube.
So the basis of the issue here is bogus. It's a long leap from "two qubes get the same ID" to "Whonix is leaking IP", or "qubes are circumventing firewalls".
I'm not saying that Whonix doesnt leak IP - I'm saying that this on its own doesn't suggest it.

@adrelanos There's not enough detail in your test descriptions. Check the hardware characteristics for the whonix-ws instances where they got same ID and where they got different ID.

@adrelanos
Copy link
Member

Used a debian-10-minimal appvm behind sys-whonix + whonix-ws-15 based DispVM behind the same sys-whonix. Got a different teamviewer ID. Therefore team viewer ID is probably based something /etc/machine-id alike as unman previously pointed out. It's not /etc/machine-id specifically (tested to modify it in one VM) but must be some other shared identifier in root image.

Therefore I suggest to close this issue as invalid.

@andrewdavidwong andrewdavidwong added the R: not applicable E.g., help/support requests, questions, discussions, "not a bug," not enough info, not actionable. label Mar 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Whonix This issue impacts Qubes-Whonix P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. privacy This issue pertains to data or information privacy through technological means. R: not applicable E.g., help/support requests, questions, discussions, "not a bug," not enough info, not actionable. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
Projects
None yet
Development

No branches or pull requests

6 participants
@marmarek @adrelanos @andrewdavidwong @unman @bugreporter123456 and others