Droidwall is leaky

[GoogleCodeExporter]

** What steps will reproduce the problem?

1. Install DroidWall
2. Configure it to "blacklist" mode.
3. Check "Any application" under 3G (i.e., should block all network activity 
when on 3G).
4. Activate firewall.

[Note: I tried both blacklist and whitelist and blanket and individual app 
filters with the same results.]

** What is the expected output?

No apps have access to network. Data counters in TrafficStats and 3G Watchdog 
remain at zero.

** What do you see instead?

Both TrafficStats and 3G Watchdog count data traffic for a number of apps, with 
significant byte counts on both input and output (tens of kilobytes over a few 
hours). Culprits include:

- Dialer com.motorola.hiddenmenu Programming Menu Dialer Storage
- Network Location Settings Account and Sync Settings Storage PGM System VPN 
Services
- Amazon MP3
- Calendar Sync Adapter Google Services Framework Contacts Sync Adapter

[Ironically, pretty much the set of apps I installed DroidWall to block.]

At least something is blocked - the browser cannot load any web pages.

** What version of the product are you using? On what operating system?

This is on a Droid 1.

DroidWall 1.5.1
Android 2.2.2 build number FRG83G
Kernel 2.6.32.9-g68eeef5

** Please provide any additional information below.

Happy to test. Let me know how I can help.

# ls /sys/class/net
lo
usb0
sit0
ip6tnl0
ifb0
ifb1
ppp0
# /data/data/com.googlecode.droidwall.free/app_bin/iptables_armv5 --list 
--verbose
Chain INPUT (policy ACCEPT 146 packets, 13491 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 133 packets, 12550 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  297 24614 droidwall  all  --  any    any     anywhere             anywhere            

Chain droidwall (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 droidwall-3g  all  --  any    rmnet+  anywhere             anywhere            
    0     0 droidwall-3g  all  --  any    pdp+    anywhere             anywhere            
  156 11440 droidwall-3g  all  --  any    ppp+    anywhere             anywhere            
    0     0 droidwall-3g  all  --  any    uwbr+   anywhere             anywhere            
    0     0 droidwall-3g  all  --  any    wimax+  anywhere             anywhere            
    0     0 droidwall-3g  all  --  any    vsnet+  anywhere             anywhere            
    0     0 droidwall-wifi  all  --  any    tiwlan+  anywhere             anywhere            
    0     0 droidwall-wifi  all  --  any    wlan+   anywhere             anywhere            
    0     0 droidwall-wifi  all  --  any    eth+    anywhere             anywhere            

Chain droidwall-3g (6 references)
 pkts bytes target     prot opt in     out     source               destination         
  133  8826 droidwall-reject  all  --  any    any     anywhere             anywhere            

Chain droidwall-reject (1 references)
 pkts bytes target     prot opt in     out     source               destination         
  133  8826 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-port-unreachable 

Chain droidwall-wifi (3 references)
 pkts bytes target     prot opt in     out     source               destination         

Original issue reported on code.google.com by reid@reidster.net on 19 Jul 2011 at 1:50

[GoogleCodeExporter]

Do you know if your provider supports IPv6?

The following interfaces suggest that your device supports IPv6:
sit0, ip6tnl0, ifb0, ifb1

From the iptables output, it is possible to see that 297 packets where handled 
by the OUTPUT chain, but only 156 of then were directed to the ppp0 interface.
So, it is possible that the remaining of the packets are being routed to one of 
the interfaces described above.

You can probably check exactly to which interface by manually adding iptables 
rules into the "droidwall" chain:
# /data/data/com.googlecode.droidwall.free/app_bin/iptables_armv5 -A droidwall 
-o sit+ -j droidwall-3g
# /data/data/com.googlecode.droidwall.free/app_bin/iptables_armv5 -A droidwall 
-o ip6tnl+ -j droidwall-3g
# /data/data/com.googlecode.droidwall.free/app_bin/iptables_armv5 -A droidwall 
-o ifb+ -j droidwall-3g

The, after some time, check the status again with:
# /data/data/com.googlecode.droidwall.free/app_bin/iptables_armv5 --list 
--verbose

Thanks in advance!

Original comment by rodrigo...@gmail.com on 20 Jul 2011 at 6:52

[GoogleCodeExporter]

Rodrigo, thanks for getting back to me! I really appreciate your help.

I don't know about IPv6; my interfaces with 3G up and WiFi turned off are:

# ls /sys/class/net
lo
usb0
sit0
ip6tnl0
ppp0
ifb0
ifb1

I:

(a) installed the three extra rules as you suggested
(b) zeroed the iptables counters
(c) zeroed the counters in 3G Watchdog and Traffic Stats Lite
(d) confirmed that the firewall was up by trying to load a web page (which 
failed as expected)
(e) waited for a couple of hours.

This is the output from --list --verbose:

# /data/data/com.googlecode.droidwall.free/app_bin/iptables_armv5 --list 
--verbose
Chain INPUT (policy ACCEPT 742 packets, 70433 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 738 packets, 69456 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1478  119K droidwall  all  --  any    any     anywhere             anywhere            

Chain droidwall (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 droidwall-3g  all  --  any    rmnet+  anywhere             anywhere            
    0     0 droidwall-3g  all  --  any    pdp+    anywhere             anywhere            
  740 49729 droidwall-3g  all  --  any    ppp+    anywhere             anywhere            
    0     0 droidwall-3g  all  --  any    uwbr+   anywhere             anywhere            
    0     0 droidwall-3g  all  --  any    wimax+  anywhere             anywhere            
    0     0 droidwall-3g  all  --  any    vsnet+  anywhere             anywhere            
    0     0 droidwall-wifi  all  --  any    tiwlan+  anywhere             anywhere            
    0     0 droidwall-wifi  all  --  any    wlan+   anywhere             anywhere            
    0     0 droidwall-wifi  all  --  any    eth+    anywhere             anywhere            
    0     0 droidwall-wifi  all  --  any    ra+     anywhere             anywhere            
    0     0 droidwall-3g  all  --  any    sit+    anywhere             anywhere            
    0     0 droidwall-3g  all  --  any    ip6tnl+  anywhere             anywhere            
    0     0 droidwall-3g  all  --  any    ifb+    anywhere             anywhere            

Chain droidwall-3g (9 references)
 pkts bytes target     prot opt in     out     source               destination         
  740 49729 droidwall-reject  all  --  any    any     anywhere             anywhere            

Chain droidwall-reject (1 references)
 pkts bytes target     prot opt in     out     source               destination         
  740 49729 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-port-unreachable 

Chain droidwall-wifi (4 references)
 pkts bytes target     prot opt in     out     source               destination         

[Note that the number of packets in chain OUTPUT is twice the number of packets 
through the droidwall chain, minus 2.]

3G Watchdog reports the following:

  All applications:
    Received 14.4 KB
    Sent 15.8 KB
    Total 30.3 KB

  Dialer com.motorola.hiddenmenu... 22.7 KB
  Network Locaton Settings...       15.4 KB
  Superuser                          5 B
  Words Free                         4 B

Traffic Stats Lite reports the following:

                                                    Sent   Received
  Total GPRS/EDGE/3G                                 0 B   977 B
  Dialer Dialer Storage com.motorola.hiddenmenu...  15 kB    9 kB
  Android System Settings Network Location...        5 kB   10 kB
  Superuser                                          5 B     0 B
  Words Free                                         4 B     0 B

  [yeah, those numbers don't add up to that total]

Let me know what else you need. Thanks for your help!

Original comment by reid@reidster.net on 25 Jul 2011 at 1:37

[GoogleCodeExporter]

FWIW, ipv6.google.com doesn't work regardless of whether the firewall is 
enabled.

Original comment by reid@reidster.net on 25 Jul 2011 at 1:45

[GoogleCodeExporter]

Issue 169 has been merged into this issue.

Original comment by rodrigo...@gmail.com on 10 Aug 2011 at 1:03

[GoogleCodeExporter]

Issue 171 has been merged into this issue.

Original comment by rodrigo...@gmail.com on 10 Aug 2011 at 1:03

[GoogleCodeExporter]

We have a number of similar complaints now, but I cannot reproduce this issue 
in any of my devices.

This is what I currently know:

1. When DroidWall's log is enabled, it will allow all DNS queries to pass the 
firewall. This is necessary to show correct IP addresses on the log. This 
should add to a few bytes daily, but rarely over 2KB/day - UNLESS there is a 
buggy/misbehaving application.
If you are on a very limited data plan, please turn off DroidWall's log and 
enable it only when necessary.

2. Monitoring apps cannot reliably determine how much data a single app has 
transferred over a specific interface. It seems to be impossible to do that 
using the Android API.
The "data per app" on those monitoring apps will always count loop-back traffic 
in the totals - which is not (nor should be) blocked by DroidWall. This data is 
not sent over your cellular network.

3. Currently, DroiWall does not block incoming connections (only outgoing). It 
is possible that, depending on the carrier, they communicate to your phone by 
initiating a remote connection - which will consume cellular data.
I will probably add an option to block incoming connections soon... but for 
now, you can manually block them using the following command on a root terminal:
/data/data/com.googlecode.droidwall.free/app_bin/iptables_armv5 -A INPUT -m 
state --state NEW -j DROP

You can even check if there was any blocked incoming connection with the 
following command:
/data/data/com.googlecode.droidwall.free/app_bin/iptables_armv5 -L INPUT -v

Example output from the command above:
Chain INPUT (policy ACCEPT 233 packets, 39287 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  any    any     anywhere             anywhere            state NEW 

The "pkts" here represent how many connections attempts were blocked.
Just keep in mind that once you reboot your phone you need to run this command 
again to keep blocking.

Can someone please test and let me know if this changes anything?
Thanks

Original comment by rodrigo...@gmail.com on 10 Aug 2011 at 1:46

[GoogleCodeExporter]

Rodrigo, thank you very much for your detailed explanation. 

The "1. When DroidWall's log is enabled, it will allow all DNS queries to pass 
the firewall. This is necessary to show correct IP addresses on the log." is 
indeed what must be happening for me - the traffic is minor.

Anyway, I wasn't worrying about traffic, but rather information leaking. I'm 
almost 100% your explanations are correct.

Thanks again for a great app and great support. Are you planning the "block 
incoming traffic" option?

Original comment by Roman.Be...@gmail.com on 10 Aug 2011 at 1:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Tried entering the command 
"/data/data/com.googlecode.droidwall.free/app_bin/iptables_armv5 -A INPUT -m 
state --state NEW -j DROP" and got "iptables v1.4.10: can't initialize iptables 
table 'filter': Table does not exist (do you need to insmod?)Perhaps iptables 
or your kernel needs to be upgraded."

my kernel version is 2.6.32.9

Original comment by mnann2...@gmail.com on 10 Aug 2011 at 8:53

[GoogleCodeExporter]

mnann2...@gmail.com, are you sure you ran this command as root?

Original comment by rodrigo...@gmail.com on 11 Aug 2011 at 12:06

[GoogleCodeExporter]

I tried running it again through terminal emulator but got the same error. My 
phone is rooted and so I should have root access I also tried running the sudo 
command which isn't supported. 

Original comment by mnann2...@gmail.com on 11 Aug 2011 at 7:21

[GoogleCodeExporter]

mnann2...@gmail.com, please try this:
su <ENTER>
... (Superuser may pop, requesting root access - ALLOW)
/data/data/com.googlecode.droidwall.free/app_bin/iptables_armv5 -A INPUT -m 
state --state NEW -j DROP

(note "su" instead of sudo)

Original comment by rodrigo...@gmail.com on 12 Aug 2011 at 12:47

[GoogleCodeExporter]

closing due to inactivity.

Original comment by rodrigo...@gmail.com on 7 Oct 2011 at 5:27

• Changed state: Done

[GoogleCodeExporter]

I know it's not my call, but I think closing this bug is a mistake.

I see open source projects do this all the time, and it always seems like the 
wrong move. Just because the original reporter disappears doesn't mean the bug 
is solved or never existed. Closing the bug removes the opportunity to work on 
it sometime in the future and overstates the software's reliability.

Speaking for myself, the behavior I described was very real. But, I just don't 
have time to track down weird bugs, and leaving 3G was a battery hog. So, I 
stopped using DroidWall and just toggled 3G on when I needed it.

I'm not asking you to work on it; you choose how to spend your time. It's just 
that closing the report implies a resolution which isn't there.

Thanks,

Reid

Original comment by reid@reidster.net on 10 Oct 2011 at 1:17

[GoogleCodeExporter]

Reid, I believe that this bug can really be closed considering Comment 6. There 
is no "real" data leakage.

I just kept this issue opened for a while because of Comment 9, which is not 
really related to the original report.

Original comment by rodrigo...@gmail.com on 10 Oct 2011 at 2:18

[GoogleCodeExporter]

i am having the same problem with uid 1000 & 1001; even when on wifi data is 
being uploaded & downloaded.

Original comment by spa...@gmail.com on 12 Nov 2011 at 9:53

[GoogleCodeExporter]

Issue 213 has been merged into this issue.

Original comment by rodrigo...@gmail.com on 5 Dec 2011 at 11:41

[GoogleCodeExporter]

Same issue over here, but this time its not exactly a "small" leakage... As per 
3G Watchdog, 500K leaked from "OS Services + Other" during the first 10 minutes 
of mobile network usage. Selected Blacklist on DroidWall, tried blocking 
everything over 3G, however issue persists...

Something new related to this?

Original comment by mradzin...@gmail.com on 29 Jan 2012 at 8:31

[GoogleCodeExporter]

There are two problems:

1) When you boot your phone, there's a brief period between your phone waking 
up and DroidWall getting out of bed. It only lasts a few seconds, but in those 
seconds any app can go online.
http://androidunderground.blogspot.com/2011/05/droidwall-has-leaky-boots.html

Switching your data connection off the normal way doesn't always help, because 
some apps switch it back on without any user interaction (and then other apps 
can hitch a ride on the open connection):
http://androidunderground.blogspot.com/2011/06/lookout-opens-unwanted-data-conne
ctions.html

A fix (or workaround) would be for DroidWall to ApnDroid your access points on 
shutdown, and change 'em back to normal upon boot after its done writing 
iptables. That won't fix data leak after the phone crashes, but at least it 
will plug the holes after user-initiated shutdowns/reboots.

Original comment by evildi...@gmail.com on 5 Mar 2012 at 4:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi!

Adding my two cents here...
I do not use DroidWall per se (since I'm on JellyBean), but the problem is the 
same with AFWall+ and Android Firewall, which both are based on DroidWall.

I have the same "data leaky" problem on my phone and I can rule out both the 
"localhost traffic" and "data sent before Firewall is active" explanations.

1) Even when the firewall is active I can see (by repeatedly opening the data 
usage statistics) that the "OS Services" process uses 3G data, even though I 
have blocked it.
2) My monthly statistics currently states 26MB for February out of which 8MB 
are caused by OS Services. On my provider's customer service page in the web I 
can see that the used (and billed) data actually is 26MB.

I have allowed the following apps 3G access:
- Browsers (Chrome, Firefox, Opera)
- Connectbot
- SMS/MMS (--> for MMS)
- Maildroid
- Viber
- WhatsApp

No OS Services here...

Any ideas (also what else to test and check) are appreciated!

BR
 Alex

Original comment by Alestri...@googlemail.com on 17 Feb 2013 at 9:46

[GoogleCodeExporter]

i see this is an old thread but. i am seeing ( using network log app ) apps 
that are supposedly blocked sending and recieving hundreds of packets ofer the 
course of an hour or so. clean master, root, kernal, play services, playstore, 
and some others.
rooted, slimbean, lg 696 otimus elite.

Original comment by Gr8fult...@gmail.com on 22 Aug 2014 at 4:16