849061 - Security Review for UDPServerSocket

Status: RESOLVED FIXED

(mozilla.org :: Security Assurance: Review Request, task)

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

As part of Simple Push Notifications for B2G, support for receiving wake up messages via UDP is needed. Simple Push has been reviewed at a high level, but UDP support was not complete when the previous review was done, so we should really have a look at both the UDP server implementation, and also how it is used in Firefox OS.

Comment 1

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

The way this works for Push is that the UDP server is only started on a network that supports it. Specifically, the first time a phone enters a mobile network, it contacts the push server in-band with the SimplePush protocol, not using UDP at all. The phone and server exchange information so that the server knows if it can use UDP. This is because all networks won't support UDP, and on wifi networks its easier to just keep the TCP channel open. If the user switches to a network where the operator does not have a push server supporting UDP (say user is on roaming), again UDP is not possible.

So when the server determines it can wake up the phone over UDP, it closes the TCP connection after informing the phone that it can be woken up. At this point the phone starts the UDP socket.

In the current protocol, the 'weakness' is that the UDP packet sent to the phone does not need to contain any information, it can simply be a blank packet and this will cause the phone to wake up the push service and go and contact the push server over TCP. Potentially, an attacker who gets access to one of the routers or something (sorry if my networking is hand-wavy when it comes to broadcast), he could force all phones to keep waking up. AFAIK it is not possible for one phone to reach another phone via IP on an operator network. If this is a security flaw then we can fix how the wake up occurs (by putting something in the UDP packet that only the push server knows, the user agent ID)

Comment 2

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Nikhil Marathe from comment #1)
> The way this works for Push is that the UDP server is only started on a
> network that supports it. 

Sorry to be a pain, but can you point me to the Push API code (either bug, or mxr link etc)? There isn't any code in bug 822712, and I looked couldn't find the right bug/or find the code in mxr.

Comment 3

[Doug Turner (:dougt)]

https://hg.mozilla.org/users/nsm.nikhil_gmail.com/push-ws1

It isn't ready for review yet.

Comment 4

[Paul Theriault [:pauljt] (no longer reading bugmail)]

See also https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=822712&attachment=725658 for code.

I still haven't been able to confirm typical network controls for mobile data networks, but I don't think it is safe to assume that one mobile device would be prevented from sending a UDP packet to another mobile device. 

On the flipside - if an attacker does spam the network with UDP packets, and we are processing them (ie looking for some secret) haven't we already woken the phone up at this point? 

Not sure how serious this threat is though(and maybe an attacker with the ability to flood the network with network traffic can already achieve the same thing in other ways? I don't know enough about mobile networking stacks vs battery consumption.

Can anyone from TEF provide input here?

Comment 5

[Doug Turner (:dougt)]

> I don't think it is safe to assume that one mobile device would be prevented from sending a UDP packet to another mobile device.

Why?

Also, what would you have us do if this wasn't true?

Comment 6

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Doug Turner (:dougt) from comment #5)
> > I don't think it is safe to assume that one mobile device would be prevented from sending a UDP packet to another mobile device.
> 
> Why?

From discussions with ex-telco engineer friends - but I dont have any real evidence apart from their opinions, hence the request to TEF.

> 
> Also, what would you have us do if this wasn't true?

Well nothing - I was really just was responding to Nikhil's comment. Waking the up the gecko stack just to process a UDP message to check if you should wake up seem counter-intuitive to me.

From a security review perspective I have been through the code in 822712 and 839757 I don't see anything of concern. Worst case on the battery draining issue it will be a low risk ( a specific DoS, which requires significatn attacker resources, and could possibly be achieved in other ways anyways) - happy to continue the discussion, but I'm closing this from a security review perspective.