Slashdot Mirror
Blame Bad Security on Sloppy Programming
CowboyRobot writes "ACM Queue has an article that blames security flaws on poor programming, rather than any inherent problems with particular languages.
From the article: 'Remember Ada? ... we tried getting everyone to switch to a 'sandboxed' environment with Java in the late 1990s... Java worked so well, Microsoft responded with ActiveX, which bypasses security entirely by making it easy to blame the user for authorizing bad code to execute.'"
Does anyone feel that this is just publicizing what every GOOD developer has been saying for the last 10-15 years?
Disconnect and self-destruct, one bullet at a time.
"Microsoft responded with ActiveX, which bypasses security entirely by making it easy to blame the user for authorizing bad code to execute"
.NET is their response to Java (and, for all intents and purposes, .NET is miles ahead of anything MS has ever created in terms of security).
Uh, not quite. ActiveX was more a response to JavaScript/Flash/et al. Anything that created a lightweight web app.
Anything we do to improve software security must work without the programmer having to switch languages
I agree; it's not so much the language--or the tools--each developer on a project must be personally aware of vulnerabilities and exploits. Using "managed code" does not "secure" your projects. These days, a C programmer ignoring the dangers of gets(), for example, is incompetent and should not be trusted. It's not, as the article reads, "sloppy"... it's ignorance pure and simple.
Also, relying on tools like an updated gcc, gprof, or splint--helpful as they are--without experience and education in writing secure code... is asking for trouble also.
Sigs cause cancer.
I remember the bad ol' days when security was a matter of what you did or didn't do rather than what you didn't know was occurring without your knowledge!
Abstracting the user from programmatic events wasn't supposed to make your use of the computer a crap-shoot.
Mod me troll, if you must, I can't help it.
That's why OpenBSD's continuous code auditing makes for good security. Everything but the kitchen sink != better.
That all said, a sandbox environment allows the developer to make sloppy mistakes, not program better.
Trolling is a art,
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 you're in college, the graders are not trying to break into your application, they're just evaluating the source code and give you points for correct stack and linked list implementation. Thus giving a false assurance that the real-world development is pretty much the same - friendly and non-threatening environment, no need to check and validate input, no need to resort to minimum security permissions and so on.
I think Caustictech said it better than I can:
a bad workman always blames his tools.
Drill baby drill - on Mars
Are you crazy?
Anyone who's worked on a software project of any size (especially in terms of number of people on the project) can tell you that the person who takes the official blame for a development flaw is almost never the person actually responsible for it.
Maybe if we had a programmers union and I could strike if I was ever asked to implement bad design or put out someone else's fire... maybe. But as things stand? You'd drive a lot of good developers out of the field because they're not skilled enough at office politicking to avoid being made scapegoats for the messes of others, and can't afford to bear the direct financial burden of it.
I'm glad someone other than me (who can get published on a site slashdot will link to) said it:
Compilers shouldn't generate warnings, they should generate errors.
It's time to stop holding the programmer's hand. If I write a C program that makes 5 malloc() and 4 free(), the compiler should notice that and say, "Gee, you have a memory leak here" and refuse to compile. It should NOT say, "Well, what you're doing is provably unsafe and probably not what you want, but yes sir Mr. Developer, I'll happily crash the system for you!" It is NEVER correct to write unsafe code.
I understand that there is a certain laxness built into C to make it easy to port to multiple platforms, etc., but these were compromises made in the early 70s, ffs. How long must we live with choices made under circumstances that became outdated 20 years ago?
"Honey, it's not working out; I think we should make our relationship open-source."
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.
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!
C++ should not be so casually lumped together with C. While C provides virtually zero (if any) facilities to automate better practices, C++ does. The two are NOT equivalent.
A Pirate and a Puritan look the same on a balance sheet.
Yes, that would be great. Open source would cease to exist overnight for one.
We could all be just like doctors, and spend half of our salaries paying for malpratice insurance. That's AWESOME.
Turn s60 photos into awesome videos with mScrapbook for all S60 3rd edition phones!
It's not just that. They integrated web browsing into the file manager -- which is different than merely integrating html viewing. They designed the entire Windows UI Shell to be, basically, remotely exploitable.
There's no good reason to confound the local file manager with a networked program.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
here in the UK the BCS in conjunction with the Engineering Council do accreditation for Chartered Engineer (CEng) status, and the new Chartered IT Professional (CITP) too.
Posters recognized by their sig,
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"?
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.
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.
``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.
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.
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.
Which doesn't really address the underlying issue. Yes, managed languages like C# and .NET are essentially immune to some classes of exploits that cause problems in C and C++. That doesn't mean that they're completely secure, though; there are still plenty of classes of security holes that apply to managed languages. You can bet that bad programmers will find plenty of them.
There's no point in questioning authority if you aren't going to listen to the answers.
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
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 it's a great idea, too! Let's extrapolate it, and have gun manufacturers asking gun owners to get safeties for their fingers. After all, it's not the gun's problem if you've got shaky hands! It's not the car's problem if the road is icy and people don't know how to pump the brakes...let's get rid of ABS!
Seriously...if after soo many years and soo many exploits programmers still haven't got it, they probably never will -- they'll just ignore the warning or throw in lip service methods (the way some Java developers perform exception handling by declaring all methods throws Exception). I've even heard people use the automatic bounds checking in C# or Java as an argument against them. Never mind that bounds checking is optimized to be predictive by the JIT, so it is rarely the cause of a bottleneck. When developers are so stupid that they consider essential security a bottleneck -- and the feature is trivial to add in hardware without slowing down I/O -- add the failsafe and be done with it. At worst, the bounds get checked twice, and that's not a bad thing.
Hey freaks: now you're ju
Yes, it DOES address the underlying issue. Just because part of the problem remains doesn't mean that the problem hasn't been addressed at all.
If you stop using C/C++ by default and use safer languages such as Java or C#, your code will become more secure. The fact that it still isn't 100% secure doesn't mean you've made no progress. And with fewer vulnerabilities, you can pay more attention to the types of vulnerabilities that remain.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
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)
..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!
> But I hate 'BEGIN' 'END' where { and } will do.
And some hate {} where indentation will do...
When people have holy wars over whether { should go on the same line or at the start of a new one, that should be a hint that the character really isn't all that important to program semantics.
At any rate, minimizing the number of keystrokes required to write a program should be fairly low on your list of what makes a good programming language, unless you're a hunt-and-peck typist. In general, readability is more important than writeability, if the program is going to have to be maintained.
Sheesh, evil *and* a jerk. -- Jade
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.
for example, in c#:Notice that the developer has no worries about SQL quoting or escaping - it's all handled by the database layer.
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.
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"
But the problem is that since C++ programs can also make calls to the C library, programmers often end up doing that instead of using the C++ features, *especially* with regards to string manipulations. While this might seem like the fault of bad programmers, keep in mind that the string manipulation abilities of C, while insecure, are very, very powerful. Also, for the longest time, the output formatting abilities of C++ were horrible. Even today, while they can do everything that the stdio libraries can do, they still take five times as much verbiage to do it. There's something to be said for: printf( "%12.2lf", balance );
If the makers of C++ had wanted to get rid of the unsafe use of null-terminated strings, they should have included a FULLY FEATURED string manipulation and string output facility that was just as easy if not easier to use than the one that you could use in old-fashioned C. Because they didn't (at first), they created a dis-incentive for dropping c-style strings.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Arguably the two biggest problems today are spam and trojans. Both of these stem from what is essentially a security failure, namely the abuse of authority. In the case of spam, the spammer is erroneously granted the authority to send out millions of emails. In the case of trojans, a piece of code fools the user into granting it the authority to run.
Neither of these problems is solved by using managed code environments.
Yes, Java solves a number of annoying problems. But it does so at significant expense, and the problems it solves are exactly those problems that are trivial to fix when found. It does not, and can not, fix the much more prevalent and potentially much more disruptive problems that occur at the human level.
Only unrelenting vigilance and diligence during development and deployment can ever hope to solve those problems.
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