Software Flaw Puts Mobile Phones and Networks At Risk Of Complete Takeover (arstechnica.com) 52
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."
Re: (Score:2)
First I've heard.
Government can do what it always does (Score:2)
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.
Re: (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
Re:Yet again.. (Score:5, 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.
Re: (Score:2)
Re: (Score:2)
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.
Yay for Open Standards! (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.
Re:Yay for Open Standards! (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
Re:Yay for Open Standards! (Score:4, 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.
Re: (Score:1)
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.
Re: (Score:2)
Oh, and it is used exclusively in a few niche technologies, which means the odds of bugs getting found and fixed are relatively small.
Re: (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.
Re: (Score:2)
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.
Re: (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.
Re: (Score:1)
Re: (Score:2)
You mean ANS1 is/was used because of security?
It's the encoding for X.509 certificates.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
What I found really bad is that somebody modded you into insightful for expressing this silliness.
Re: (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.
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 wh
Re: (Score:2)
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-comp
Perish the thought! (Score:1)
Those who do not understand ASN1 are doomed to re-invent it. Poorly.
Look at abominations like binary xml.
Re: (Score:2)
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.
Untrusted sources (Score:4, Insightful)
So... could the Feds use a Stingray to distribute this to a targeted phone?
Re: (Score:3, Interesting)
Some of us old people actually want to have some fighting chance to make our systems secure.
Re: (Score:1)
Re: (Score:1)
Could, might, possible, (Score:2)
"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.
Heap memory corruption in Windows ASN.1 library (Score:1)