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,
Okay, it's the happy-fun Slashdot thing to talk about how retraded 'lusers' are. Almost as hi-larious as jokes about Clippy and rebooting Windoze machines.
But you know what?
Most developers are retraded too.
This probably includes you, my friend, as you read it in your grease-stained Manga t-shirt. This is not a problem that will be solved by yelling at people about bad code - they're going to produce it anyways, and in droves. The solution to dumb users is good UI design and a sensible permissions architecture. Similarly, the only workable solution to this problem is architectural.
Google confirms: Ruby is the world's most beloved programm
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.
I'm glad someone other than me (who can get published on a site slashdot will link to) said it:
Compilers shouldn't generate warnings, they should generate errors.
It's time to stop holding the programmer's hand. If I write a C program that makes 5 malloc() and 4 free(), the compiler should notice that and say, "Gee, you have a memory leak here" and refuse to compile. It should NOT say, "Well, what you're doing is provably unsafe and probably not what you want, but yes sir Mr. Developer, I'll happily crash the system for you!" It is NEVER correct to write unsafe code.
I understand that there is a certain laxness built into C to make it easy to port to multiple platforms, etc., but these were compromises made in the early 70s, ffs. How long must we live with choices made under circumstances that became outdated 20 years ago?
"Honey, it's not working out; I think we should make our relationship open-source."
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.
Most security issues are a combination of Bad Specs and Limited Time (where Time==Money) That truely make a program insecure.
Companies are afraid to make the Specs simple they want the program integrated, customizable and expandable. And all that other good stuff so programmers are forced to make their application very dynamic which makes the program more complex and open for security issues. But combined with these specs they are not willing to pay the programmer for all the time is needed and they get very annoyed when the programer is over budget. So the programmer in order to keep his job will find short cuts to make the programming time faster (Hoping the product will be used in a well protected network. But of course once the program is completed they decide to use it outside the normal specs and put it on a hostile network.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
C++ should not be so casually lumped together with C. While C provides virtually zero (if any) facilities to automate better practices, C++ does. The two are NOT equivalent.
A Pirate and a Puritan look the same on a balance sheet.
It's not just that. They integrated web browsing into the file manager -- which is different than merely integrating html viewing. They designed the entire Windows UI Shell to be, basically, remotely exploitable.
There's no good reason to confound the local file manager with a networked program.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
The security advantage of some langages is that it makes it EASIER to write secure code, not that they make it impossible to write insecure code. There's a difference between protecting you from accidentially shooting yourself in the foot and preventing you from intentionally aiming at your foot and pulling the trigger.
It is possible to write secure code in C or C++ -- but it takes a whole lot more effort and talent to get it right than it would to do so in a language which does automatic bounds checking and runs in a sandbox. Unfortunately, history has shown us that it's extremely difficult to write secure C/C++ code -- only a handful of programmers are able to consistently get it right, and even the best of the best still make basic mistakes.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
I don't agree. Yes, if programmers wrote perfect code, there would not be vulnerabilities. But programmers are people, and people make mistakes. This is a given.
For the solution, I think we must look not to the programmers, not to the languages per se, but to their standard libraries. C's pointer arithmetic and unchecked array bounds allow for a variety of mistakes, but also for great efficiency. It's the standard functions like gets, scanf, sprintf, even printf that make C unsafe. Sure, the programmer can be blamed for writing unsafe code, but if these functions were removed and replaced by safer ones, there would be that many fewer mistakes to make.
Pointer arithmetic is mostly evil and should be avoided. As for bounds checking, I would think that with all the constant propagation modern optimizing compilers do, it would be easy enough to determine which accesses are guaranteed to not go out of bounds, and do bounds checking for the rest. Exceptions help, too. If something goes wrong that the programmer didn't account for, the program stops. In the best case, that means no harm done. In the worst case, the system is DoSed, a situation which is so undesirable from a productivity point of view that it's going to be fixed, whether or not the parties involved care about security.
Comparing a language that follows all the guidelines set out here to one that doesn't (e.g. Java to C) will quickly reveal the truth: there are far fewer vulnerabilities in safer languages than in unsafer languages.
Of course, mentality plays a role, too. With the industry having mainly focused on features and quantity, I am not surprised that software is so insecure, and I think businesses depending on this model are getting what they asked for.
Please correct me if I got my facts wrong.
This is exactly what those of us in the trenches coding have been saying for many years. The current abysmal state of poor software performance seems directly correlated to the race to the bottom in 'cutting' develoment cost. The solution to producing secure reliable code is to hire experienced competent programmers who understand security issues, and have a vested and sincere interest in producing reliable secure code. This generally means a long term relationship and with and understanding of the clients's needs and business perspectives, as well as the technical competence and willingness to put forth the efffort required to produce quality code. This is necessarily the oppossite of the current trend towards going with the lowest bidder, outsourcing, H1-B's, and throwing large numbers of low skilled developers at a project rather than using a small group of highly skilled developers. Fortunatley for me however my current client regognizes this and only retains a couple of long term highly skilled developers, they do have a number of very nice, secure and relaible applications to show for this, absent the usual bloated development team. This however may be the exception in the industry. Hopefully the corporate types will eventually figure out that throwing large numbers of low skilled developers at a project will not produce relaible secure code. This issue been well documented obstensibly in works such as 'Mythical Man Month" and "The Pragmatic Programmer" however it seems most corporate manager types have yet to acquire this wisdom. Mark
..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!
That's where I think the author completely failed to make his case for changing programming languages not being a solution.
People who program in C/C++ are vulnerable to all of the security risks Java and C# programmers are vulnerable to, plus quite a few more that Java and C# programmers are NOT vulnerable to.
So, if you have a program that could reasonably be written in either Java or C++, and you choose C++, you've just increased the number of security vulnerabilities you'll have to check for. Given the same development deadlines, but with more areas to check, you're going to be handicapped from a security perspective if you choose C++.
Then add to that the fact that almost everybody with equivalent experience is more productive at implementing a feature in Java or C# vs. in C++, with the same deadline pressures you have even less time available for security checking on top of more things to check if you work in C++.
Of course there are some tasks for which C or C++ are the still best choice for other reasons, so I still use both frequently and applaud any attempt at adding better security scanning to the compiler.
I can't help thinking, though, that even in those cases a language with the granularity of C but with built-in strings (UTF-8), arrays that are checked by default but with an override, with fixed built in data types (e.g., a 'byte' type that isn't signed in some places and unsigned in others), and yet without all of the massive baggage of C++, would go a long way to improving C's bug proneness without removing its power.
Unfortunately, most developers value such things as security, globalization and, frankly, reliability so little, resist change so much, and are so arrogant about their l33t ski11z that would only be impeded by "guard rails", that a language that offered only these improvements on top of C would never put a dent in C's popularity.
And to that extent only I agree with his thesis that bad programmers are the root of the problem.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."