The upcoming security fight

Posted Nov 13, 2003 9:39 UTC (Thu) by brouhaha (subscriber, #1698)
In reply to: The upcoming security fight by ken
Parent article: The upcoming security fight

One of the best ways to "write secure c/c++ with open source tools" is to ditch C/C++ entirely and use a language that actually tries to promote reliable software. It's certainly possible to write secure code in C or C++, but it's way too much work, so it almost never is done in practice.

Some languages I recommend for this are Ada, Eiffel, Java, Modula 3, Python, Sather, Scheme, or Smalltalk. Ada, Eiffel, Modula 3, and Sather generally have little or no performance penalty compared to C or C++. That's true of Java as well, if it's compiled to native code.

C and C++ are like table saws missing their finger guards. If you're careful you can get away with it for a while, but it's eventually going to cause you a problem.

The upcoming security fight

Posted Nov 13, 2003 10:18 UTC (Thu) by jonth (guest, #4008) [Link] (1 responses)

And while we're at it, let's all speak Esperanto - English is inherently irregular, open to misunderstanding and difficult to learn. Look how easily lawyers can twist English to their own ends: it must be bad ;-)

I write low level software for very small embedded systems (mobile phones, to be precise); for the time being there is no alternative to C as an efficient, highly portable high level language for these devices. It is the lingua franca of the low level computing world: it's the first compilable language made available for almost every new processor. For anything that gets reasonably close to hardware, there just isn't any choice to C. (Even C++ is a stretch too far in this case.) Java for a device driver? Don't make me laugh.

The Linux kernel is itself written in C, and it's pretty secure. It's not perfect (nothing is), but for something that complicated, it's damn good. It got that way not because of the language in which it's written, but the process by which it's written. Trusting a language to be "inherently secure" is damn dangerous. Ask any Java developer.

cheers,

Jonth

The upcoming security fight

Posted Nov 14, 2003 2:29 UTC (Fri) by brouhaha (subscriber, #1698) [Link]

I respectfully disagree. I have written code in Ada and Modula 3 for small embedded systems, and it worked just fine. I didn't find any area in which they were deficient as compared to C. But the compiler was able to catch errors that would only have been found at runtime if I'd used C instead.

I also develop for Microchip PIC processors, and for those, I use assembly language, because even C isn't a good fit for them, though the newer PIC18 architecture is somewhat better suited to C.

Trusting a language to be "inherently secure" is damn dangerous.

I never said that you should trust a language to be inherently secure. Just because a table saw has a finger guard, you don't trust it to be perfectly safe. You still use it cautiously. That doesn't mean that a finger guard is useless.

The upcoming security fight

Posted Nov 13, 2003 13:22 UTC (Thu) by rmstar (guest, #3672) [Link] (1 responses)

You are completely right.

How many large security holes could have been avoided, for instance, if strings and arrays were propperly bound-checked? Certainly thousands. How many if assignment were not allowed in conditional clauses? etc.

C/C++ are error prone, and thus insecure, in every respect. From memory management all the way to their insane and barroque syntax.

Regards,
rmstar

The upcoming security fight

Posted Nov 13, 2003 18:00 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

You confuse C and C++. C++ has a standard string class that is properly bounds checked, and a standard vector class that can grow to unlimited size. However, too many C++ programmers are really C programmers and use the C mechanisms that they are more familiar with, instead of the safer classes that take care of memory management properly.

secure programming languages

Posted Nov 13, 2003 17:10 UTC (Thu) by zooko (guest, #2589) [Link]

The E language has been carefully engineered through and through to maximize security. It also features the unification of object-oriented programming and capability-security programming, which is a really neat idea.