tomagoyaky / droidwall

Automatically exported from code.google.com/p/droidwall
0 stars 0 forks source link

(Deliberate) bypass on UDP 53 with logging & whitelisting enabled #125

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Api.java@246-249:
if (whitelist && logenabled) {
    script.append("# Allow DNS lookups on white-list for a better logging (ignore errors)\n");
    script.append("$IPTABLES -A droidwall -p udp --dport 53 -j RETURN\n");
}

While I understand the reasoning behind that course of action (allow hostnames 
in logs), it still allows creators of malicious apps to emit arbitrary traffic 
over UDP 53.

droidwall is a direct subchain of OUTPUT (-A OUTPUT -j droidwall), this is the 
first rule in droidwall (the "categorisation" for droidwall-3g and 
droidwall-wifi are added after it, so this rule will match first) and there are 
no further rules added to OUTPUT, which means that a packet from ANY 
application outbound on UDP 53 will traverse the chains like this:
OUTPUT -> droidwall -> OUTPUT -> done

I just checked which UIDs perform the DNS lookups, sadly it seems that it's 
performed under the UID of the actual app (and not as the kernel), otherwise 
you could simply whitelist the kernel on that port.

What do you think about adding an option to either have neat logs (and possible 
FW bypass) xor have a completely locked down whitelist and unresolved hosts in 
the log?

Original issue reported on code.google.com by manuel.l...@gmail.com on 31 Mar 2011 at 11:03

GoogleCodeExporter commented 8 years ago
You are right about an application being able to "bypass" the firewall by just 
using UDP port 53.
The logging feature was not designed to be always enabled, but rather to help 
you find out which application needs to be unblocked for a specific purpose.

I however have to admit that most people is simply using DroidWall with the log 
always on, so I will strongly consider adding an option to block UDP 53 even 
when the log is enabled.

Original comment by rodrigo...@gmail.com on 1 Apr 2011 at 1:29