1034411 - Lock down WiFi debugging to only external interface

Status: NEW

(DevTools :: about:debugging, defect, P3)

Description

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

To prevent apps from connecting to the debug server, we should lock down the WiFi debug socket to only allow connections over the WiFi interface and block any from local / lo0.

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Attachment: Unique device discovery names for b2g

Paul, this gives a more unique name on b2g, such as "flame-1234abcd", instead of just "flame".

This would become important anywhere there are many b2g devices on the same local network (like most Mozilla offices I would guess!).

Try: https://tbpl.mozilla.org/?tree=Try&rev=ef1e7e43fdc5

Comment 2

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Oops, wrong bug.

Comment 3

[Julian Descottes [:jdescottes]]

About:debugging bug triage. Filter on TRIAGE-JD201705

Temporarily setting P3 to bugs migrated from webide to cleanup the triage for about:debugging.

Comment 4

[Julian Descottes [:jdescottes]]

Considering the current thread about wifi authentication protocol and potential vulnerabilities for the debugger (ie the client), I am not sure about this bug. What are the apps mentioned here in the summary? ffos apps or applications/processes other than Firefox?

Comment 5

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

This bug is about adding some mechanism to restrict the WiFi debugging socket opened on the server side (Android phones, etc.) so that it only listens on the WiFi network interface.

When this bug was filed, we mainly had Firefox OS in mind.  We were worried that random apps on the phone might have the ability to connect to the server socket over the local interface, which would imply breaking any sense of per-app isolation on the device, since an evil app could then steal any data on the phone.

It appears that a similar concern may still apply with Firefox for Android.  "Some applications use localhost network ports for handling sensitive IPC. You should not use this approach because these interfaces are accessible by other applications on the device."[1]  My knowledge of Android sandboxing is limited, but this guidance suggests to me that the current WiFi debugging socket setup may allow a malicious attacking Android app to connect to the server socket over a local interface.

However, such malicious apps would still trigger authentication prompts and such, so it's not as if they would silently get access to data.  For an informed user, they would most likely only be an annoyance that they would then block using the connection prompt in Firefox for Android.  So I would say the overall risk here is low.

This bug then is mostly about defense in depth: since there's no functional need to allow access over the local interface for WiFi debugging, we should block it.

To achieve the desired goal here, we would need to:

1. Add some way to restrict a server socket opened via `initSpecialConnection`[2] to only listen on the WiFi interface
  * Currently there is a "local interface only" mode, but here we want sort of the opposite as "WiFi interface only"
2. The steps to open the server socket for WiFi on phones[3] should use this new mode
  * Looks like WiFi debugging isn't listed currently in the GeckoView version[4] (maybe since it currently requires QR code reader)

[1]: https://developer.android.com/training/articles/security-tips#Networking
[2]: https://searchfox.org/mozilla-central/rev/8affe6e83188787eb61fe0528eeb6eef6081ba06/devtools/shared/security/socket.js#438
[3]: https://searchfox.org/mozilla-central/rev/8affe6e83188787eb61fe0528eeb6eef6081ba06/mobile/android/chrome/content/RemoteDebugger.js#342
[4]: https://searchfox.org/mozilla-central/source/mobile/android/modules/geckoview/GeckoViewRemoteDebugger.jsm