What is the excuse for writing business-critical software in unmanaged languages?

I would say the 2nd bug would be the most serious. Anyone who is able to make unauthenticated calls could certainly make it a very expensive bug to exploit.

Buffer overflows have been around forever as a vulnerability. Surely they would be part of some basic audit process?

I'm not a programmer so I'm slathering on the barbecue sauce in preparation for the flames.

Most stuff is in C, C++, C#, VB.

Ada and Modula-2 can be used simply to write programs immune to these tricks, but the success of Linux/Unix & Windows has made the C family too popular and held back IT by 20 years at least.

And to think that the Western World keep pointing fingers at the Chinese for shoddy workmanship !! I thought "Buffer overflows" were beaten out of young programmers in my time (>30 years ago) !! "Test, test and test again to destruction" was the litany in those days !! One didn't get to go home unless the damn thing could stand up to all possible conditions !!

I blame the dot,com bubble for generating extravagant expectations in the IT industry in return for shoddy workmanship !! There's no longer any pride in doing a good job. Just pure greed !!

SIP was designed to be very flexible, and can handle much more than just voice.

In theory it's a great protocol, as the actual RTP data traffic only needs to travel between active parties, and not through a central server as required by other protocols (IAX). in practice SIP has alot of faults.

In practice SIP fails to function natively with the most popular/common NAT routers found in homes.

This is due to SIP/RTP's need for a huge range of incoming ports needed. Some applications can attempt to use an external STUN service (which is not a SIP protocol standard) to learn external IP addresses and ports, but this isn't 100% reliable even when configured properly.

More likely someone needs to configure the router to map ports internally. Even this isn't strait forward because the SIP packets themselves need to contain the public ip&ports, which will not match the ip&ports the device is using internally, so sometimes the public IP address is statically configured in the VOIP device. Alternatively the other end often ignores the IP address in the data portion of the SIP packet, and use the IP address from the IP stack, thus reducing the original flexibility SIP was designed to offer.

SIP is transmitted in plain text, which is bad for security, and consumes more bandwidth.

All these complexities make it difficult to roll out SIP securely as many are simply added to the router's DMZ.

There is no question about it, SIP will be the target of numerous attacks once hackers become motivated.

As much as I like to support open protocols, I think SIP users will continue to suffer from it's design problems.

It was about 25 years ago that I learned to program and it was simple common sense (as well as good practice) that if you had a buffer that takes up to 128 characters, you checked the data that was coming into it to ensure that its length was less than or equal to 128.

If it was longer, you truncated it or kicked it back with an error.

When did this cease being the case?

If you have a look at the architecture and coding you will see that asterisk is not typical of IP PBX software.

Starting with the architecture, it is not designed for large scale business use. It has basic limitations on call volume because it routes all calls through itself either in B2BUA mode with SIP or in translation mode between say a SIP call and a digium adapter.

The whole design of Asterisk started out as a piece of software to handle FXO/FXS cards and do basic PBX stuff for a small office. It has growed somewhat since then and has plug-ins for every possible protocol and service. Its architecture really is not suited to large businesses or for use as a public IP telephony provider.

When you look at the code underneath you can see it has evolved 'like topsy' as well. In some ways I am very surprised that multiple vulnerabilities aren't discovered daily.

Now if you want to get into serious IP PBX, look no further than SER or SIPX-PBX. SER is used in massive commercial deployments, as is SIPXPBX (in commercial form). A break of one of these systems would be much more interesting. Especially SIPXPBX which seems to have very little maintenance and development other than some audio subsystem tweaks.

Probably easier to break is the fork openSER which goes through rapid cycles of development. It is not, to my knowledge used in major commercial deployments.

For the commercial systems, obviously CISCO, but their focus is on their own non-SIP format. Broadcom/Broadsoft is also pretty big in the SIP area and a break of their system would be of interest.

The rest - to my limited understanding - are a hotchpotch of proprietary digital systems eg NEC and Siemens. They sell a lot of kit but whether cracking them is worthwhile is open for discussion.

These things still happen today because :

1) managers view IT as a cost center, and any cost must be stamped on as hard as possible

2) managers today deem themselves able to program because they've written a few Excel macros, thus validating the "simply magical" idea Joe Public has ever had on how computers work, ergo whatever programming needed should be done by tomorrow morning because it's easy

3) security is a word that managers have never lookup up in a dictionary - along with maintainable, resilient and long-term

4) because of the three previous points, developers are always on a shoestring budget with very, very short deadlines, and testing is just confirming that the code you wrote does what you think it is supposed to do with the generic data you prepared for it

5) not to mention that not all developers have been properly trained on the language they are to use for the project (if at all)

6) the maintenance budget and the bug fixing budget are not the same as the development budget - sometimes even the managers are different (that should be referred to as "passing the buck beforehand")

I hope that clears that argument up. :-)

- The rest - to my limited understanding - are a hotchpotch of proprietary digital systems eg NEC and Siemens. They sell a lot of kit but whether cracking them is worthwhile is open for discussion.

I would say most installed systems are proprietary digital systems. I really don't think there are *that* many new VOIP systems in use. I'd question how possible it is to crack our existing switches.

Seeing as you can't even send data to it without an ISDN modem (and ISDN line) telephone number for remote and the user/pass I think that its secured quite nicely. Simply needing an IDSN modem rules out an awful lot of people that could attack the system. There is *no way* to actually send any other data to the system. And ignoring that its not possible for a few moments, an ISDN line is kind of static. If my system gets attacked from a fixed ISDN line then it kind of gives away the identity of the attacker.

"if you had a buffer that takes up to 128 characters, you checked the data that was coming into it to ensure that its length was less than or equal to 128 .. If it was longer, you truncated it or kicked it back with an error .. When did this cease being the case?", Graham Marsden

When they started producing 'programmers' that never saw a line of code only a form that you dragged and dropped widgets onto. That and a CPU/MMU that didn't prevent 'buffer overflows'. Just how difficult is it to make a MMU that fails safe if the app tries to write past the 128 character buffer?

Why are people still using functions like strcpy to copy data? I was taught 20 years ago never to use it and to always use strncpy limited to sizeof(buffer). It's just common sense unless you know you generated the data yourself and even then that's risky.

If I was running a development project I would give consideration to removing such functions from the header files so people couldn't use them.