Security flaws in Abstract Syntax Notation One (ASN.1)

Note that the vulnerability was discovered in June 2002!

The United Kingdom National Infrastructure Security Co-Ordination Centre revealed in Jan. 2004, “that it had discovered security flaws that affect the products of dozens of vendors. The flaws were found in software that support a variety of applications and technologies, including voice over IP, videoconferencing, text messaging, Session Initiation Protocol, devices and hardware, and critical networking equipment such as routers and firewalls.” …

“CIOs need to be aware that voice over IP creates exposure to vulnerabilities, says David Fraley, a principal analyst at Gartner Dataquest. "While there are very real and neat opportunities with VoIP, as convergence increases, the risks to attacks to these systems are going to increase," he says.

George V. Hulme, “H.323 Flaws Threaten Scores Of Products”, InformationWeek, January 15, 2004,
http://update.internetweek.com/cgi-bin4/DM/y/eer70Blkgg0V30CKN80Av Links to an external site.

Risks range from denial-of-service attacks to allowing access to malicious code. according to the

see http://www.cert.org/advisories/CA-2004-01.html#vendors Links to an external site.

Transcript

[slide383] Now, in H.323, many years ago, in 2004, there was a problem in the United Kingdom when someone realized that, oops, in this binary protocol, which was widely used in IP telephones inside the government, there was a flaw. That if you sent a malformed H.323 request, you could make the IP telephone misbehave. In particular, you could make it, yes, activate the microphone and now stream media content to you. And this was a really very big shock because these were used in places like the Ministry of Defense and other parts of the government. And the really bad problem was that it turned out because H.323 is this binary protocol, you need, of course, a state machine to parse the messages. It's very hard implementing that state machine. So what did most companies do? Yes, they bought a library from a company that had implemented this. Unfortunately, almost every vendor had bought their library from the same company. So a huge number of products from lots of different vendors were all affected by the same flaw. And you say, well, how hard could it be to implement this? Well, I had a bachelor's student a number of years ago who worked for about 10 weeks trying to implement an H.323 parser by hand, working from the standard specification and the state diagram. And I said to him when he began, don't do this by hand. Use code generators. LEX and YACC. Build a tool that will take the description and now write the code for you. Which then he proceeded to do and it took him two weeks to do that. But most people built these hand-implemented H.323 parsers. It's really really hard to do it. The other problem is denial of service. If you send the right malformed packets in, yes, you can make it so that they can't make any calls at all. Which isn't good.