Android is the only operating system that fully immunizes VPN apps from the attack because it doesn’t implement option 121. For all other OSes, there are no complete fixes.
Operating/System 
The most effective fixes are to run the VPN inside of a virtual machine whose network adapter isn’t in bridged mode or to connect the VPN to the Internet through the Wi-Fi network of a cellular device.
is my understanding correct if your android device is connected to your regular home wifi (aka not using the cellular connection) - android is no different? pretty sure it is. which means the problem is within routers, not the OS of any actual “user” devices.
Since 2002? This is scary.
Next headline “UPNP only android is safe”
Android chads rise up
Operate and/or system
is my understanding correct if your android device is connected to your regular home wifi (aka not using the cellular connection) - android is no different?
No. Dumbing this down as much as I can, and leaving out a lot of specific gotchas for the rest of this post.
When any computer (…phone, whatever) wants to send a packet to the internet, it consults its routing table. The universal rule of routing tables is, “scan table for more specific route until you don’t find anything better”. (Better in this case being a more specific or higher priority route, in that order.) That’s the key to how this exploit operates.
Normally you connect to a network, and a DHCP server gives you an IP address and sends two things… A) a network definition that tells your computer what other computers it’s physically connected to. B) A default route through a gateway to the rest of the internet, also known as a route of last resort. i.e. “If you don’t find anything better, send it to this guy”. So when you’re on your home network, your routing table will be two routes, route one says anything you are physically connected to goes straight out your network card unmolested, and route two is the route of last resort
out the default gateway. Let’s call this point A.
So let’s say you want to send a packet someplace. Computer looks at the address you’re sending to, sees that you’re not directly connected with amazon, and sends that packet to its route of last resort, your default gateway (never to be thought about again, it’s been dealt with!).
Throwing some numbers on as an example, let’s say your computer is assigned 192.168.0.5 with a subnet mask of 255.255.255.0 and a default gateway of 192.168.0.1 . To your computer, that translates as “I’m directly connected to every IP that starts with 192.168.0 .” Now you want to send a packet to amazon, and let’s say (making numbers up here) that amazon’s IP address is 10.5.1.2 . Computer checks and you’re not directly connected to 10.5.1.2 (you’re connected to anything 192.168.0.x), and you don’t have any more specific routes so it sends your packet destined for 10.5.1.2 to 192.168.0.1 .
Now throw a VPN into the mix. (Completely ignoring split VPNs, that will really confuse the issue.)
You connect to the network, and your DHCP server sets what you’re directly connected to (192.168.0.x), and a default gateway of 192.168.0.1 . So far so good.
Then you fire up your VPN software, and it inserts another default route to the entire internet but with higher priority than the default gateway.
Remember the rule for all packets is you scan all your routes until you find the best (most specific or highest priority) route.
So now let’s go back to your packet you want to send to amazon (10.5.1.2). Computer checks, nope, you’re not directly connected to 10.5.1.2. Computer checks and it finds your default route. It then keeps looking and finds your VPN route for the entire internet with a higher priority than the default route, so sends your packet to your VPN program to package up and deal with.
Here’s where the exploit happens.
Go all the way back to point A. Nice simple network, I’m directly connected to 192.168.0.everything , and everything else goes to the default gateway.
But wait there’s more!! (Sorry, couldn’t help myself.) Now you have a bad guy somehow sending out DHCP packets. (Either they compromise your DHCP server, or they are in a race, or what-have-you.) This DHCP server, in addition to giving you your IP address, saying what you’re directly connected to, and setting a default route also sends two option 121s (that’s legal):
- If the IP address is 127 or below, send packet to BadGuyMachine 192.168.0.254
- If the IP address is 128 or above, send packet to BadGuyMachine 192.168.0.254
These two routes are exactly one bit more specific than your default gateway; exactly half the internet will go through the first route and half the internet will go through the second route. (More specific.) Let’s call this point B.
So now your routing table looks something like this:
-
I’m directly connected to 192.168.0.everything .
-
My default gateway for the entire internet is 192.168.0.1 .
-
My route for anything 127.x and below is 192.168.0.254, which I’m directly connected to.
-
My route for anything 128.x and above is 192.168.0.254, which I’m still directly connected to.
Now fire up your VPN software, and it inserts a higher priority default route. So now your routing table looks like this:
-
I’m directly connected to 192.168.0.everything .
-
My default gateway for the entire internet is 192.168.0.1 .
-
My higher priority default gateway for the entire internet is my VPN software.
-
My route for anything 127.x and below is 192.168.0.254, which I’m directly connected to.
-
My route for anything 128.x and above is 192.168.0.254, which I’m still directly connected to.
So now you want to send a packet to amazon, 10.5.1.2. Computer checks, nope, not directly connected to 10.5.1.2 . Computer sees your default route to the entire internet, good we have a way out. Computer keeps checking for more specific or higher priority routes. Computer sees higher priority VPN route for the entire internet, so that’s now the candidate for where this packet should go. Computer keeps checking for more specific or higher priority routes. Computer sees route for half the internet, anything 127 and below, and since half the internet is more specific than the entire internet, that’s the route it selects, bypassing your VPN software entirely.
So why isn’t android affected? Apparently Android doesn’t honor when a DHCP server sends option 121 and just flat ignores it. So back at point B when the bad guy DHCP server sends it two option 121 routes for half the internet each, Android pulls a middle finger and drops that information on the floor. So since the more-specific-route never gets inserted into the routing table, your VPN software’s higher priority default route still is the best route, and your VPN isn’t compromised.
No Android doesn’t support DHCP option 121. When they said Android was not effected by this they actually mean Android is not effected by this.
wow awesome response, thank you that actually helped me understand it a lot better. anyway so. i did a little info searching and found a few links
this starlink post from a few years ago mentioning they had implemented opt121
bug report to google referencing opt 121, discussion on hackernews about it
i actually have quite a few other questions related to this now but rather than ramble on (which i had done but deleted for both of our sakes lol), ill just leave it at that and say… interesting stuff. thanks again!
Great response to a legitimate question. Thanks.
thanks for the succinct answer lol. you cant blame me for wondering - as the other reply said, it is a “reasonable question” - because tech is complicated, and often tech journalism simplifies things so the average person can understand it… when often they dont actually understand it themselves. which means theres a lot of bad info. it is still complicated though, and reading the actual tech specs is… also complicated
Happy to help! You asked a reasonable question, thought it deserved my best shot at a reasonable answer.