Software Flaw Puts Mobile Phones and Networks At Risk Of Complete Takeover (arstechnica.com)

← Back to Stories (view on slashdot.org)

Software Flaw Puts Mobile Phones and Networks At Risk Of Complete Takeover (arstechnica.com)

Posted by msmash on Wednesday July 20, 2016 @04:45AM from the security-woes dept.

Dan Goodin, reporting for Ars Technica: A newly disclosed vulnerability could allow attackers to seize control of mobile phones and key parts of the world's telecommunications infrastructure and make it possible to eavesdrop or disrupt entire networks, security experts warned Tuesday. The bug resides in a code library used in a wide range of telecommunication products, including radios in cell towers, routers, and switches, as well as the baseband chips in individual phones. Although exploiting the heap overflow vulnerability would require great skill and resources, attackers who managed to succeed would have the ability to execute malicious code on virtually all of those devices. The code library was developed by Pennsylvania-based Objective Systems and is used to implement a telephony standard known as ASN.1, short for Abstract Syntax Notation One."The vulnerability could be triggered remotely without any authentication in scenarios where the vulnerable code receives and processes ASN.1 encoded data from untrusted sources," researchers who discovered the flaw wrote in an advisory published Monday evening. "These may include communications between mobile devices and telecommunication network infrastructure nodes, communications between nodes in a carrier's network or across carrier boundaries, or communication between mutually untrusted endpoints in a data network."

52 comments

Min score:

Reason:

Sort:

Yet again.. by Anonymous Coward · 2016-07-20 04:47 · Score: -1, Troll

Yet again..ASN.1 rears it's head.
1. Re:Yet again.. by MindStalker · 2016-07-20 05:01 · Score: 1
  
  First I've heard.
2. Re:Yet again.. by ScentCone · 2016-07-20 05:04 · Score: 4, Funny
  
  Yet again..ASN.1 rears it's head.
  And the hackers are already using that vulnerability to insert random apostrophes into posts made from mobile devices.
  
  --
  Don't disappoint your bird dog. Go to the range.
3. Re:Yet again.. by Anonymous Coward · 2016-07-20 05:35 · Score: 0
  
  If we had unicode here, that apostrophe would be a virus.
4. Re:Yet again.. by Anonymous Coward · 2016-07-20 06:44 · Score: 1
  
  ASN.1 is quite complex, and quite more complex than it should be, because of a long history of committee-driven development. In particular, it includes a lot of distinct character string types for no apparent reasons, and its types to encode dates are remarkably inefficient and hard to handle (and one of them is subject to Y2K issues, currently scheduled for 2050). Faced with this complexity, developers often found attractive the idea of doing specialized decoding "just for certificates", in order to avoid the daunting task of implementing a generic and systematic decoder (in particular, it is possible but inconvenient to implement a full-featured generic ASN.1 decoder in languages such as C which lack automatic memory management, e.g. garbage collectors).
  Doing specialized code "by hand", to avoid the overhead of a systematic approach, means that the developer will need to think a lot more about possible issues when presented with "abnormal" data. This is a fertile ground for vulnerabilities (developers are only human, after all) and this is precisely what happened in OpenSSL.
I'm sure... by Anonymous Coward · 2016-07-20 04:48 · Score: -1

I'm sure this is all Obama's fault.
1. Re:I'm sure... by Anonymous Coward · 2016-07-20 05:03 · Score: -1
  
  This is not a "flaw" it is part of the NSA toolkit.
2. Re: I'm sure... by Anonymous Coward · 2016-07-20 05:28 · Score: 0
  
  Donald will fix it. He'll regulate the telecoms back to the fifties, when everything was Great.
3. Re:I'm sure... by PPH · 2016-07-20 05:28 · Score: 1
  
  Obama's fault
  Yes and no. ASN.1 predates his term in office. But his grant of retroactive immunity to the telecoms just perpetuates this sort of dirty dealing. A standards-making body might try to demand that participants declare their interests in patents or government espionage units. But if they have a 'get out of jail free' card from him, they can say or hide anything they want.
  
  --
  Have gnu, will travel.
4. Re:I'm sure... by Aaden42 · 2016-07-20 05:33 · Score: 1
  
  I wonder how far we are from a point when patching a vulnerability (that NSA, etc. depend on) will be prosecuted as an act of war/terrorism/think of the children/whatever irrational fear we're rallying against this week.
5. Re: I'm sure... by Anonymous Coward · 2016-07-20 06:11 · Score: 0
  
  Donald will fix it. He'll regulate the telecoms back to the fifties, when everything was Great.
  It will be "fixed" before he gets in office.
  It's revealed now so the NSA (ASN backwards!) backdoors can't be used by enemies of the left.
  This is a clear sign the left knows they are going to lose in November.
Not surprised it is in ASN.1 by Anonymous Coward · 2016-07-20 04:48 · Score: -1

ASN.1 is a mental masutrbation-fest.
1. Re:Not surprised it is in ASN.1 by Anonymous Coward · 2016-07-20 13:32 · Score: 0
  
  "ASN.1 is a mental masutrbation-fest."
  MasUTRbation? That's what happens when you try to type with the wrong hand because the other's (getting) busy.
Yay for Open Standards! by TechyImmigrant · 2016-07-20 04:59 · Score: 4, Insightful

I've done my bit to try to eradicate ASN.1 from standards I work on. But there's always 2 or 3 vocal people going to great lengths to keep it in there. It's become more clear over time that they don't only work for their stated employers.

--
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
1. Re:Yay for Open Standards! by Anonymous Coward · 2016-07-20 05:08 · Score: 4, Insightful
  
  Or they don't want to break everything by removing support for ASN.1.
  But the open source community has never been on for maintaining compatibility, so it's understandable
2. Re:Yay for Open Standards! by Anonymous Coward · 2016-07-20 05:15 · Score: 0
  
  I think you meant to type "one" instead of "on".
  Your entire argument is now invalid because your typo has been exposed. *smug*
3. Re:Yay for Open Standards! by dgatwood · 2016-07-20 05:20 · Score: 0
  
  Yeah, it's baffling how many security people seem to like ASN.1 as a means of encoding various cryptographic data. It's an awful format. It isn't human-readable, and the parser is fairly complex, which means that creating one is likely error-prone.
  
  --
  Check out my sci-fi/humor trilogy at PatriotsBooks.
4. Re:Yay for Open Standards! by dgatwood · 2016-07-20 05:21 · Score: 1
  
  Oh, and it is used exclusively in a few niche technologies, which means the odds of bugs getting found and fixed are relatively small.
  
  --
  Check out my sci-fi/humor trilogy at PatriotsBooks.
5. Re:Yay for Open Standards! by TechyImmigrant · 2016-07-20 05:22 · Score: 3, Informative
  
  >Or they don't want to break everything by removing support for ASN.1.
  Clean sheet specs for security systems. There's nothing to break. Adopting ASN.1 based technologies is a poor compromise because is undermined the purpose of the spec. See TFA for an example of how this works.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
6. Re:Yay for Open Standards! by Anonymous Coward · 2016-07-20 05:29 · Score: 0
  
  Plus he missed a period at the end of his last sentence. What a looser!
7. Re:Yay for Open Standards! by Anonymous Coward · 2016-07-20 05:41 · Score: 1
  
  Get rid of ASN.1 ?? Heaven forbid we have a standard that explicitly states the sizes of fields and makes it easy for computers to tokenize data. I want more html and human readable text standards so I can worry every night about cross-site scripting and other vulnerabilities they cause.
  Some of us old people actually want to have some fighting chance to make our systems secure.
8. Re:Yay for Open Standards! by Anonymous Coward · 2016-07-20 05:44 · Score: 0
  
  Then AC must be a "she" not a "he"
9. Re: Yay for Open Standards! by Anonymous Coward · 2016-07-20 06:00 · Score: 0
  
  So you are rallying around ASN.1, which has been proven to not be so secure over the years.
10. Re:Yay for Open Standards! by Anonymous Coward · 2016-07-20 06:18 · Score: 0
  
  You'd be more successful if you tried to achieve that with something less shit than ASN.1.
  Though this particular fault is a typical "forgot integer overflow check before malloc".
  If you haven't eradicated those systematically, your processes are bad enough that you'd probably have security holes no matter the standard you implement.
11. Re:Yay for Open Standards! by umghhh · 2016-07-20 06:28 · Score: 2
  
  If I understand this correctly you blame the encoding standard which may or not be useful in some applications for faults in a library?
  What I found really bad is that somebody modded you into insightful for expressing this silliness.
12. Re: Yay for Open Standards! by umghhh · 2016-07-20 06:32 · Score: 1
  
  You mean ANS1 is/was used because of security?
13. Re:Yay for Open Standards! by TroII · 2016-07-20 06:49 · Score: 1
  
  I can't tell whether you're being sarcastic or what, but obscurity is not security; quite the contrary, it reduces the likelihood that a bug or backdoor, if there, will ever be found. Human-readable protocols are good.
  
  --
  "If there was a gay Afro-Puertorican Linux distribution, I'd give it a try" ~lucm
14. Re:Yay for Open Standards! by Anonymous Coward · 2016-07-20 06:51 · Score: 0
  
  This is the exact sort of heterocentric comment which creates a hostile work environment for men with loose assholes!
15. Re:Yay for Open Standards! by Anonymous Coward · 2016-07-20 06:55 · Score: 1
  
  ASN.1 is just a notation standard, not unlike BNF. It's the code generator that parses ASN.1 that has a problem.
16. Re:Yay for Open Standards! by Anonymous Coward · 2016-07-20 15:53 · Score: 0
  
  "But the open source community has never been on for maintaining compatibility, so it's understandable..."
  bullshit
  The open source community had been the only one maintaining compatibility and standards! There are large software companies (Bikerosoft comes to mind) that *ISN"T EVEN COMPATIBLE WITH PREVIOUS VERSIONS OF ITS OWN SOFTWARE!!!* let alone anyone else's. So we slam the lid down on that steaming pile. As for this vulnerable software, the hole gets closed, and the NSA needs to go to the next best way to read all and sundry.
17. Re: Yay for Open Standards! by TechyImmigrant · 2016-07-21 02:58 · Score: 1
  
  You mean ANS1 is/was used because of security?
  It's the encoding for X.509 certificates.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
18. Re:Yay for Open Standards! by TechyImmigrant · 2016-07-21 02:59 · Score: 1
  
  You'd be more successful if you tried to achieve that with something less shit than ASN.1.
  Though this particular fault is a typical "forgot integer overflow check before malloc".
  If you haven't eradicated those systematically, your processes are bad enough that you'd probably have security holes no matter the standard you implement.
  If you knew how big things would be at the start, you would need to be mallocing as TLVs come in.
  This is one of the many reasons that ASN.1 is bad.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
19. Re:Yay for Open Standards! by TechyImmigrant · 2016-07-21 03:04 · Score: 1
  
  If I understand this correctly you blame the encoding standard which may or not be useful in some applications for faults in a library?
  What I found really bad is that somebody modded you into insightful for expressing this silliness.
  Yes I did. This is because the ASN.1 encoding standard is and has been shown to be exactly the sort of format that is hard to implement parsers for correctly and securely. Worse, it doesn't need to be that way in most of the places it is used. It is used in protocols that are typically throwing around fixed size fields. But you have to specify the size of the field in the data and a parser has to read it and trust the input and set aside memory on the fly as the data comes in and declares itself to be of whatever size.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
20. Re:Yay for Open Standards! by dgatwood · 2016-07-21 03:36 · Score: 1
  
  Not sure how this changes the facts—that ASN.1 is a niche language used in a few narrow areas, that it doesn't get a lot of attention because only a tiny percentage of engineers understand or use it, and that we'd all be better off if everyone just used more sensible data formats, such as JSON, XML property lists, or any number of other similar formats that are well understood, broadly used, and thus thoroughly debugged. The same is true for all the usual binary formats that people define using ASN.1 (BER, DER, etc.), but doubly true for the ASN.1 format itself.
  If they're really passing the actual ASN.1 syntax data around over an insecure channel and providing a compiler that compiles the abstract syntax into a new parser to parse a data stream... that's just a recipe for failure in every possible way. Such a design means taking ASN.1 compiler code that most people assume will be used only by software engineers in a controlled setting, and deploying it in such a way that communication equipment all around the world has to use it on the fly to create executable code and run it. Such a design precludes code signing, because the device has to be able to run unsigned, freshly generated parser code derived from the ASN.1. This means that the security of the device is weakened fundamentally, and any security holes in either the ASN.1 compiler or in the resulting parsers are likely to be easier to exploit as a result.
  More importantly, it means that arbitrary third parties can create parsers and then provide incompatible data to feed to those parsers, maximizing the chances that there will be an exploitable bug in those parsers that can result in privilege escalation.
  ASN.1 should die already, and so should all of the various binary encodings derived from it. IMO, they're fundamentally bad for security, they're hard to audit, and when used in dangerous ways like this, they represent a major security risk.
  
  --
  Check out my sci-fi/humor trilogy at PatriotsBooks.
21. Re:Yay for Open Standards! by Anonymous Coward · 2016-08-01 22:09 · Score: 0
  
  Funny that - I used it only in protocols where the fields were of different sizes. Granted there are other solutions - whether they are better I am not sure. Parsers are difficult - any SW that is well written is difficult. This is sometimes not visible from reading the code but it is so. The argument that you can make faults while implementing it I do not buy - the software can have faults, design techniques are there to prevent most and QA to find most of the rest. There is no such thing as faultless software. Go suck it if you cannot live with it.
Government can do what it always does by Lead+Butthead · 2016-07-20 05:10 · Score: 1

Outlaw revealing of information related to design and vulnerabilities, and declare victory.
This is what happens when the lawmakers we got are stuck in the mindset of 1950s.

--
ELOI, ELOI, LAMA SABACHTHANI!?
Untrusted sources by willoughby · 2016-07-20 05:31 · Score: 3, Insightful

So... could the Feds use a Stingray to distribute this to a targeted phone?
1. Re:Untrusted sources by FeelGood314 · 2016-07-20 05:43 · Score: 3, Interesting
  
  Get rid of ASN.1 ?? Heaven forbid we have a standard that explicitly states the sizes of fields and makes it easy for computers to tokenize data. I want more html and human readable text standards so I can worry every night about cross-site scripting and other vulnerabilities they cause.
  Some of us old people actually want to have some fighting chance to make our systems secure.
2. Re:Untrusted sources by Anonymous Coward · 2016-07-20 06:07 · Score: 0
  
  Your brush is a bit broad, good sir. html and xml and such are pretty broken, yes. But it's not exactly difficult to write a format that's both reasonably human-readable (the various kinds of "tag soup" don't count, nor does, say, json) and reasonably secure. It does require knowing what you're doing, exactly the trait for which xml sought to obviate the need. That resulted in lots of security and encoding trouble and, ultimately, json.
3. Re:Untrusted sources by t8z5h3 · 2016-07-20 06:26 · Score: 1
  
  html and xml Broken? really? come on both are really solid for what they are built for (reconstruction of a website on a client computer) mine you they where never designed to be secure but thought other tech (ssl and certs) it was able to live with in a security minded world. but i am also excluding plugin's like flash and java.
4. Re:Untrusted sources by t8z5h3 · 2016-07-20 06:29 · Score: 1
  
  unknown but it maybe why yesterday the government was moving from android to Apple IOS.
5. Re:Untrusted sources by Anonymous Coward · 2016-07-20 07:35 · Score: 0
  
  Yes, really. No, they're not remotely "solid". Also, mind your grammar.
6. Re:Untrusted sources by Anonymous Coward · 2016-07-20 08:31 · Score: 0
  
  Grammar is broken, so you off fuck.
7. Re:Untrusted sources by Anonymous Coward · 2016-07-21 01:36 · Score: 0
  
  I'm more interested in the exploits going the other way. Using a phone to pwn the cell node and/or network.
ASN.1 is not the source of the bug. by Anonymous Coward · 2016-07-20 07:05 · Score: 0

The bug is with a commonly used third party library that implements ASN.1, it has nothing to do with the ASN.1 standard itself. Your solution is for everyone to stop using SSL/TLS because of bugs with OpenSSL?
1. Re:ASN.1 is not the source of the bug. by TechyImmigrant · 2016-07-20 09:33 · Score: 1
  
  The bug is with a commonly used third party library that implements ASN.1, it has nothing to do with the ASN.1 standard itself. Your solution is for everyone to stop using SSL/TLS because of bugs with OpenSSL?
  OpenSSL had it's own ASN.1 bugs.
  It is in the nature of ASN.1 that is it hard to implement correctly and securely, yet it is in products that face the outside world on wired and wireless networking equipment. It is a recipe for disaster. We should stop using SSL/TLS because it is built on ASN.1 and many other hard-to-implement technologies that has yielded and will continue to yield a constant dribble of security failures. They can be replaced with protocols that do not express basic formats with turing-complete languages for which the most security properties are formally undecidable.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Perish the thought! by Anonymous Coward · 2016-07-20 07:28 · Score: 1

Those who do not understand ASN1 are doomed to re-invent it. Poorly.
Look at abominations like binary xml.
1. Re:Perish the thought! by TechyImmigrant · 2016-07-20 11:02 · Score: 1
  
  Those who do not understand ASN1 are doomed to re-invent it. Poorly.
  Look at abominations like binary xml.
  Those who implement ASN.1 are doomed to introduce more critical security flaws into the world.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Could, might, possible, by Hylandr · 2016-07-20 08:48 · Score: 1

"They";
- Could,
- might,
- it's possible
Fuck off with the paranoia and prove it in the wild before more scare-mongering to make everyone buy new shit every few years. I am just so getting tired of it.

--
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
Same bug as Project Aurora? by Anonymous Coward · 2016-07-20 11:04 · Score: 0

Anyone know?
Heap memory corruption in Windows ASN.1 library by khz6955 · 2016-07-20 13:49 · Score: 1

This flaw resides in a version of the library implemented on a specific platform, namely Windows running on x86 hardware. Makes a good case for not running your infrastructure on a software monoculture. This isn't the first such discovery, see Microsoft ASN.1 Library Length Overflow Heap Corruption from July 2003.
Stupid fuckers. by Anonymous Coward · 2016-07-20 16:04 · Score: 0

If you stand next to an AC outlet it is plugged into it won't be at risk of complete takeover.
This is a bullshit story. How it really is, is all mobile networks are already spy networks. Every SMS, every voice call, and voice pattern, and web surfing, and email, and the rest are all tracked and stored along with GPS. GPS won't shut off like you think because it is there for E911 emergency services.
You people are some totally stupid fuckers with these stories.