Blame Bad Security on Sloppy Programming

CowboyRobot writes "ACM Queue has an article that blames security flaws on poor programming, rather than any inherent problems with particular languages. From the article: 'Remember Ada? ... we tried getting everyone to switch to a 'sandboxed' environment with Java in the late 1990s... Java worked so well, Microsoft responded with ActiveX, which bypasses security entirely by making it easy to blame the user for authorizing bad code to execute.'"

Comments

Re:ActiveX a response to Java?

[StephenLegge]

I think the writer meant ActiveX was Microsoft's response to Java *Applets*.

Java Applets had a well-defined and flexible security API that provided fine-grained set of privaleges for what an Applet could do on the user's system.

To combat Applets, Microsoft implemented ActiveX with brain-dead all-or-nothing approach that is still used today ("Do you want to trust whoever wrote this to do anything they want to your system? Yes / No"). Then Microsoft forced Java Applets to work the same brain-dead all-or-nothing way in IE.

SLL

Ada's strengths, Ada's problems

[Anonymous Coward]

Ada as a language roughly equivalent to C++ in form and expressiveness. Ada goes beyond C++ in that it allows one to more tightly specify constraints on data and to have these constraints automatically checked and enforced. That is the basic strength of Ada.

The weakness of Ada is its woefully outdated standard libraries which are more oriented to a 1960s mainframe view of the world. There are no containers, no STL, no general algorithms. That is the weakness of Ada.

If Ada had the powerful standard libraries which C++ has, that combined the safety of Ada would make it a first choice for many programming tasks. Ada can still deliver on bug free programming. But it lacks the scaffolding needed for 21st century projects.

Boost is working on a replacement for C strings

[Animats]

Over in the Boost sandbox, some of us are working on C++ classes to replace C strings in existing code. The usual C string operations (sprintf, strcat) work, but they're all protected against overflow. The idea is that you replace just the declarations, and the code either becomes safe or won't compile. So

• char s1[80];
  ...
  void foo(char* out, char* in)
  { sprintf(s,"In = %s\n",in); }
  

which has a risk of buffer overflow, becomes

• char_string<80> s1;
  ...
  void foo(char_string_base& s)
  { sprintf(s,"In = %s\n",in); }
  

which will truncate the string at the specified length. Note that the "sprintf" line hasn't changed. So you don't have to rewrite complex formatting code. Changing the declarations does the job.

The new "sprintf" is actually an overload on fixed_string.

The author simply doesn't get it

[javajedi]

"We need to be realistic in recognizing that we're stuck with a set of languages and environments that are not susceptible to a massive change."
This is a huge cop-out. Buffer overflows simply can not happen in Java. The same goes for almost all of the security problems that are turned into exploits these days. Instead of applying patches to compilers and yelling at ignorant developers, how about just switching to a development language and runtime environment (e.g. Java and its Virtual Machine) that simply doesn't allow these kinds of mistakes to be made?