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.
> ...if you can just shoot the message?"
So true. Thus the logo for PMD, a Java static analysis tool - "don't shoot the messenger".
The Army reading list
I blame bad security on the Speak'n'Spell keyboards we have to use in this office.
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.
It is time to create an official Engineering Certification for software designers/developers, the certified Engineer will have to be financially responsible (insurance etc.) for their creations.
I would like to see that happen, anyone else?
You can't handle the truth.
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
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 will we see "ACM Queue has an article that blames security flaws on HR departments and middle management?"
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
A lot of problems result from the C and C-like languages' inherent faultiness. The language is a great way of writing "portable assembly language", but makes for sloppy code a lot of the time, even from relatively experienced programmers. It's mainly due to the "New Jersey" approach to development.
C++ and C are very popular and widely used, and will probably never fade completely as they are too entrenched, however, there are a lot of languages these days with compilers which can produce code as tight and fast as C/C++, but without the mess. This is one example, there are many others.
Brandon Glass's personal site.
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."
While it's easy to rip on the idea behind ActiveX, Mozilla.org thought it was a good enough idea to copy it as XPI*.
The basic idea is that plugins and toolbars should be easy to install, and due to the nature of these things, they often can not be "sandboxed" or run in a Java VM. One of the big complaints about Mozilla is that people find it difficult to install the Flash/Java/Real plug-ins. If vendors supported XPI, this would be mostly resolved.
The real security problems with IE are not directly related to ActiveX, but instead the holey and flawed "zone" system. There's also some operational annoyances with ActiveX (like throwing up dialogs even though ActiveX is disabled and the lack of an easy way to whitelist), but it sounds like XP SP2 is going to try to fix some of those things.
* ? Apologies if I'm confused about the moz alphabet soup.
Business. Numbers. Money. People. Computer World.
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.
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.
Didn't even finish reading the article before: /var/www/acmqueue.com/htdocs/db/db.php on line 88
Fatal error: Call to undefined function: message_die() in
-
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.
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"?
Speaking as a computer engineer who passed the FE (on my first try) - the FE is most definitely biased in favor of civil and mechanical engineers, and against electrical and chemical. That being said, there's really very little incentive for EEs to take it. The only things you need it for are government work or testifying in court.
However, it really gets under my skin when people call themselves "engineers" and they have *no clue* about engineering in general. In texas, they had a school collapse and kill 100 children because the guy who designed it wasn't a real engineer. As a result, they passed the toughest engineering-standards legislation in the country - if you call yourself an engineer and you are not certified (that is, you have not passed the PE) then you go to jail.
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
Which is now /.'ed you would know the author was arguing the point against the hardware people putting buffer overflow checks in hardware for essentially a software design problem.
He was saying that warnings, etc. need to require the programmer to fix errored code (ie, gets() vs fgets()). Like code optimization, security needs to be a low level function of a runtime/compiler.
It is a different take on an old problem. If you don't like it simply don't read it. However, since you waste time posting redundant posts about redundant articles I figured it was right up your alley.
If Java worked well, it wouldn't be one of the languages that a ton of people hate to work with because of how annoying it is... granted, that is due to the poor VM rather then the problems within the language itself...
Your argument is attempting to prove that Java does not, in fact, work well. What you're saying goes something like this:
You can't assume that point #1 is correct because you can never assume that which you are trying to prove. The only proof (albeit subjective proof) you offer is that "tons of people hate to work with it." But if we grant that to you then you're affirming the consequent. Again, something you can not do. This argument doesn't work.
Depending on how skeptical you are today, you might think:
Really bad/inexperienced users write insecure code.
Good programmers write good,secure code.
Excellent programmers that work for companies that make a lot of money from support and updates write insecure code that is easy to fix.
Slashdot Syndrome: the sudden, extreme urge to correct someone in order to validate one's self.
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.
"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?
Unfortunately, unless someone as big as Microsoft (ha!) or IBM gets behind the message, you're not going to see much come of it.
.NET. Longhorn will be entirely .NET-based.
They have--see C# and
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
Define secure.
I can guarantee that a developer and a customer will have two different definitions of secure. And, the cost will be more than the customer will want to pay.
How many customers can write a scope of work, send it off to a developer, and get a proper quote for a project that includes adequate security? How many customers actually remember to ask for security? Or if they do, do they put enough priority on security?
I bet the answer is very few. I know from past experience that most customers take the cheapest bid. The cheapest bid is usually the one that is skipping something, and the easiest thing to skip is security. If the customer didn't ask for it, is the developer responsible? Is Micro$haft reponsible? Nope. Security is not in their project. They want speed. So, there's always a niche for ActiveX. Microsoft knows they can undercut someone's cost because security isn't an issue.
And everyone complains about Microsoft's future security ideas. Well, what do people really want? Security? Or no security?
-- No sig for you!
Good security is more a matter of developer foresight than anything else. Almost all of the security flaws known to date hinge on two factors:
The first point applies to a lot of Microsoft software; the second, to a lot of software across the board. The fact that a sysadmin blames compromises on easily-guessed passwords is no solution at all - yes, the user is at fault, but the user wouldn't have chosen a bad password if the system of username/password wasn't broken in the first place. It seems that sysadmins and developers alike forget that ordinary people have to remember things far more important than the dozen or so username/password combinations that it takes to live in today's society...
The society for a thought-free internet welcomes you.
Bugs should not result in security issues.
I repeat: Bugs should not result in security issues!
A properly designed application will have multiple layers of error detection and security checking. As you write your software, abstract things like security checks and database access into an API, and then do insane amounts of input validation behind that API!
In my home turf language, PHP, one of the biggest common problems in applications is the dreaded SQL-Insertion bug.
The pat, standard answer is to validate-validate-validate!
But, I'm human. I *WILL* make mistakes. It's only a question of when, not if.
Ask yourself: How can I structure my application so that mistakes in this regard do not result in an immediate, full compromise?
I bury database access behind an API that forces me to identify the data being passed to the database, and then trap errors from the database so it doesn't show anything to the web client.
Example:
<?
$sql="INSERT INTO logindata (login, password) VALUES ('[login]', '[password]')";
$todb=array('login'=>$login, 'password'=>$password);
if (!$DB->SafeQuery($sql, $todb))
Error($DB->Error());
?>
What happened here? The SQL statement does not contain any data - instead I'm passing a template for the query, and the data array to parse into the query. The function SafeQuery() does a pattern match to get the names of the fields (in the square brackets) and then does the requisite addslashes(), as well as checking the number of fields to ensure that everything matches up, before actually dumping this statement over to the database.
Errors get trapped within the object, and are accessed through function Error(). This prevents any sensitive information being sent to the browser, and the global Error() function simply displays an "Sorry but an error occured" webpage while logging the text of the error message, and quits.
Now, none of this negates the need to do input validation - but this makes a very bad threat for PHP application all but disappear!
As you develop your applications, structure them as much as possible such that bugs and errors do not result in security breaches.
Use constraints and triggers in your databases to kick out data that can't be demonstrated as good. Use APIs and functions to interface with areas (such as the shell/CGI interface) so that common security mistakes (such as not escaping a shell argument) simply can't happen.
Repeat after me: Bugs should not result in security issues!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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
The problem is that QA and development of good specifications prior to a project have a huge impact on the quality of the product that results. Having said that, QA and specifications are never seen directly by the outside world.
Most programmers I know WANT to write good code but have the odds stacked against them. They aren't given the time and resources to do the job well. When it's crunch time, security and quality are the first things to go because they are less likely to get canned over a bug than over a completely missing feature.
This sig has been temporarily disconnected or is no longer in service
The first image conjured up by "sloppy" is someone using sprintf in production code (much buffer overrun potential), raw pointers unnecessarily, ad-hoc string manipulation code, and so on. But it's much deeper than that.
Consider something as simple as BMP file format decoder. Writing a decoder is easy. It takes about 30 minutes tops to write one for a subset of the format. But writing a safe version is much more difficult. First, you have to validate all fields. Easy enough. Then you have to handle attempts to crash an application by passing in really huge values, like 10,000,000 pixels in each dimension. That's a bit trickier, because you have to figure out what you should allow and what you shouldn't. Then you have to deal with intentionally malformed images, where the RLE information doesn't add up to the total image size. Depending on how the code is written, this can cause you to chew through memory past the end of the image. To fix this, you have to put some checks into your inner decoding loop. The temptation to avoid doing this is strong, especially among "performance" oriented coders.
So, yes, you can blame this on poorly written code. But had this been written in a checked language, like Lisp or Python or any similarly safe language, then some of the problems go away immediately. Not all of them but some.
It isn't the coders.
I believe it is management's fault for insisting on designs that are unsecure (like ActiveX).
You can have coders who KNOW the correct way.
You can give them tools that help them secure their code.
But those only work if management focuses on secure code instead of "user friendly" features.
And management will only focus on security when the buyers focus on security.
I think we're seeing that now. More people are accepting that Linux is more secure than Windows, so Microsoft has to start focusing on security in an attempt to narrow that perception.
..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!
I worked, at CenterLine, on a follow-on for CodeCenter that used compiled-in checks to get similar checking at a higher speed than the intepreter. It was a wonderful accomplishment, but it was still vastly slower than a good Java or Modula-3 implementation. Use a safe language, end of stupid security bugs, and you can spend more time worrying about the subtle ones.
One more thing to note, if you take the draconian view that warnings are for wimps: I found one real program, in all that I tried as tests, that did not generate a single warning during its execution, and that was gzip. One of the emacses was our error-filtering test case; running to the "dump" step, it generated over one million diagnostics, which we managed to automatically filter down to one thousand.
I really have to wonder about the author's background. He claims to care about this, yet has apparently never used Java outside of a browser, nor played with the BDW-GC for as a leak backstop. I sure do wish the ACM editors were a little more clueful.
Starting with the last - He praises M$ development environments. OK, what was the last major Bug that even made the Drudge Report. An IIS and IE combo - why are IIS sites defaced more since it is the minority and even CERT is saying to switch browsers (how do I load Firefox or Apache into Visual.net?).
He complains about C malloc/free (ever heard of electric fence?). C++ (wasn't OOP the magic bullet?) gave us new and delete and some garbage collection and more memory leaks (but he says we shouldn't use Java which actually gets the conceptual model right). Oh, and every makefile I have has -Wall, and running them produces no warnings (at least when I'm through changing things algorithmically). And I'll have to look again for a good opensource lint. I used commercial products for a while.
Since I'm often doing embedded, I have to be careful and have space and timing requirements (and in many cases NO debug facilities) few others have to deal with.
The article is probably worth reading, but won't be very helpful. A lot of people don't understand the art of programming even if they make their living that way. The people doing the hiring either want the buzzword checklist, or don't care if the result is brittle (at least not when the project starts).
His solution is more "magic bullets". Everyone I know (even many I would not let write a simple sort routine) was horrified by ActiveX (v.s. Java). How do you make that secure? You can't.
A security shell inserter like pixie? Maybe it would be a source of exploits (basically it is a manual virus - if you can alter an EXE to add a security shell...). And an IDE can be a great tool (Emacs works for me) but also can make one lazy - I assume IE and IIS with all their holes are developed on the same praised IDEs.
There is an art to programming and it often takes 5 years and is a way of thinking, not a "method". I do Java and C++, but I don't do them differently than I do C. But much education (and investment) seems to be toward finding a product or method to replace process.
As often has been said: Security is a process not a product.
My own saying: I don't write complex programs, I simplify and reduce complex tasks into simple programs.
Good Cheap Quick, pick 2.
On the topic where memory management related security issue is blamed on reluctance to switch away from C...
This is not true. Cyclone does exactly that, and more. Cyclone is a dialect of C. In fact, a lot of C code can be ported to Cyclone with little to no modification. It has garbage collection for stub malloc/free code, and optionally region memory management where you can dictate when some collection of objects are deallocated all at once.
I once had a signature.
This'll end up on the fourth screen of threads, but it's worth reading for those who find it. It's over seven years old, but essentially everything in it holds true today. (worth reading on various lists I don't have it bookmarked - I knew where it was.
"They Write The Right Stuff". I'm not even going to provide a summary of everything which is listed in the article. There are a lot of good lessons in well organized, well thought out explanations as to why the software doesn't shut down but how few errors are found.
There is a difference between a shuttle crew and standard users. 1) A shuttle crew is a smaller user body. 2) They're more likely to follow instructions ala "what happens if I hit this button?"
I've never sent a note to the author, but I think it would be a book as important as Writing Solid Code (is that the right one? (I've been up a little too long without a syringe.)