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.'"
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...
I guess I should be an anonymous coward right now as I'm sure all the people who think Java is 31337 and open source will come and mod me down
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.
When will we see "ACM Queue has an article that blames security flaws on HR departments and middle management?"
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.
I think the writer meant ActiveX was Microsoft's response to Java *Applets*.
Java Applets had a well-defined and flexible security API that provided fine-grained set of privaleges for what an Applet could do on the user's system.
To combat Applets, Microsoft implemented ActiveX with brain-dead all-or-nothing approach that is still used today ("Do you want to trust whoever wrote this to do anything they want to your system? Yes / No"). Then Microsoft forced Java Applets to work the same brain-dead all-or-nothing way in IE.
SLL
The weakness of Ada is its woefully outdated standard libraries which are more oriented to a 1960s mainframe view of the world. There are no containers, no STL, no general algorithms. That is the weakness of Ada.
If Ada had the powerful standard libraries which C++ has, that combined the safety of Ada would make it a first choice for many programming tasks. Ada can still deliver on bug free programming. But it lacks the scaffolding needed for 21st century projects.
-
char s1[80];
...
which has a risk of buffer overflow, becomesvoid foo(char* out, char* in)
{ sprintf(s,"In = %s\n",in); }
-
char_string<80> s1;
...
which will truncate the string at the specified length. Note that the "sprintf" line hasn't changed. So you don't have to rewrite complex formatting code. Changing the declarations does the job.void foo(char_string_base& s)
{ sprintf(s,"In = %s\n",in); }
The new "sprintf" is actually an overload on fixed_string.
.NET is miles ahead of anything MS has ever created in terms of security
.NET, and that included a survey of the security features. A classic MS fallicy has happened here too: The Feature Creep. It is so overloaded with features I felt it made the thing unusable and difficult to understand.
I'm a little hesitant at that. About a year ago plus (when I was still in college), a MS guy came to campus to give a demo on
My suspicions were confirmed when the guy couldn't get a Demo to work correctly. His demo program, written in C# and provided to him by MS, was supposed to deny him access in scenario #1, and it worked correctly. But he couldn't retool the program to get scenario #2 right, where access was to be granted. No matter what the guy did, he kept getting denied access. Makes me wonder whether scenario #1 was actually correct or provided the expected denial for a different reason than intended. Oddly enough, the same guy had it working at a conference of local ACM chapters a week earlier.
My take on something like this: Yeah, you could get the configuration right when setting up your security model. But if it's this easy to get it wrong such that the program is unusable, then it's just as easy to get it wrong while still being usable.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
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
"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?
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!
"software people are worthless".
except he'd insert "shit" for "worthless". In this country (USA), the people responsible for the failures of these types of projects are never held accountable in a way that makes it possible to the next executive to learn from their mistakes.
Some days working in this industry feels like the story of Sisyphus
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
Let's extrapolate it, and have gun manufacturers asking gun owners to get safeties for their fingers.
Actually, it would be more like gun manufacturers telling bullet manufacturers not to make defective bullets that will blow up in the gun so that the gun manufacturers don't have to add safety against defective bullets.
they'll just ignore the warning or throw in lip service methods
At least they'll get a warning.
What about the situation where you build under multiple compilers and they can't agree on things? Sometimes it's literally impossible to get rid of all the warnings.
...
Besides, the habit of ignoring warnings often dates back to the days when the compiler was dumber than it is today and would complain about things that were 100% correct, like thinking you need to cast when
comparing a typed pointer to a void pointer in C (they whole fscking reason void pointers were invented was precisely for situations in which you *don't* have to care what the type is. That's what they're FOR. Then dumb compilers kept yelling at you for not casting void pointers, leading to such uglifications as this:
if( a_string != (char*)NULL )
Or, when a function is declared to take a void pointer, like:
free( void *m );
and the compiler would sometimes complain and bitch about not casting pointers when calling it.
This led to a practice that was even WORSE than leaving the warnings in place: Programmers being in the habit of casting *everywhere*, unthinkingly, to get the compiler to shut up. I even worked one place where this was the mandatory standard. I tried pointing out how bad a practice this is, because then the compiler will never tell you about actual ERRORS in mismatched types either - every time you use the wrong type of pointer, the compiler will assume you know about it and are doing it on purpose, because that's what you're trying to tell it by casting the pointer, so it won't raise an error.
This might sound like ancient history, like it doesn't matter, but often it's the case that this kind of thing is the reason many warnings are still there in old code, and new projects still use an awful lot of old code in them.
Sometimes the only response to a warning that works is to say, "Yes, I know what you're trying to tell me mister compiler, but in this case, you're wrong. No, that variable isn't uninitialized, it's just getting initialized somewhere you aren't noticing it. Yes, I know that variable is unused, but that's only because there's a section that only compiles when DEBUG is ifdef'ed on, and that's the section that still uses it.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Being a coder, I'll own up to having written bad code in the past. I even tried justifying it at times with "but I had a deadline" or "I tried to plead my case but management wouldn't listen" or other drabble.
These days, I simply won't take work from people who demand I write code their way, or impose unreasonable deadlines. Even in the programming decline since 2001 (it's bounced back well this year) I refuse to compromise my work because of someone elses ideas/deadlines/etc... because the end result is a reflection on me.
I like to think most programmers, early on at least, went through the same thing, but I could be wrong. It had nothing at all to do with having to build experience before I knew anything about the necessity of writing apps with security in mind. Rather, it had to do with needing work and compromising my own principles to gain employment.
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
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.
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
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.)