Slashdot Mirror
The 25 Most Dangerous Programming Errors
Hugh Pickens writes "The Register reports that experts from some 30 organizations worldwide have compiled 2010's list of the 25 most dangerous programming errors along with a novel way to prevent them: by drafting contracts that hold developers responsible when bugs creep into applications. The 25 flaws are the cause of almost every major cyber attack in recent history, including the ones that recently struck Google and 33 other large companies, as well as breaches suffered by military systems and millions of small business and home users. The top 25 entries are prioritized using inputs from over 20 different organizations, who evaluated each weakness based on prevalence and importance. Interestingly enough the classic buffer overflow ranked 3rd in the list while Cross-site Scripting and SQL Injection are considered the 1-2 punch of security weaknesses in 2010. Security experts say business customers have the means to foster safer products by demanding that vendors follow common-sense safety measures such as verifying that all team members successfully clear a background investigation and be trained in secure programming techniques. 'As a customer, you have the power to influence vendors to provide more secure products by letting them know that security is important to you,' the introduction to the list states and includes a draft contract with the terms customers should request to enable buyers of custom software to make code writers responsible for checking the code and for fixing security flaws before software is delivered."
I'll sign such a contract, but the project will take twice as long and my hourly rate will go up 300%.
People like to draw the comparison with civil engineering, where an engineer may be liable (even criminally) if, say, a bridge collapsed. But this isn't really the same thing. We're not talking about software that simply fails and causes damage. We're talking about software that fails when people deliberately attack it. This would be like holding a civil engineer responsible when a terrorist blows up a bridge -- he should have planned for a bomb being placed in just such-and-such location and made the bridge more resistant to attack.
The fault lies with two parties -- those who wrote the insecure code, and those who are attacking it. I'll start taking responsibility for my own software failures when the justice system starts tracking down these criminals and prosecuting them. Until then, I'll be damned if you're going to lay all the blame on me.
A real programmer can do all 25 in one line of code.
Kind of ironic the report is a PDF file, when another report stated that PDF accounts for 9/10 (or something like that) exploits last year.
Some of the errors are not relevant, mainly having my code in a managed (i.e. .NET) environment. The SQL injection and XSS potential vulnerabilities are still very relavent to me. Although most of my responsibility lies in code which is only reached via a https authenticated connection, as with any other web programmer, a "trusted" user can still -especially- find exploits.
This is even more true in inherited code. If you inherited code from a previous employee, I recommend a rigorous audit of the input and output validation. You just don't know what was missed in something you didn't write.
... letting me try assembler with my level of dyslexia.
Holding a gun to somebody's head won't make them a better developer.
I don't understand why well-known and tested techniques can't be used to catch these bugs. There are many ways to help ensure code quality stays high, from good automated and manual testing to full-on code reviews. The problem is that most companies aren't willing to spend the money on them and most open source projects don't have the manpower to dedicate to testing and review.
TFA seems like it's just looking for somebody to blame when the axe falls. If your method of preventing bugs is to fire everybody that makes a programming mistake pretty soon you won't have any developers left.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
Or did they retire that category?
... how many of these errors have been committed by slashdot?
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
They got each organisation to submit one error, ranked them, then dropped the last 5 (or maybe there were 5 double-ups)
Divide a cake by zero. Is it still a cake?
The Register is just talking about another article detailing the list.
The actual article: http://cwe.mitre.org/top25/
I am a competent and trustworthy programmer in his late 30s who will fail a background check because I was convicted of something in my mid 30s, something I did when I was a teenager (and still a minor).
I have, over the years, been given many responsibilities and opportunity to abuse the authority required to discharge those responsibilities. I never once have abused that authority. If you ask previous co-workers if they consider me honest and trustworthy they will unanimously tell you that I'm one of the most trustworthy people they know.
I strongly resent the growing prevalence of background checks. I wasn't convicted of any sort of fraud or theft, but I am rejected anyway. The sad part is half the time I end up having to tell someone exactly what I was convicted of and why, and they wring their hands over their policy being so stupid but follow it anyway.
Background checks lead to stupid behavior. The criminal justice system is only a mediocre to poor arbiter of who is and isn't trustworthy. Like lie detector tests, you can never pass, only fail.
. . . to the list, instead of an article discussing the list: Link
When you say "developer", I think individual employee. However, the individual employee isn't around long enough, the project validation will more than likely happen after the majority of them have finished, taken their final pay and left.
As for the actual contract? It reads like lawyer bait.
Consistent with the provisions of this Contract, the Vendor shall use the highest applicable industry standards for sound secure software development practices to resolve critical
security issues as quickly as possible. The "highest applicable industry standards" shall be defined as the degree of care, skill, efficiency, and diligence that a prudent person
possessing technical expertise in the subject area and acting in a like capacity would exercise in similar circumstances.
And finally, background checks? Seriously? Only if you want it to take 6+ months for me to hire someone.
I didn't see this one in there... I once typed it into some code by accident. It's more common than you'd expect.
Free the Quark 3 from asymptotic confinement! Bring your charm! Don't get down! All colours and flavours welcome!
But I think they probably could have shortened it to about 6 or 7. "Sanitize every input", "pay attention to trusted vs untrusted input methods", "bounds checking - do it", "make sure the encryption you use is strong enough", "watch multi-threading carefully", and the interesting one: "while error messages should be helpful and detailed, remember that you're not the only one reading them."
The way to prevent most of these types of errors is to fix the programming language. A modern high-level language simply should not allow most of these things to happen. Any such language which does needs to be either fixed or discarded.
Yes, for low-level work you need languages without such safeguards. But for the rest of development work, the compiler/interpreter/runtime environment should prevent even the most careless of programming from making most of there errors.
The model contract smacks of the customer attempting to micromanage the vendor's development process. You might get away with that if you're IBM or the Federal Government, but most smaller customers aren't going to have that kind of clout.
And of course, the "security training" section is pure self-promotion for SANS itself.
So much shit. So much commentary. Just gimme the list? Here it is:
How we know is more important than what we know.
Outsource security and programming to those countries responsible for the attacks.
Right away the system will have fewer vulnerabilities and there will be fewer attacks.
While it makes sense for the developer of any product to be held responsible for its quality, it does not make sense for some huge multinational company to sue a $20/hr programmer for billions in damages.
Troll is not a replacement for I disagree.
"Insisting on absolute safety is for people who don't have the balls to live in the real world."
- Mary Shafer, NASA Dryden Flight Research Center
Good luck actually finding a programmer that will give you code you want at the price you're paying.
Oh, and protection against SQL injection attacks? That shouldn't be part of a contract; that should be implied.
Yes, there are many bad programmers out there. Probably over 50% of them wouldn't understand the bugs (security or otherwise) if you sat down and tried to explain it to them. Probably most people who work as programmers should be in another field. This isn't, however, really the issue.
With commercial software, the real problems are well known. Product and project managers for the most part do not understand software. What they do understand is their deadline and making their bosses happy. Quality is always sacrificed in order to make those deadlines. Companies put far less emphasis on testing than they should, and even when companies have great programmers and go to great effort to test, things will slip through anyway. Fees, contracts, etc. are really just a replacement for training that comes too late, after the problem has already occurred.
Improper Sanitization of Special Elements used in an OS Command
The best solution is not "sanitization" (which people usually perform by blocking or editing out what THEY think are dangerous metacharacters) but proper encapsulation. In addition, there's a misleading section here:
Execl() is not a "C" API, it's a UNIX API. It doesn't involve quoting. On a UNIX system, you can safely take advantage of this mechanism to pass parameters and bypass either shell or application quoting inconsistencies. On Windows, even if your program is in Perl and you pass system() an array of arguments, Perl is still at the mercy of the called program to correctly parse the quoted string it gets from CreateProcess()... *unless* you are operating under the POSIX subsystem or a derivitive like Interix.
In addition, whether you quote your arguments, use execl(), or use a smart wrapper like Perl's system(), you still need to ensure that COMMAND level metacharacters (like the leading dash (on UNIX) or slash (on Windows) of an option string) are properly handled.
This latter problem may remain even if you pass the command arguments through a configuration file to avoid the possibility of shell metacharacters being exploited.
Whitelists can't be simplistic. You can't ban the use of "-" in email addresses, for example. Encoding is better.
Bad programming for a radiation therapy machine caused it to emit 100 times the radiation dose after certain keystrokes, burning patients badly and killing some of them. Wikipedia has the root cause analysis.
what is a programmer to do when managers demand short coding time, nothing but leave features out. Each feature costs time and given less time companies have to be happy with more bugs
So, I clicked the link expecting something similar to the slashdot description and was shocked to find a real and relevant list!
Cross site scripting? sql injection? buffer overflow errors? Those are real problems and issues that any programmers would do well to learn about.
Really, presenting that information almost makes Slashdot seem, well ... responsible and informative.
I wonder if I just went to the wrong site...
Instead of articles *about* the list, go to http://cwe.mitre.org/top25/.
some jackass circa january 1986
As much as we might like to think otherwise, software development is a business. And like all businesses the goal is to generate profit by increasing revenue and decreasing cost. As such an inherent bargain is struck between consumers and software shops as to proper ratio of cost to quality. High volume consumer applications get a lot of attention to quality though less to security. It's all a matter of threat assessment verse the cost of securing against such threats. Sure we all want perfect software where the software engineer is held accountable for every bug. But we also want software whose cost is comparable to a 20 dollar an hour sweet shop programmer. The software that results is really an economic compromise between the two. Running a space shuttle or saving patients lives? You probably are willing to shell out for the high cost software engineer. Putting up your hello kitty fan club blog? You might settle for something a little bit less... high class. I've been in this business for awhile now and as much as we like to wax poetic about quality we are still just trying to have our cake and eat it too. Better, faster, cheaper. Pick two.
Wow, that dude sounds almost as scary as that guy named Sue.
I must have put a decimal point in the wrong place or something. Shit. I always do that. I always mess up some mundane detail.
She's not a guy. As for her balls, she might have ripped them off the guy named Sue for all I know.
In the case of XSS I'd say fix (X)HTML and the browsers. By default scripting should not work in the body of a page. Force a meta tag to enable it in the head part of the page or by end-user override if they really must have it. There is really no reason scripting needs to be included in the body of a web page. Trying to completely block scripting, especially in IE which just executes damn near anything, is a real pain and often ends up excluding valid data such as comments including source code. If someone uses an unsafe browser it's their problem.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
a programmer who doesn't get bitten by race conditions on occasion, and I'll show you one who doesn't program more than basic multithreaded code.
A good programmer is a good debugger...
Does having a witty signature really indicate normality?
Whoosh!
What if you obtain your software through means other than a written, detailed negotiated contract?
What if you provide software you have written to the world under terms no more detailed than, say, the GPL?
Is this really a serious effort at security, or is it a corporate push to get entities away from libre software?
Any word on who is really behind this?
I work as a software developer in the avionics industry.
This list is ridiculous.
There's nothing any website programmer could do that is even remotely dangerous compared to what we could screw up yet all I see in the list are website programming bugs.
Hold devs responsible for bugs that creep into code. Because, after all, we all know that developers always get to work on unlimited time constraints and NEVER have any pressure to cut corners and get something out fast...right?
If they do that, there has to be a means to defend oneself in that situation, or they're suggesting that unlike any other production industry, the workers would be held accountable for a company's systematic failure to provide an operating environment and schedule that could produce success. Work a developer 24 hours without paid overtime? No problem. After all, if they get delirious and check in some code they were using for testing and were too out of it to remove it and it gets into the final version...and poof...there's a bug, you can sue them for whatever they were paid during 8 hours of that shift. Or a lot more. Then, you end up with the legal problem of defining what a proper environment and schedule would be. After the dust settles, all you'll have is a pile of bureaucracy and a legal mess that will just end up in shafting the developer, and not the management ultimately responsible for the release, in the end...after way too much money and time is spent trying to wade through that mess each time a bug is found in production code. Ridiculous.
Any bugs that resulted in a human death move to the front of the line.
Defective automobile braking and accelerator systems perhaps? Medical equipment that delivered too much radiation due to a software error (vs. machine-operator error)?
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
"As a customer, you have the power to influence vendors to provide more secure products by letting them know that security is important to you,"
And, as a consumer, you have the power to influence vendors to provide better employment and buying practices by letting them know that they are important to you.
Meanwhile, the vast majority of America continues to shop at Walmart whilst every competitor goes out of business.
"Does it get the job done? Now what's the cheapest I can get it for?" is most people's primary motivation.
Sellers, who listen to them saying, "I want security!" and deliver that, at the expense of greater cost, are then left wondering why the competitor who did just enough to avoid standing out on security but otherwise kept their product slightly cheaper is selling many times more copies.
So, yes, people can influence sellers with their actions. The problem is, it needs to be their actions, not their words. Even worse, they're already successfully doing just that - unfortunately, their actions are screaming something quite different to any words about, "Security is truly important to me."
Been there, done that, in an aerospace company. Here's what it's like.
First, the security clearance. There's the background check before hiring, which doesn't mean much. Then, there's the real background check. The one where the FBI visits your neighbors. The one where, one day, you're sent to an unmarked office in an anonymous building for a lie detector test.
Programming is waterfall model. There are requirements documents, and, especially, there are interface documents. In the aerospace world, interface documents define the interface. If a part doesn't conform to the interface document, the part is broken, not the document. The part gets fixed, not the documentation. (This is why you can take a Rolls Royce engine off a 747, put on a GE engine, and go fly.)
Memory-safe languages are preferred. The Air Force used to use Jovial. Ada is still widely used in flight software. Key telephony software uses Erlang.
Changes require change orders, and are billable to the customer as additional work. Code changes are tied back to change orders, just like drawing changes on metal parts.
In some security applications, the customer (usually a 3-letter agency) has their own "tiger teams" who attack the software. Failure is expensive for the contractor. NSA once had the policy that two successive failures meant vendor disqualification. (Sadly, they had to lighten up, except for some very critical systems.)
So that's what it's like to do it right.
A real problem today is that we need a few rock-solid components built to those standards. DNS servers and Border Gateway Protocol nodes would be a good example. They perform a well-defined security-critical function that doesn't change much. Somebody should be selling one that meets high security standards (EAL-6, at least.) It should be running on an EAL-6 operating system, like Green Hills Integrity.
We're not seeing those trusted boxes.
I have as much of a right to verify their background. After all, you don't want to deal with convicts.
Security experts say business customers have the means to foster safer products by demanding that vendors follow common-sense safety measures such as verifying that all team members successfully clear a background investigation and be trained in secure programming techniques. [citation needed]
"He who pays the piper is calling for a low-quality tune" - Tom DiMarco and Timothy Lister in their book PeopleWare: Productive Projects and Team
yay! another way for the insurance people to make money!
New Economic Perspectives
You now become personally liable for any problems. No lawyer would have their client sign this. Which means we can ignore everything else they recommend, because it's tainted by the stupidity of this "requirement."
There are less painful ways to earn your Darwin than by the death of 1,000 legal cuts.
Programming machines with capacity to love?
The solution to the software reliability crisis is to abandon the Turing Computing Model and adopt a deterministic, non-algorithmic, implicitly parallel, synchronous and reactive software model. This model is based on the notion that almost all unforeseen (and unpreventable by syntactic debuggers) bugs are due to erroneous temporal expectations within computer programs. Timing is the critical element of computing that is missing from the Turing Computing Model. And it's not a matter of providing clock objects for use in certain time-dependent applications. Timing is critical at the instruction level because it allows us to determine the invariant temporal signature of a program and sound an alarm whenever a deviation is detected. Software should be such that it should be possible to determine whether any two events (operations) within a program are either concurrent or sequential under various conditions. This sort of temporal determinism will enhance security and reliability by many orders of magnitude if not cure the problem once and for all. If you're serious about finding a solution to the parallel programming crisis that is also a solution to the reliability problem, check out the links below. It's free info. Take it or leave it.
How to Solve the Parallel Programming Crisis
Parallel Computing: The End of the Turing Madness
Why Software Is Bad and What We Can Do to Fix It
The jest of it is that we must reinvent the computer. We are using essentially the same model that Babbage invented more than 150 years ago, the thread concept. It's time to change.
Rebel Science News
I divided by zero once.
"But, no matter what you do, it will never be perfectly, 100% risk-free to fly. Or to drive, or to walk, or to do anything." I find that very appropriate given the current topics so often discussed here.
There's another problem here which we seem to be forgetting: The user.
Users continue to buy systems with inferior security -- every dollar spent on Windows is a dollar telling Microsoft that you're OK with them taking months to fix known security bugs, and Apple is no better. Maybe this "contract" would help, though it will kill Easter Eggs, among other things, and that makes me sad.
But even if you design the most secure system ever, it's useless if the users aren't educated about security. This was specifically a list of programming errors, but put it into perspective. There's really nothing I can do to keep people from reading your email, modifying it, or impersonating you entirely and undetectably in an email sent to someone else (which you'll never see), if you aren't willing to at least learn the basics of something like PGP. If you learn PGP and use it properly, and convince all your friends to do the same, and people still do nasty things to your email, that is the point it becomes the programmers' fault, but you have to meet them halfway.
Don't thank God, thank a doctor!
"Well I'll tell 'ya that I've fought tougher girls, but I can't really remember when,
she kicked like a mule and bit like a crocodile"
-- With apologies to Johnny Cash
To be fair, I used to agree with this 100%. Now that I'm in a position where I'm the one accountable for any errors, not so much....
if (alert_code = red)
launch_missles ();
is it me or is americans in love with absolutes?
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
Really bad.
The problem is that 99% of us fellow programmers are full of sh*te and know next to nothing. How many programmers do know what a rainbow table is? How many know what use a salt is for? How many know that in most PKCS the public/private key pair is typically used to exchange a symmetric key and why is it so? The birthday paradox? How many know how a timing attack works?
If you think that's bad, I've got much more worrysome: most programmers simply do not understand at all how public/private crypto keys work. I remember scratching my head on this, last century, when I read about it. I simply couldn't understand it at first. "Why would it be slower without the private key?". I went on to write my own algo to crack weak keys. Just to "master" the topic. Who takes that pain?
Another monstrously huge problem is that you can't really be a good programmer unless you've also at least some sysadmin skills. Do you eat stateful firewall rules for breakfast? Or may you know jack shit about networking and you're writing your applications so that it becomes a pain for sysadmins to install/monitor and they've got to pierce holes everywhere for your swiss cheese app to run correctly?
Face it, there are so many security issues because most programmers are completely clueless when it comes to security.
You want to see how lame it is? Go look at the retarded answers voted +30 on stackoverflow.com on some subjects: I saw one accepted answer with 32 votes where the dude explaining what a salt was completely missing the point. Then there was a deluge of comments telling him he and all the people who voted this crap answer up where on heavy crack, yet the comment defending the bogus and stupid answer themselves kept being modded up too. Then of course if you get a bit too vocal in your own answer (who still gets some +votes because they're not all complete retards) because you're pissed off to read such misinformation you've got retards with lots of rep like Shog9 who're going to play the revisionists with your posts and for lots of these high reps are completely clueless too, they actually change the meaning of what you wrote, making it wrong (not on purpose, it's incompetence, not malice). And that "tragedy of commons" website of crap is where the "real programmers" hang out. Sad.
This is how bad the situation is: most programmers really have no fraking clue about security. Most programmer don't even know what a stateful firewall is.
Worst of them all: because XSS and SQL-injection are not hard to understand, they *think* they know it all about security when they know what these attacks are. Yet they are actually completely clueless for about 20 others issues of these 25 listed.
The bullshit answers "but the bad buy are attacking us" are no excuse for our incompetence and lack of knowledge.
I'm in the process of building a web site. Based on past experience, I wanted to make sure that I could knock out SQL injection. I also made sure that covered buffer overflows and cross site scripting. Then along comes this Slashdot article and BANG! I realise I've covered the top 3. Now all I need to worry about are 4-49, and I'm good to go.
Believing in output when input is garbage is the worst computer-related sin.
I think most of us here understand why this is true.
Why don't you build your "Universal Behaving Machine"? It doesn't have to be even remotely powerful, it just has to prove universal capability. Hell, if you don't fancy fiddling with breadboards, you could even do it in software/on existing UTMs, though I doubt you will, given your distaste for software/UTMs (HINT: atomise "time" in your virtual machine, make all operations as discreet representations of their actual indiscreet nature, then show frames/snapshots and compare simulated UTM runtime to simulated UBM runtime, obviously choosing operations with heavy b/locking issues for UTMs to demonstrate UBM superiority). Of course, a virtual machine wouldn't have the performance advantage you're talking about, but again - all you need is proof-of-concept. Such a proof of concept could fund your "science" for the rest of your life (both financially and in terms of credibility), so it's not as if there's no incentive.
Though for the record, I think you're as balmy as a bag of bedbugs. I find it inherently contradictory to speak of an operation/process that can produce valid output when its input changes during operation - for example, if you had an operation that returns $(input+5) with 5 (atomic) loops of incrementing by 1, and at an arbitrary point during operation the input changes, then obviously timing always enters into it . And don't tell me that mathematics or algorithmic logic is UTM-speak, because then your "U"BM is not a "universal" machine (humans can do mathematics, and we're "universal" machines). But prove me wrong, and I'll praise your name.
The loss of 7 people was tragic, but not an unjustifiable risk for such a grand endeavor as human spaceflight.
Only a Sith deals in absolutes.
PlusFive Slashdot reader for Android. Can post comments.
Of course, she's a woman so she doesn't have the 'the balls'...
Does that mean she insists on absolute safety and was trying to say that in a humoristic way?
Sigs are for the weak.
Having programmers imagine every way that their program may be attacked is impossible.
Fortunately, that's typically not required for software security. In a lot of cases, you can prove that for all inputs, the software does the intended thing.
For instance, if you know that the username variable will always be properly escaped, you don't care whether the user is called "bobby" or "bobby tables" (http://xkcd.com/327/).
It takes a lot of discipline, though, to always consider who the origin of a particular piece of data is, to decide (based on that) exactly what amount of trust to place in it, and how to handle semi- or untrusted data.
I wish the original poster (and everyone else using these terms) would stop doing so.
There are no such thing as "bugs". There are programming errors and programmer mistakes.
And "bugs" (aka. programming errors) do absolutely not "creep into the code"!
This terminology has made for a bunch of apologetic imbecile programmers that blame their errors on the position of the stars or the foulness of their neighbours farts. They do by no means convey the reality of the situation.
I am a computer scientist, and I stand by every programming mistake I make.
This signature is DRM protected. By the DMCA, you are not allowed to counteract or oppose to it.
At school we would write programs (mostly silly adventure game style things) in QBasic and share them with the whole school on an unsecured hard drive attatched to the main server. I once added a few lines of code that went something like 150 PRINT My name is Adam and I like willy 160 GOTO 150 to a friend's game. Happy times.
I have mod points so I would mod you up.
However you're an AC, and lots of people browse /. with all AC's automatically downmodded to -1 so there's probably not much point. But I agree with much of what you say - with more to add.
Most of the arguments against this article boil down to one single thing.
"It's too hard."
You know something? That's a lousy argument. If "It's too hard" was a real argument against reliable software, the airline industry would never have developed modern autopilots without planes crashing out of the sky because of software faults on a daily basis.
If "It's too hard" was a real argument, NASA wouldn't have a reputation for developing almost bug-free software.
If "It's too hard" was a real argument, OpenBSD would have had a lot more than just two remote holes in the default install in over 10 years.
Frankly, as an industry IT (and I'm referring to all IT here, not just software development. Sysadmins are just as guilty) needs to grow up and start developing and implementing some real good-practise processes industry-wide. The engineering industry seems to have mostly managed that, and when was the last time you heard of a properly maintained car exploding for no good reason?
Well... NASA has never lost any space probes due to software bugs, right?
And OpenBSD has only had two remote holes ("Only" two?) in the default install (with nearly all services turned off).
Avionics industry is doing better, but check out the requirements on them ( http://en.wikipedia.org/wiki/DO-178B )
If this is to be followed for all software, well, something is certain: costs and development time will go up.
In my limited experience, the wish is rather for these to go down even further, with more impossible deadlines ever coming up...
"Give me six lines of C++ code written by the most competent programmer, and I will find enough in there to hang him."
Whatever is made on human being's hands, is prone to have errors, simply put. It's no use to try this ridiculous contract, that'd only make the work-hour more expensive and still, the human factor denies the assurance of an error-free software.
Sometimes. But that is maybe a pretty good observation. Whatever.
once. It was a Kawasaki 350 like mine, a couple of years older and parked next to my bike. With apparently, an identical lock cylinder. I was in the process of starting it when I looked down and saw that the shape of the instrument cluster had changed. At that point, I noticed I was starting the wrong motorcycle, stopped, moved to my own bike and took off.
I figured it was simply a 1 in several thousand chance and was mildly amused.
Tech Public Policy stuff
I'll be the unpopular one and say that except even then,
1. IRL you'd have a good chance to catch the terrorist. Someone would see them trying to attach the bomb, there'd be traces, etc. I've yet to see many programmers think of implementing the equivalent as logging and monitoring.
Probably the worst offender I've seen in this aspect was a site where deleting your user also cascaded through all foreign keys and erased any trace that you ever existed, or done anything. Contracts, debts, messages, everything would just disappear in a black hole. We're talking about a B2B site where contracts started at millions of dollars. But you could just delete your user and any trace that you ever accepted that contract would simply disappear.
Sorry, but that's beyond "I'm not a civil engineer" and into the realm of being a clueless fucktard.
2. Most of these exploits are known to already happen every day, and are really just maliciously triggering a bug that is already there. If you want a more apt comparison with civil engineering, it's not terrorists with bombs, but someone driving a car into a bridge pillar. Sure, it can also happen maliciously, but it is a fault you're supposed to prevent either way.
3. Even terrorist attacks are often taken into account in civil engineering. See the WTC which was actually supposed to withstand an airplane impact from a smaller airplane than those actually used. Or I was talking to someone who actually does simulations for an airport so they can improve their layout and lessen the damage in case someone does detonate a bomb there. Etc.
So basically, yes, RL civil engineers actually have to think of such scenarios too. Unlike the average retrained burger-flipper programmer type who just finds excuses for why he doesn't.
4. The real reason why the most extreme terrorist attacks aren't taken into account in RL civil engineering projects is a calculate risk. If probability of an attack times damage done is less than what it costs to reinforce the bridge more, the decision can be taken to not reinforce more. But it's an actual calculate risk, not a stupid excuse to do a crap job.
And more importantly software doesn't have the same "the probability is too small" factor to justify such a decision. An XSS exploit or SQL injection being actually exploited isn't as rare as a terrorist attack. In fact, it's almost certainty. The same excuse simply doesn't apply.
4. In the end all this is missing the point: you're there to deliver what the paying customer wants. If he's ok that his site will resist everything except every single script-kiddie who wants to pwn it, sure, you don't have to do that. If he actually expects security, you're there to deliver security, not lame excuses.
5. And I doubt that the hourly rate is the problem either. I've seen a site done by ridiculously overpaid consultants from a major corporation, where they only checked your rights when they generated the links to other pages, but not when you actually access those pages. Trivial exploit: choose to change your user's password, edit the user ID in the URL of that page to user 0 (it was the admin), change the password. Now log in as the admin of that site and do whatever the f-word you wish. Seriously, stuff like that makes me actually wish there _was_ liability in some contracts.
A polar bear is a cartesian bear after a coordinate transform.
I think you are confusing argumenting correctness and proving correctness.
It is impossible to prove that your escape sequence for PHP will proper escape any given input for a given field, just look at how many tries the developers behind PHP had at escaping a simple query string for MySQL - and still failed - why? Because they failed to imagine the myriads of ways you can make quoutes in UTF-8 and failed to take into account the forgiveness of MySQL. Very few languages allows you to prove correctness, add an intelligent file pointer like MySQL and you can't prove anything.
A Monday morning quite a few years ago:
UPDATE Customer SET NotifiedByMail = 'false'
*click*
Err, I mean WHERE Id = 140487
*click*
Sudden realisation.
Oh crap...
Let's say I committed a very, very bad thing and I rolled back under my desk...
More to the point, the astronauts explicitly agreed to the risk. They knew what they were doing.
It's really not the same thing as bridge building at all. xD
The fun thing is that i've found at least three bugs in their example code other than the ones MITRE intended to illustrate. The most glaring of which would prevent the code from even getting compiled. http://cwe.mitre.org/data/definitions/805.html void host_lookup(char *user_supplied_addr){
/*routine that ensures user_supplied_addr is in
struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);
the right format for conversion */
validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
strcpy(&hostname, hp->h_name);
}
The final strcpy will not work, since the first parameter is a pointer-to-pointer-to-char, instead of pointer-to-char.
Timeo hominem unius libri
The navy even has Windows running ships. How does that square with all the stuff you mentioned? I'm guessing theres some conflicting interests in government.
I think most here agree to a certain point. Writing software is impossible without errors. I also feel that holding a gun at the head of a developer in order to 'persuade' him or her to write better code is not going to help. We are after all humans, we need motivation and stimulation in order to get better at what it is we need to do.
However, what is more important is that the processes surrounding the software that needs to be produced, whether result of a client requirement or as part of a new idea, is sound and helps to avoid and remove errors.
Developers have an obligation to take note of known exploits, known attack vectors, and make sure to avoid these pitfalls. But it is impossible to predict all types of attacks, so the processes that govern the requirement gathering, designing, development, testing and the continued maintenance on the software once released are equally important. The whole organisation is part of that quality and security process, not just the developer. Plus, the cost of the production of the software is a very important consideration.
In light of this I found the old article about the space shuttle software development extremely interesting. It clearly shows that it IS possible to write near-perfect software, but that has its price. But a well-driven development organisation is in principle capable to produce solid, error-free code. By adjusting the mindset of people and modifying the processes that introduced errors.
Read it if you don't know it yet, it is a very nice article that I keep in my bookmarks...
http://www.fastcompany.com/node/28121/print
By all means, accountability is great.
But saying the developer is at fault is ridiculous. It opens the door for companies to mismanage projects as per usual, and clueless HR departments to hire people who don't know what they're doing, and fire people arbitrarily every time they have a complaint from someone that the software doesn't work.
Start the responsibility with the company. If the company sends a flawed product and are to be made accountable, then the organisation needs to prove:
* It has proper QA processes in place to test the product, and that the staff are suitably qualified.
* The project management was performed to allow for proper specification, design and development within the normal working hours of a day, taking holidays and time lost due to usual unforeseen circumstances.
* Training, or self learning time is allocated to enable staff to keep current with developments and issues with languages/compilers/methods they use.
If you're going to hold a developer responsible, then it should be absolutely certain that everyone in the dependancy chain for that person is responsible. Did HR hire someone who wasn't fit for purpose? Their job is to ensure that doesn't happen. They're the start of the problem chain.
Did management provide the logistics necessary to complete the job to a quality? If not, they should be liable.
Did the sales team (if it's bespoke software) make impossible promises (if so, and developer opinion was overturned such that a 'broken' system was arrived at from spec, then the salesman should be accountable).
Did the producer of the spec introduce a design flaw that resulted in the error? If it wasn't the developer, then the specifier/designer was at fault.
Pretty much whichever way you look at it, management and HR should carry the can first, leaking down to the developer, if you're going to be sensible about it. If a place is well run, well managed then sure, have developer liability, but expect to have raised costs to cover developer's professional liability insurance.
you wrote
launch_missles ();
you meant
launch_missiles ();
mutually assured destruction saved!
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
is it me or is americans in love with absolutes?
You are 100% correct. Anything less would be un-American.
Tequila: It's not just for breakfast anymore!
Not commenting code adequately, especially ad hoc debugging fixes, leaving it near-unmaintainable....
I'm going through this right now..... Bugger. Why not document, please?
Hit: http://jamals-massive.blogspot.com/
Hit: http://jamals-massive.blogspot.com/
Presumably she's implying that she has more balls than the people insisting on absolute safety. /explaining the joke
.evom ton seod gis eht
Yes, but they were betrayed by petty office politics that resulted in the warnings of experts being ignored by people that got their jobs by having the right drinking buddies.
They wanted Feynman's name on the cover up but he wasn't going to go along with it after NASA engineers went around management and the rigged enquiry procedure and showed him the evidence.
... until only specialized people wit criminal intent can unpick the locks.
Continuing with the car analogy (what a suprise) most modern cars's locks can't be picked up open.
At the end you need an arbeiter of what is the minimum acceptable (insurance companies, trade bodies, professional associations) This will come, sooner or later, we are living in an era of blissful innocence, it will amaze people in the future that software companies had the gall to say ther were not liable for the software they were selling.
It is impossible to prove that your escape sequence for PHP will proper escape any given input for a given field
Do you have a proof of this?
If finite state (or pushdown) transducers are anything like their counterpart automatons, it should be perfectly possible to prove theorems about them.
In particular, it might be possible to prove that a particular transducer always outputs strings which satisfy a certain property (i.e. valid SQL where all characters besides literals are identical for all inputs).
just look at how many tries the developers behind PHP had at escaping a simple query string for MySQL - and still failed - why?
Because they're incompetent. Or because they were drunk. Or because they didn't have a big enough budget. Or [...].
Pointing to previous failures isn't a proof of the failure of all potential future attempts: the failures might have been for the wrong reasons, those not having to do with whether the task is possible.
I think you are confusing argumenting correctness and proving correctness.
That doesn't surprise me, given how well you appear to grasp the difference.
Unlike a software bug, you can't put out a patch to fix a collapsed bridge, or release a service pack for a unbalanced rotor shaft that destroys a generator.
So wait, it is acceptable to patch it afterwards?
When you hear people moaning about buggy software, or claiming the developers be personally liable, the implication is usually that patching afterwards isn't acceptable. If I can patch it afterwards, and maybe charge them for it too, sure I'll gladly accept the comparison to engineering.
We're talking about functions that you could expect the completed product to perform, not fucking miracles.
When we're talking about security holes, it's a fair comparison.
For other things, all that would happen in a world of personal libaility is that the number of functions you could expect the completely product to perform would be vastly diminished. You'd get software that was only certified to be used for a small number of finite inputs (which is no different to the way most engineered products work), and anymore would be a higher cost.
My bridge doesn't fall down because a bus drives over it instead of a car.?
Nonsense, things like bridges and tunnels do have limits, and yes there is a risk if you exceed things like weight or height limits.
Your software still breaks. That's why everyone's pissed at you.
The ultimate problem is that you want it on the cheap. How much did your browser or operating system cost? Now how much does a bridge cost? And which of these two systems is more complex?
If you really want to compare to bridges, then perhaps you should start paying those kinds of prices. The fact is that bug free software does exist, you just have to pay for it - and most people are too cheap.
Your'e paid to produce software that performs a given function, not software that might work under some circumstances.
I'll gladly be like a bridge builder, who gets paid to write software that works with only one limited set of inputs, and does a specific thing. E.g., a web browser that will decode one specific web page (which is surely no more simple than a single bridge that allows a car to travel from one specific place to another specific place). Most people want things that are vastly more complex, however.
You have a bright future in management.
I am very small, utmostly microscopic.
I've got a squad of Bangledeshis that will sign the contract, underbid you by going under the original price, and turn it out in half the time. So...shut and take what we give you. Unless you are coming up with something completely innovative and earth shattering, you are doing pee pee caca work and you'll get paid like it. You are a programmer, and like MBA's and English majors, the world is full of your type.
On another note: Guess who just got promoted and instead of running a programming team, is now managing TEAMS. Hey, and that management seminar has already paid off.
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
How about the one where someone stole someone else's identity from a poorly written application leaving the victim unable to pay for/acquire/use vital services?
Perhaps there's not a direct bug-to-death relationship, but the trivial-to-defeat bugs that top the list can lead to things going awry, like your Toyota incorrectly controlling the brakes or accelerator (not saying that's what caused the Toyota problem, just saying that can happen with some of these simple errors).
It is more likely this will result in an inconvenience, possibly severe, than a death, but sometimes if you're not the only YOU in the computer world, it's like death.
End the FUD
That's not true. The implementation of mysql_escape_string does exactly what the developers who wrote it wanted it to do. That is: Escape a string of 8859-1 encoded bytes.
The fact that this was not what the users wanted and expected it to do, is the reason they also made the mysql_real_escape_string method.
But this is a design mistake, not an implementation mistake. The mistake they made was that they were having a query* method that accept multiple different string encodings, and an escape method that could only escape iso-8859-1 and other single byte encodings. This was stupid but not a bug as such.
* Well the real mistake was to have a mysql_query method at all. They should have had prepared statement support only, would have made all php software much more safe.
The navy even has Windows running ships.
I'm sure you mean to to say "the Navy even has Windows running ON ships" instead of the implied opposite "ships critical systems are controlled by software run ON Windows."
When I was in the USAF, we used openly available software on our desktop systems for our administrative duties like e-mail and word processing, but on the satellite control systems the software was rigorously controlled. It was not anywhere close to running ON Windows (or Mac or BSD or Linux or Solaris...).
End the FUD
Never!
Neil Cherry - Linux Smart Homes For Dummies
This goes against the business practice
of "just good enough". If you want the bugs fixed,
the contract value would have to go up 5X or more.
I'm sure businesses would appreciate that !
Perhaps the Navy isn't quite as smart as the USAF:
http://www.slothmud.org/~hayward/mic_humor/nt_navy.html
I'm hoping they've since given up using Windows for that sort of thing but I wouldn't lay money on it.
Perhaps the Navy isn't quite as smart as the USAF
Heh...we always thought that. In good fun, to be sure.
End the FUD
This would be like holding a civil engineer responsible when a terrorist blows up a bridge
If the bridge failed to live up to its designed specifications then the engineer would be liable regardless of the means used to bring it down. Major structures ARE designed knowing that attack is possible and the engineers try to mitigate reasonably foreseeable and preventable problems. While a structure is never designed to withstand all possible attacks you can be sure the contract will outline performance requirements which the engineer is expected to meet. If the bridge met its designed performance specs AND those specs are deemed reasonable given the state of the art (no excuse for shoddy specs) then the engineer has met his professional obligations. Software engineering should be no different in this regard. Just because some software is badly designed and implemented doesn't mean all software engineers should be excused from standard of care in exercising their professional duties.
Bear in mind, only a fool would sign a contract with unlimited liability. Just make the contract one that clearly specifies the performance levels required and the resources (including time) needed to meet that level of performance. Then get liability insurance like doctors, lawyers, accountants, and other skilled professionals do for when things do go wrong since nobody is perfect. Software engineering is not and should not be an exception.
...it is unreasonable and completely unrealistic to expect every line to be a pinnacle of perfection, just like it is unreasonable to expect that every sentence in a book is completely without error.
And every lawyer you ever talk to will agree with you AND then tell you that what you just said is irrelevant. Nobody really cares if the code is perfect. What they care about is if the code failed and someone got hurt (financially, physically, etc) as a result. If the code is designed and/or implemented such that a reasonably common and foreseeable attack (say a buffer overflow) can and does occur and harm results, then the programmer has failed in their duty of care. Doctors, (civil) engineers, lawyers, accountants and even tradesmen (electricians, etc) who engage in professional services all have this obligation to perform high quality work. When they fail in their duties they get sued and rightly so. They also carry liability insurance because nobody is perfect. Software engineers are not and should not be an exception. Just because your job is hard sometimes does not excuse you to do shoddy work that will cause harm to others.
absolutely.
"But then don't be surprised of the opinion customers and your peers hold for you."
There were some extraneous commas, but the main errors are that the last sentence should read, "But then don't be surprised at the opinion your customers and your peers hold of you."
It's nearly impossible to actually write a well-formed specification that covers the full operation of the code once a certain level of complexity is reached.
NASA does it for the code in the shuttle. It costs a fortune.
The POSIX standard is 17MB of text files written over multiple decades, and people still argue about the interpretation of various corner cases.
I agree with that 110%!
You shall see a cow on the roof of a cotton house.
I think that companies (management) should be held liable for poor quality of the software they produce. How each individual company distributes that liability internally is completely up to them. So whether you want to work for a company that holds its developers financially and legally liable is completely up to you. My guess is that that such companies would quickly go out of business.
I work in the telecommunications industry managing (first line - still a pawn) a sizable team of software designers. If one of my designers creates a security hole which is subsequently successfully hacked, it could mean that 911 services go down somewhere and someone unnecessarily dies. That being said, a bug in our software typically means that someone somewhere can't download their porn.
Here's how the process (for me) works:
1) Customer sees a need for new functionality and communicates that to the company
2) Request goes to Product Line Management and they get R&D involved for some preliminary time and cost estimates
3) PLM then squeezes the timeline and passes on the date to management
4) Management squeezes the timeline again and passes it back to the customer
5) Customer then requests a reduced cost and an even earlier delivery date
6) Management agrees to terms
7) R&D is stuck developing a release in 1/3 time it takes to develop properly
Also, the code base is millions of lines of disjointed code that are very difficult to manage effectively.
In order to devliver software under these conditions, we depend on heroics from our developers... they're definitely overworked, but not underpayed. We also have to cut corners by only performing specific targeted testing. In the end, our products have their fair share of bugs, and some of those bugs could be catastrophic. However, that's what the customer negotiated and paid for, so that's what they got!
Everyone of my designers would like to produce better software (not perfect - that's impossible). They're just not afforded that privilege by management and customers. So do I think software developers should held responsible? Hell no... they should learn from their mistakes, but holding them financially and legally responsible means it will take 10 times longer to develop software.
Is that the crony put in place by the Bush administration? :p
I'll take liability, when the industry changes enough that I can say "No, you can't have that" when the client asks for something stupid, and the end result is not me moving to a fulfilling career as a wal-mart greeter.
If the program were a control system for a jet fighter, or safety system for a subway line, I'd agree.
Nonsense. You write a crappy program which you sell to me which then gets 0wned because of your bad programming costing my business lots of money, I'll want your head on a platter. It doesn't have to cost lives to cause real harm. If you as a programmer can't be bothered to follow reasonable industry standards to prevent foreseeable and preventable harm to your users then you, my friend, are negligent under current law.
However whether I'm entitled to anything depends on whether you as the programmer A) fulfilled the design specifications of the software and B) satisfied your professional duty of care in the creation of your software. If you can't be bothered to program your software to reasonable industry standards for security then you ARE and SHOULD BE liable.
Let's be clear - you ALREADY are potentially liable as a programmer for harm caused by your actions. The only things protecting you are the fact that serious harm is relatively rare and hard to trace to you personally. If it can be proven that your negligent coding was responsible for allowing real, foreseeable and preventable harm to another party then you deserve to be sued.
The problem is that what you said could be easily applied to "oh no, there was a bluescreen of dearth, SUE!"
The word you are missing is reasonable and it is part of the test for whether the harm that occurred is worthy of a lawsuit. Like every programmer I've ever met you have immediately taken things to ridiculous logical extremes. A blue screen probably didn't cause my company an appreciable amount of harm. An insecure accounting system that gets hacked would cause a lot of harm. Which situation do you think I'm going to generate a lawsuit over? Which one do you think would get laughed out of court?
If you want to start criminalizing bugs, expect to see even more development moved overseas and less free and significantly less open source software.
The benefits of open source are no excuse for software that will cause significant harm to my person or my business. Furthermore, you can limit liability in many ways. Open source software also provides some protection because the user has the opportunity to review the code for risks themselves. If the user can't be bothered to check the quality of software they use when they have the source code you as a programmer have a pretty darn good defense.
I also doubt you'll see code going overseas more either if the companies doing so intend to sell the product here. Just because something is made in China does not exempt it form consumer protection laws here in the US. Sure there is a cost to any engineering but we certainly aren't demanding enough of our programmers most of the time.
1. PHP. ...better stop there before I get modded into oblivion.
2. Visual BASIC.
3. Perl.
4. C.
5. C++.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
On the script writers deal in absolutes!
Good luck taking Biytu in Timbuktu to court.
Table-ized A.I.
"The Vendor shall be responsible for verifying that all members of the developer team have been successfully trained in secure programming techniques.
Pre-contract award, the Vendor shall document the process including training courses that their application developers have taken prior to developing applications.
Pre-contract award, the Vendor shall certify to the Purchaser that only application developers who have received appropriate level of formal training on secure application development and passed a competency test on application security shall be involved in the Contract."
Translation:
We, the security consultants, are going out of business and need to sell more training courses.
We, the managers of big companies, are going out of business and need someone to blame. You know that we will still accept the lowest bid, and we know that you're qualifications will be faked, but at least when the shit hits the fan we can point at you and say it wasnt our fault.
In drafting their contract to encourage Customers to demand of the Developers that the code is bug free, they chose to provide this at the top:
"DISCLAIMER
THIS DOCUMENT SHOULD BE CONSIDERED GUIDANCE ONLY. IT IS STRONGLY RECOMMENDED THAT YOU CONSULT A QUALIFIED ATTORNEY TO HELP YOU NEGOTIATE A SOFTWARE CONTRACT.
Please be advised that there is no warranty, expressed or implied, and no assumption of any legal liability or responsibility for any third party's use, or the results of such use of this Document."
I guess code can be made 100% accurate, but not legal contracts, huh?
I was once offered a contract for a software position with a paragraph claiming that I was responsible for making sure my code did not infringe on other companies IP or patents.
I told them I was not an expert on the matter and the responsibility was that of the company managers/lawyers. I returned the contract with a line through that paragraph and my initials. They did not hire me... maybe because of the contract changes. But who really cares? I wouldn't work for a company who offloads their legal liability onto their employees.
side tip: you can rewrite any contract handed to you... even bank account contracts (I have)... and usually they will accept it and file it away. If they don't then you have the option to walk away or suck it up. In that case: walk away!
I believe that most buffer overrun exploits work by overwriting a function's return address on the stack. These could be largely avoided by the compiler using either of two techniques. First, it could grow the stack into higher numbered addresses and store the return address first. Now if the code allows a buffer overrun, it will overrun the local variables and spill into the available stack space. In both cases, the chances of finding a function pointer are small. In contrast, if you grow the stack into smaller numbered addresses, then a buffer overrun has pretty much 100% chance to overwrite a code pointer (the return address).
The other technique is to use two stacks, one for the return addresses and another for the parameters/return values. Same idea though: move the return address out of the way of the overflowed buffer.
You are absolutely wrong, you are 0% right and you are a fucking communist.
These ones look like they could be off-by-one errors.
3. Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
12. Buffer Access with Incorrect Length Value
14. Improper Validation of Array Index
17. Integer Overflow or Wraparound
18. Incorrect Calculation of Buffer Size
Only 5 out of 25? Has the dreaded "off-by-one" error lost its teeth?
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
is it me or is americans in love with absolutes?
Except when it comes to grammar.
Tragic, yes. And entirely preventable if the people in charge had listened to the engineers and scrubbed the launch. Actually dovetails nicely with timmarhy's comment.
I prefer rogues to imbeciles because they sometimes take a rest.
... I have to find a new job
tyoup.