Slashdot Mirror
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.'"
Does anyone feel that this is just publicizing what every GOOD developer has been saying for the last 10-15 years?
Disconnect and self-destruct, one bullet at a time.
"Microsoft responded with ActiveX, which bypasses security entirely by making it easy to blame the user for authorizing bad code to execute"
.NET is their response to Java (and, for all intents and purposes, .NET is miles ahead of anything MS has ever created in terms of security).
Uh, not quite. ActiveX was more a response to JavaScript/Flash/et al. Anything that created a lightweight web app.
Anything we do to improve software security must work without the programmer having to switch languages
I agree; it's not so much the language--or the tools--each developer on a project must be personally aware of vulnerabilities and exploits. Using "managed code" does not "secure" your projects. These days, a C programmer ignoring the dangers of gets(), for example, is incompetent and should not be trusted. It's not, as the article reads, "sloppy"... it's ignorance pure and simple.
Also, relying on tools like an updated gcc, gprof, or splint--helpful as they are--without experience and education in writing secure code... is asking for trouble also.
Sigs cause cancer.
I remember the bad ol' days when security was a matter of what you did or didn't do rather than what you didn't know was occurring without your knowledge!
Abstracting the user from programmatic events wasn't supposed to make your use of the computer a crap-shoot.
Mod me troll, if you must, I can't help it.
That's why OpenBSD's continuous code auditing makes for good security. Everything but the kitchen sink != better.
That all said, a sandbox environment allows the developer to make sloppy mistakes, not program better.
Trolling is a art,
The same is especially true in PHP. The short learning curve for getting started in the language allows for a great deal of insecure coding on the internet. I run a site that promotes secure programming, and is running a security challenge for writing scripts as well. The URL is http://www.uberhacker.com
When you're in college, the graders are not trying to break into your application, they're just evaluating the source code and give you points for correct stack and linked list implementation. Thus giving a false assurance that the real-world development is pretty much the same - friendly and non-threatening environment, no need to check and validate input, no need to resort to minimum security permissions and so on.
I think Caustictech said it better than I can:
a bad workman always blames his tools.
Drill baby drill - on Mars
Are you crazy?
Anyone who's worked on a software project of any size (especially in terms of number of people on the project) can tell you that the person who takes the official blame for a development flaw is almost never the person actually responsible for it.
Maybe if we had a programmers union and I could strike if I was ever asked to implement bad design or put out someone else's fire... maybe. But as things stand? You'd drive a lot of good developers out of the field because they're not skilled enough at office politicking to avoid being made scapegoats for the messes of others, and can't afford to bear the direct financial burden of it.
If you see a warning, get rid of it right away! Once you slack off a bit, it becomes like dirty dishes piling up in the kitchen sink. Nobody wants to touch them, and everybody feels like most of them are the other roommate's anyway.
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.
-
char s1[80];
...
which has a risk of buffer overflow, becomesvoid foo(char* out, char* in)
{ sprintf(s,"In = %s\n",in); }
-
char_string<80> s1;
...
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.void foo(char_string_base& s)
{ sprintf(s,"In = %s\n",in); }
The new "sprintf" is actually an overload on fixed_string.
"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?
Ummm gosh, the only ActiveX applets I ever saw was right after it was released. Heh, I often say Java is dead on the web (though I know it isn't completely) but now ActiveX is entirely dead except for like the applet on Windows Update :-P
You are a Holy Person, sir/madam.
Go find some pr0n and you'll see a lot of activeX thingies trying to install. Lucky me I use Moz.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
..and there he said it was (paraphrasing here) common for programmers to sorta ignore error flags and just code out the warnings about memory leaks and arcane whatnot like that, like that made the problem "fixed". No warnings-no problems! On to the next project.....
probably more stuff too, that's all I read though.....
Not a coder here, so I have *no* idea if this is common or not, or true or not, but I *have* noticed on slashdot NO ONE writes bad code,or has written bad code, or thought about bad code, and *everyone* has personally corrected every other coder they ever met on their code, and no one has ever had a boss who knew what he was doing or could read so much as a grocery list without speaking the big words out loud, and only the *other guys* someplace else write bad code, and they always use the wrong language and editor to boot, like on bizarro dotslash forum or something. It's ALL "their" fault that there's ANY of this alleged "bad code" that causes buffer overflows and like acne and flat tires and girls who say no.. Them dang guys "over there", buncha no-good slackers....let's hang 'em!
Actually, you can continue to use C/C++ and just use a garbage collector with them. I don't know why more people don't do this. You don't even need to change your code, as Boehm's garbage collector translates malloc() to it's own allocation routine, and free() does nothing.
In fact, even better, if you have Boehm GC installed anywhere on your system you can do this for already compiled programs using LD_PRELOAD.
Just do:
export LD_PRELOAD=/path/to/libgc.so
/path/to/program
and I'm automagically using a garbage-collected runtime for the program, even if it was compiled to use the standard malloc()/free() calls.
Engineering and the Ultimate