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.'"
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
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.
Not real popular with EEs, unless you are in power systems. I've never heard of a software engineer with a PE stamp, but the system is in place.
http://www.ncees.org/licensure/licensure_for_en
BS. There was a bunch of (proprietary) DHTML stuff added through IE6. Based on a pure feature list, IE's DHTML is a lot more advanced than Mozilla's (who tends to stick to barebones W3C stuff).
There are ActiveX applets all over the place---and not just those with a spyware payload. Think Macromedia Flash/Shockwave, Apple QuickTime, Real Network's player, Microsoft Windows Media Player, etc. You find these apps embedded on countless websites, particularly Flash.
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.
ActiveX was MS's answer to Java Applets. Flash is another applet alternative.
.Net is MS's answer to J2EE.
J2EE and Java Applets, despite being written in the same langage, have very little to do with one another.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
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
You can follow the link above to see how they connect crime to poor coding.
Give a man a fish and he will eat for a day.
Teach him to eat and he will fish forever.
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.
no.
IBM and Microsoft were working on an operating system together- they had a lovers tiff and Microsoft took their code from the project and made Windows NT, IBM took their code and make OS/2
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.
I'm a VB 6, ASP, and VB .NET developer and to put it from my viewpoint. I really don't think has anything to do with the language, compiler, or development environment; but more to do with everything else.
On an average day I deal with patching of our IIS web servers, Administrate 2 MS-SQL servers. In addition to the ENTIRE software development life cycle: from Analysis to maintenance. All the while dealing with 4 to 5 major projects.
If I release bad code it's because someone didn't give me ample time to verify/think about what I'm writing. The people who tend to cause these errors also tend to cause this other problems:
So, do I believe that different languages are inherently better for security? No, but I do believe that some programmers are inherently better for security.
"640 K ought to be enough for anybody." -- Bill Gates, 1981
> Languages that don't have variable length strings make me choke.
Ada does support variable-length strings, as well as fixed-length and bounded-length strings.
Sheesh, evil *and* a jerk. -- Jade
Why not simply use a less retarded language?
Troll-like as you are, i'll respond. First of all, what you said is what they are doing. Replacing C with C++ (let the flames begin)
Second, if you can reduce security flaws in legacy C code by simply replacing the variable definition and recompiling with a C++ compiler, that is a good thing. it can probably be automated so you don't have to sift through millions of lines of code looking for C style string declarations.
I worked on OS/2 at the time, son. Microsoft was an impediment to security and stability - and none of the WNT code (except for a few chunks here and there) came from OS/2; their code was inspired by VMS if anything.
Actually, a lot of what the article suggests IS fixing the tools. Making compile/link warnings into errors, putting security checks into the program at compile time like optimizations, etc.
Uh, not quite. ActiveX was more a response to JavaScript/Flash/et al. Anything that created a lightweight web app.
.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). .Net is what MS developed when they decided not to support Java client-side. Its pretty good in terms of security, but still has weaknesses when compared to Java.
Uh, yes quite! ActiveX was exactly and precisely a response to Java - Java Applets that is. The idea was to run embedded binaries in a web browser. ActiveX components would run only on Windows, so they could use the Windows APIs, and so not require a plug-in or pre-installed VM, like Java Applet. ActiveX 'security' was by digital authentication, as against Java's sandbox. ActiveX is not related at all to client-side scripting, as with JavaScript. Microsoft's response to JavaScript was - to support JavaScript.
Here is my general view of the "secure programming" world. It goes out to all developers.
Know your tools. Choose them wisely -
Low level languages are not the problem; they are the most widely understood. Security is a process not a language. When your code inherits features and functionality that you did not intend, bad things can happen. Sure, we may not have buffer overflows, but if your RPC function allows me to execute any code that I want without overflowing buffers, who cares? Also, with these super portable "sand box" languages, I get to find one hole and exploit it everywhere. If you think Java is the answer, please tell me what language you think Java was written in? Also, please read "Reflections on Trusting Trust" by Ken Thompson.
Seeing the big picture -
Peer review is part of the security process; your attackers are becoming very skilled at finding exploitable software bugs using automated tools to help them. Everyone in the development process needs to know the type of application they are developing and the sensitivity levels of the information they are protecting.
Rule of Simplicity -
Design for simplicity; add complexity only where you must. Default to Deny, compartmentalization of code is good for more than just limiting security bugs.
Sweat the small stuff -
Just because certain attack vectors are obscure does not negate their effectiveness; writing good clean code is safer and more sane than allowing a program to "protect" bad coding practices at execution time. We have seen many examples of how this other type of protection fails.
Don't use your customers as your Q/A staff -
The Microsoft Software Release cycle is destroying security from the users and programmers perspective; it causes users to not want to upgrade, and it causes programmers to not want to fix security problems.
Don't build a $100,000 fence for a $1,000 horse -
All data is not created equal, don't treat it as such. Let the protection be commensurate with the asset.
Audit trails -
Trust with accountability. Every significant access, whether denied or permitted must maintain an audit trail.
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.
I've seen lots of people who do...
which to me seems not much different to "end loop".The single character {, } certainly makes it easier to see where control structures end at a glance so that's a Good Thing (tm).
I find that my fingers can type begin/end quicker than {} (no shift key), but I suspect it's just a matter of habit. When I switch from Java to Ada, or Ada to Java, I often get the comment symbols wrong (-- vs //). Most of the typing issues are pretty much irrelavent once you've done a small amount of programming in a language (IMHO).
A good "performance oriented" coder would know better than to choose an algorithm whose safety depended on doing a test in an inner loop. He's probably used a series of bitmasks, AND's, and shifts to ensure that even if the values were out of range that they didn't cause problems.
As an assembly programmer, I've learned two very helpful techniques to avoid overwriting memory:
Performance programming is not simply leaving out vital checks. Rather, it is designing algorithms in such a manner that the checks are unnecessary, or performed at a level where they are easily handled. Even a good C++ programmer wouldn't think of starting to render a BMP before having validated all of his fields.
The society for a thought-free internet welcomes you.
Here's one:
http://www.tribaltrouble.com/
Here's another:
http://www.wurmonline.com/
Troll elsewhere.
You don't seem to recognize the name of the person who wrote the world's first firewall (fwtk) and who is one of the most outspoken security gurus, do you?
One might not agree with his opinion (I do not in many points), but to reduce his arguments (that most development tools give no support for security properties of software systems, but should) to some rambling about "M$" just shows your unprofessionality.
Joachim
People don't write Manifestos any more -- what's going on in this world? [Frank Zappa]