How to slay a cellphone with a single text Attacks that crash most older cellphones are frequently compounded by carrier networks that send booby-trapped text messages to the target handset over and over. In other cases, they're aided by a “watchdog” feature embedded in the phone, which takes it offline after receiving just three of the malformed messages. The so-called …
because the phone manufacturers will never bother fixing the bug ... why should they? This works to their advantage because most people in the US will just buy a new phone and "renew" their plan for two more years ... so bugs like this work to the networks advantage.
It fact, if I was running a network I'd require that bugs like this are included in the phone.
The older Sony Ericsson and Siemens phones were a doddle to crash - they used to allow you to insert pictures and sounds into normal text messages which were in reality simple placeholders like: "%SND04" which the receiving phone would simply substitute with whatever soundfile was sitting at index 04.
Unfortunately for some strange reason the phone didn't seem to check if it actually had a picture or soundfile at the index specified and went off to fetch it anyway, but in the event the file did not exist - it never returned from it's fetching routine. The slightly better phones would allow you to recover from the situation by restarting the phone and deleting the offending message. Unfortunately the earlier models used to only offer the option to delete the message AFTER opening and scrolling down the bottom of the message.
The funny thing about it all was though - when you inserted the built in picture or sound into your message it didn't actually add it to the message - just it's placeholder - which ANYONE could change, and as the range for sounds was something like 1-9 and pictures 1-20 then anyone who was just the tiniest bit curious could crash someones phone without even intending to.
a few pennies.
No one was suggesting that attackers would have any desire to indiscriminately crash thousands of phones. An attacker would need to have a specific victim, their mobile number, and the knowledge that their phone is vulnerable in the first place.
You'd almost be better off running up and grabbing the phone off them, but if you are particularly passive-aggressive, you can now do it via SMS.
Advertising, yet again, is at the root of this problem. I've long thought that GSM should have had a means to disable the sending of SMS to the handset. To those of us who don't use SMS, this would be a killer feature. That it doesn't tells you all you really need to know.
... of another platform that allowed chat straight in the console, so anyone sending "quit" or "rm -r" or "format c:" or anything in that range would cause the device to somersault from a 20-story building head-first onto a concrete slab.
Yes, forcing the network to do packet filtering would be the Right Thing, but could it be possibly be done, on, lets say the interwebs itself, regarding every single malformed IP packet? Just a comparison for Inquiring Minds...
"Yes, forcing the network to do packet filtering would be the Right Thing, but could it be possibly be done, on, lets say the interwebs itself, regarding every single malformed IP packet?"
Yes. Any sysadmin worth his salt in the corporate market does this at least at the gateway level. A mid-ranged Juniper SSG firewall is little more than £2k, has packet screening, can do network level AV and a real sys admin will be blocking all traffic other than what's authorised in BOTH directions.
Think those, and most SME boxes upwards can also do IDS ONTOP of basic packet screening.
It's not expensive, and it's not hard to implement.
1) Crash someone's phone
2) ?????
3) Profit!!!!
Why would a criminal want to crash your phone other than being annoying? Would this be done en-mass by rival manufacturers to boost sales of their devices. If i were a criminal looking to use this for fun and profit I would want some way of rooting the target phone, so i can use it as a relay for spam or any of the other reasons the botnets exist.
At those who question if the carriers filter these, who knows? The researchers ran their own private SMSC and cell site inside a farrady cage for their tests. I could see equipment dropping the ones that crashed the phone by for instance claiming 10 segments when there are really 7 (since a cursory inspection indicates they are corrupted).. On the other hand, if the "outer envelope" of the text is structurally sound I wouldn't expect the equipment to look at content.
As a bad analogy, I expect most ISPs will drop corrupted packets, and drop "bogons" (packets that "got out" to begin wtih due to misconfiguration, like 127.0.0.1 or 192.168.0.x or the like) and drop corrupted packets (bad checksum). I *wouldn't* expect them as a matter of course to inspect packets for virus or malware payloads.
As for smartphones being less susceptible -- I don't think it's because they use both a baseband and service CPU (as opposed to simpler phones using the "baseband" CPU to run the whole show.) I think it's because smartphone OSes have memory protection and multitasking (instead of cooperative task switching*). So the text handler can never overwrite another area of the phone, and if it locks up it doesn't lock the phone. A daemon could watch for hung things like the text handler, and automatically kill the hung one and restart a clean copy. The watchdog counts down from (for instance) 10 seconds; a healthy phone resets the watchdog back to 10 seconds frequently, a hung phone the watchdog resets the phone when the countdown reaches 0.
*With multitasking, the OS runs an app for one timeslice (often 1/100th of a second), and when that 1/100th of a second is up the system stops that app dead in it's tracks and goes to the next one. Cooperative task switching was improperly called multitasking by both Microsoft (pre-Win95) and Apple (pre-OSX), an app runs until it says it's done running. Yes, that means if an app gets stuck in a loop or locks up for any reason, the entire system locks up.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
