linux-igd-devel

[Linux-igd-devel] Security issues to address...

[Daniel J B. <dan...@gm...>]

With 0.95 out, there are some security issues that need to be addressed.

Armijn Hemel has pointed out some areas he was able to exploit (see
http://www.upnp-hacks.org/stacks.html#linux-igd).

The security update to always store IP addresses in inaddr structures,
rather than (unbounded) strings isn't much work overall, so I can get
a patch in for this.

There does need to be a check through the code paths to ensure
requests are correctly validated, and to address some of the issues
that Armijn has raised.

Any thoughts?
-- 
Daniel J Blueman

Re: [Linux-igd-devel] Security issues to address...

[Nektarios K. P. <npa...@in...>]

Daniel J Blueman wrote:
> With 0.95 out, there are some security issues that need to be addressed.
> 
> Armijn Hemel has pointed out some areas he was able to exploit (see
> http://www.upnp-hacks.org/stacks.html#linux-igd).
> 
> The security update to always store IP addresses in inaddr structures,
> rather than (unbounded) strings isn't much work overall, so I can get
> a patch in for this.
> 
> There does need to be a check through the code paths to ensure
> requests are correctly validated, and to address some of the issues
> that Armijn has raised.
> 
> Any thoughts?

In the update Layer3Forwarding patch, I added a check for the protocol 
type in the AddPortMapping handling code. I also have in a TODO comment 
the checks for the rest of the input arguments.
Regarding the check for a valid NewInternalClient/NewRemoteHost 
arguments do you think a check for a valid IP string is sufficient or do 
we need to support dns look up? I think the spec permits an IGD device 
not to accept hostname for these arguments.

I can fill the missing parts for:
isBoolean(...)
isUI4(...)
isUI2(...)
isAddress(...)

although I think the libupnp itself is better place to implement at 
least the first three.


I'm not sure I understand the final comment in the Armijn report:

<quote>
...,but there is no check to see whether or not NewInternalClient is an 
external IP address.
</quote>

Why is it important whether or not it is an external IP address. I think 
the right input/output interface is properly set in the iptables 
invocation so having an external IP address in the NewInternalClient 
will just result in an ACCEPT rule that is impossible to trigger.
What do I miss here?

-- 
Nektarios K. Papadopoulos
inAccess Networks

Re: [Linux-igd-devel] Security issues to address...

[Armijn H. <ar...@uu...>]

hi,

[cut]
> I'm not sure I understand the final comment in the Armijn report:
> 
> <quote>
> ...,but there is no check to see whether or not NewInternalClient is an 
> external IP address.
> </quote>
> 
> Why is it important whether or not it is an external IP address. I think 
> the right input/output interface is properly set in the iptables 
> invocation so having an external IP address in the NewInternalClient 
> will just result in an ACCEPT rule that is impossible to trigger.
> What do I miss here?

I was able to trigger this (repeatedly) with several routers that use
linux-igd. If NewInternalClient is actually an external IP address it will
make a firewalling rule for that external IP address. Connect to the port
that is opened from the outside and your traffic will nicely go through NAT
to the destination port (NewInternalPort if I remember correctly) without a
problem.

armijn

-- 
 ---------------------------------------------------------------------------
  ar...@uu... | http://www.uulug.nl/ | UULug: Utrecht Linux Users Group
 ---------------------------------------------------------------------------

Re: [Linux-igd-devel] Security issues to address...

[Nektarios K. P. <npa...@in...>]

Hi,

Armijn Hemel wrote:
> hi,
> 
> [cut]
>> I'm not sure I understand the final comment in the Armijn report:
>>
>> <quote>
>> ...,but there is no check to see whether or not NewInternalClient is an 
>> external IP address.
>> </quote>
>>
>> Why is it important whether or not it is an external IP address. I think 
>> the right input/output interface is properly set in the iptables 
>> invocation so having an external IP address in the NewInternalClient 
>> will just result in an ACCEPT rule that is impossible to trigger.
>> What do I miss here?
> 
> I was able to trigger this (repeatedly) with several routers that use
> linux-igd. If NewInternalClient is actually an external IP address it will
> make a firewalling rule for that external IP address. Connect to the port
> that is opened from the outside and your traffic will nicely go through NAT
> to the destination port (NewInternalPort if I remember correctly) without a
> problem.
> 
> armijn
> 
You are right, when adding a port mappings only the 'in' interface is 
set to the 'WAN' interface of the IGD in the iptables rule. The 'out' 
interface of the rule is set to 'any'.
I intend add the check anyway, but let me continue the discussion:

So, the security issue here is that a malicious control point can add a 
port mapping that let an external entity to connect to your IGD on a 
port and then forward this connection to another external host 
pretending to be your IGD?
I see only two minor bad issues with this scenario:
- Unnecessary traffic is passing through your IGD
- The external host (RemoteHost upnp arg) can be fulled to allow the 
connection based on your IP.

Don't get me wrong. I *do* appreciate your vulnerability report and the 
check should be implemented.
However, unless we implement e.g. DeviceSecurity service, a malicious 
control point in the LAN can open up whatever port pleases it and be 
upnp correct anyway ;-)

-- 
______________________________________________________________
Nektarios K. Papadopoulos
Senior Engineer
Software Engineering Group
inAccess Networks
95A Pentelis Avenue.    Tel    : +30-210-6837640
152 34 Halandri Athens  Fax    : +30-210-6899504
______________________________________________________________

Re: [Linux-igd-devel] Security issues to address...

[<ju...@ik...>]

On Fri, 18 Aug 2006 12:02:35 +0300 "Nektarios K. Papadopoulos"
<npa...@in...> wrote:

> So, the security issue here is that a malicious control point can add a
> port mapping that let an external entity to connect to your IGD on a 
> port and then forward this connection to another external host 
> pretending to be your IGD?
> I see only two minor bad issues with this scenario:
> - Unnecessary traffic is passing through your IGD
> - The external host (RemoteHost upnp arg) can be fulled to allow the 
> connection based on your IP.

How about if someone visits a lan host and forwards some external ports and then
route all his spamming and cracking attempts through IGD IP address. I agree
this could be done without this vulnerability as well if the malicious user
already has access to any lan computers. But it does make it much harder to
detect. Just something that comes into my mind.

> However, unless we implement e.g. DeviceSecurity service, a malicious 
> control point in the LAN can open up whatever port pleases it and be 
> upnp correct anyway ;-)

UPnP just sucks in security big time. On the other hand this makes it important
to pay some extra attention to security issues.


Juho

Re: [Linux-igd-devel] Security issues to address...

[Armijn H. <ar...@uu...>]

hi,

> So, the security issue here is that a malicious control point can add a 
> port mapping that let an external entity to connect to your IGD on a 
> port and then forward this connection to another external host 
> pretending to be your IGD?
> I see only two minor bad issues with this scenario:
> - Unnecessary traffic is passing through your IGD
> - The external host (RemoteHost upnp arg) can be fulled to allow the 
> connection based on your IP.

And basically turn your router in an involuntary onion router. I wouldn't
call that "a minor bad issue" ;)

> Don't get me wrong. I *do* appreciate your vulnerability report and the 
> check should be implemented.
> However, unless we implement e.g. DeviceSecurity service, a malicious 
> control point in the LAN can open up whatever port pleases it and be 
> upnp correct anyway ;-)

Yes, unfortunately. UPnP is flawed by design. Too bad there are so many
machines using it...

armijn

-- 
 ---------------------------------------------------------------------------
  ar...@uu... | http://www.uulug.nl/ | UULug: Utrecht Linux Users Group
 ---------------------------------------------------------------------------

Re: [Linux-igd-devel] Security issues to address...

[Nektarios K. P. <npa...@in...>]

Hi,

Armijn Hemel wrote:
> hi,
> 
>> So, the security issue here is that a malicious control point can add a 
>> port mapping that let an external entity to connect to your IGD on a 
>> port and then forward this connection to another external host 
>> pretending to be your IGD?
>> I see only two minor bad issues with this scenario:
>> - Unnecessary traffic is passing through your IGD
>> - The external host (RemoteHost upnp arg) can be fulled to allow the 
>> connection based on your IP.
> 
> And basically turn your router in an involuntary onion router. I wouldn't
> call that "a minor bad issue" ;)
I understand. Bad evaluation/wording on my part.
> 
>> Don't get me wrong. I *do* appreciate your vulnerability report and the 
>> check should be implemented.
>> However, unless we implement e.g. DeviceSecurity service, a malicious 
>> control point in the LAN can open up whatever port pleases it and be 
>> upnp correct anyway ;-)
> 
> Yes, unfortunately. UPnP is flawed by design. Too bad there are so many
> machines using it...
> 
Yeah, I know, that is why I disabled UPnP on my home router :-(
Nevertheless, I *do* care to participate in developing a complete 
(first) and secure (later) one here :-)

Thanks again.
> armijn
> 

-- 
______________________________________________________________
Nektarios K. Papadopoulos
Senior Engineer
Software Engineering Group
inAccess Networks
95A Pentelis Avenue.    Tel    : +30-210-6837640
152 34 Halandri Athens  Fax    : +30-210-6899504
______________________________________________________________