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
Figure this - code is only as good as the coder.
This sig no verb.
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.
I doubt outsourcing all of our coding to India is really going to help make more secure programs either.
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.
I hardly find this news on Slashdot.
Many of us ./ers program in some capacity and have varying experience. However, it should be understood that a language is not inherently secure (neither is an OS!). It may have features that make is appear more security conscious, but it does not make the code impregnable.
A car has seat belts and air bags, but that won't prevent an accident or serious bodily injury. It definitely won't prevent someone else from slamming into you.
Good programming starts in the design. Careful attention to the UI is a must as well (think Driver's Ed!).
Oh! And check those buffers!!!
Not that i really know anything about .NET, but i recall reading articles which mention that .NET allows you to call on undocumented API's. They might not create direct threats, but we've seen hacks that utilize two or three exploits at the same time. I could be wrong, so feel free to follow up with why.
[Fuck Beta]
o0t!
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"?
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.
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.
The original poster was correct. Java's main use back in the 1.0 and 1.1 days was webpage Applets. Microsoft took a two pronged approach to this threat:
.NET.
1. Microsoft released J++ as a "better" Java. (It actually was at the time. Took me quite a while before I switched back to Sun's JVM.)
2. Microsoft came up with a new type of embeddable COM object known as "ActiveX". Microsoft was trying to outdo Java by offering the full power of the Windows platform inside webpages. Somehow we were all supposed to be happy that we could write these object in C/C++, and that they could take over your system at a whim.
It wasn't until after a judge told Microsoft that they couldn't ship Java, that Microsoft started their "COOL" project. The "COOL" project was widely considered a Bad Idea (TM) (much like digital watches) and was widely derided as a adolescent move by Microsoft. Sadly, Microsoft foisted its COOL platform on the world anyway, and now we have
Javascript + Nintendo DSi = DSiCade
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
``I'm not sure that was why applets were not a big hit... I'd blame the slow JVM startup time for that one.''
There is that, and there are the various incompatibilities. Microsoft's VM is not going to run your code, unless you specifically write it to work on it. For other code, you'll typically need a fairly recent VM, which means a hefty download if yours is not up to date. Many users are not willing to invest so much time just to see your sucky applet - and most of them are sucky, compared to real native applications.
Please correct me if I got my facts wrong.
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
Maybe he's not trying to "prove" anything but merely state his opinion that Java is annoying and that people hate it.
Not everything has to be a thesis here, y'know. I don't get why people only ever demand proof for an opinion when it's an opinion that goes against the majority.
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!
1. the bad programmer can't fix it, but says they can, tries anyways and makes it worse.
2. the good programmer can't design it, but says they can, tries anyways and makes it ok.
3. the great programmer invents something like the blinking cursor, which makes life better.
3. the expert is on an island living off of the revenue generated by their two great ideas, one was to hire the good and the bad programmer for peanuts, since the economy sucks, and two was score clients using the great programmer's invention of the blinking cursor.
stuff |
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.
I wonder if you've heard of a site called Slashdot? They have a facility for contacting members by ICQ. It uses ActiveX.
I am TheRaven on Soylent News
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.
Sure, part of it is spatial inflation, but much of it is people not willing to stand pat and say, "woah now, that's just too much for product X". I know it's difficult when it's something like a house, but you can always choose to live in an area with a much lower cost of living. There are places other than Silicon Valley (increasingly in the Midwest and Southeast) with good "IT jobs" where you can make "a pittance" and live like a monarch - you'd be surprised how much house $120k will buy you in the Southeast!
Rather than whining that 6 digits isn't enough due to cost of living, be the smart shopper and say, "I'm gonna stop supporting this crap and move." If, however, the cost of moving (including non-monetary things like family strife or whatever) is more than what you save by moving, then you have no right to complain, because you're complaining about your own choices.
It's not like anyone's forcing you to stay in a place where your income to expenses ratio, regardless of what the actual numerical value happens to be, is not what you want. And if they *are* forcing you, well, that's another issue entirely...
"There are a dozen opinions on a matter until you know the truth. Then there is only one." - CS Lewis (paraprhase)
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
..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!
First of all, it's hard to argue that any other area in the country has more tech involvement than the bay area. Next it's hard to match the niceties of the location. Winter low of barely below 60 degrees is nice. Then you add in culture, and on top of that all within 30 points of a central point you have San Francisco, Berkeley, Oakland, and development employment area's (like pleasanton, etc).
I'm not complaining about the costs, but I am saying that yes, you MUST make more here to make up for the more expensive living costs. Anybody who thinks that making 6 digits anywhere in the country guarantees an easy mortgage payment is a fool (as the AC displayed in his response about California being "shitty"). And it's not just California, check out Boston or NYC. There are tons of places in this country where the luxury and lifestyles of the location drive up costs.
And by the way, supply and demand aren't broken, supply and demand are what is MAKING these houses cost so much. So many wealthy people want to live here it drives up the cost. Supply and demand is broken in places that have rent ceilings (which cause housing shortages).
Everyone who lives in the midwest should be thankful of the expensive california area's. The fact that everyone here makes more, means that everyone here pays a greater ratio of federal taxes. Without California federal taxes in the entire nation would have to be significantly higher.
And lastly before you assume that I'm an uneducated California dolt, I grew up 18 years in Ohio, have spent 3 years in Indiana going to school, and will return to Indiana from my summer internship this fall. I understand perfectly the economics of both California and the midwest. I'll take California's in a second. But on the same note, when somebody says that 6 digits is enough to pay any mortgage easily, it just shows their ignorance to our nation IMO.
#1: Difficulty: It is harder to write, although having an inherently secure language such as Java or Ada helps. You not only have to think about your algorithm performing correctly, you have have a "hacker's eye" to make sure it cannot be used to compromise the O/S.
#2: Performance: (This is a biggie) Checking parameters and disallowing certain programming techniques that could be misused to compromise the underlying system will have a performance impact. It also makes for fatter code, if you ever tried to decompile Ada. The performance loss may or may not be significant, depending on the algorithm. But for something like direct X that provides a thin software layer for high performance graphics, I suspect the performance hit would be unacceptable. This is probably true for other high performance apps as well. That is why 99.99% of all software comes with a "caveat emptor" EULA. (Imagine if they built airplanes, cars, and buildings like that?)
Safety and life critical application will of course always be coded using "tinfoil hat" secure languages and operating systems. They also cost 100x as much to do the same job, and require more powerful hardware to do the job.
#3: Complexity: The more complex a given system is, the harder it is to secure it. The more complex the system, the more places for flaws to hide.
My rights don't need management.
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.
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.
o? Take your USB port that shines from the front of the PC. Nice and inviting, provides a few W of power and a pair of data lines... now jam your finger in it. Can't do it, can you? What happens if you short out the power lines? There's a fuse on the motherboard. What happens if a device isn't wired up correctly? The OS doesn't even get a chance to see it.
Now treat it like software: hang a space heater off of it and complain that it doesn't work. Allocate 3 weeks for design and implementation. Testing is for the weak. Add a SOAP interface (don't change the deadline). Oh, did we mention that motherboard X doesn't want to use our pinout? Make it work somehow.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
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.
We have already GONE there. Java, .NET, fancy smancy libraries for C and C++ all exist and are all far far safer than the old stuff lieing around. Microsoft has taken notice of the security trends are and introducing many backwards compatability breaking changes into XP SP2. When Microsoft *knowingly* breaks backwards compatability, you know they mean business (see this article, even tho I agree with the "MSDN Camp": http://www.joelonsoftware.com/articles/APIWar.html ). Even tho everyone on /. hates them, you can't deny that when Microsoft starts a "bet the company" style trend, that the rest of the tech world doesn't play along.
http://brandonbloom.name
How's a coffee cup warmer?a ccessory/ accessory%20series-USB%20Coffer%20Warmer.htm
http://www.sunbeamtech.com/new/products/
Motherboard didn't always have a standard USB pinout. (if they do now). Think hardware plans don't go through the same time restraints? If you do, lay off the crack. Consider that EVERY YEAR new videocard chipsets come out, and half way through usually get a revamp. Think you can design and test an all new design in a single year? Get that nice fat 14 layer board right the first time? Hardware has the advantage of they make STANDARDS for interfaces (Hear that MS? An agreed upon industry standard!). And transfer to production isn't just making disks, you have to setup numerous processes and accumulate the materials used. That stuff doesn't come at a short time frame.
Hardware can do it, why can't software?
If you think education is expensive, you should try ignorance -- Derek Bok, president of Harvard
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.)