The Peon's Guide To Secure System Development 347
libertynews writes "Michael Bacarella has written an article on coding and security. He starts out by saying 'Increasingly incompetent developers are creeping their way into important projects. Considering that most good programmers are pretty bad at security, bad programmers with roles in important projects are guaranteed to doom the world to oblivion.' It is well worth the time to read it."
Engineers (again...sorry) (Score:5, Interesting)
If Microsoft's products are so good, why do they disclaim liability on it?
Of course it isn't just microsoft doing this either. The whole licensing thing. If a 'license' is supposted to give you the privledge to do or use something, then in most things you are completely liable for your actions. For example, I have a drivers license, I kill somebody it is my fault. If Acme's Nuclear Control Software 2002 goes faulty and blows up part of the states - they would probably claim no fault (bad example I know - special case currently probably).
Re:Engineers (again...sorry) (Score:2, Funny)
*In 1942, the U.S. Supreme Court in Chaplinsky v. New Hampshire defined fighting words as words which are likely by their very utterance to inflict injury, or which tend to incite the average person to immediate violence. The high court said that fighting words receive no First Amendment protection.
Re:Engineers (again...sorry) (Score:3, Informative)
Most certifications are nothing more than an economic barrier to entry: A club, if you will, whose membership betrays zero information about the capabilities of their members, but rather excludes those who haven't signed up. P.Eng is a particularly notorious one because they've tried to get their grubby hands on virtually all aspects of society, while provably offering nothing in return. No thank you. I don't need a "P.Eng of Burger Making" to make my Big Mac, even if that does help Bob get his friends a job through his exclusive club.
Re:Engineers (again...sorry) (Score:3, Interesting)
And since you are in Ontario, which is where I got my engineering degree you should know that money is not the issue to getting an education.
Also engineering certification does not mean quality. It means that you studied so many years and have gone through specific procedures. Just like police people and fire people. Some police people are good and some are baffoons, but regardless you know that they have gone through police trainning....
When engineers become liable for stuff that they design, people design very DIFFERENTLY. This is not to say that everybody has to be an engineer to work on software. Just like in a custom machinery shop not everybody is an engineer. You just need enough engineers to sign off legally on designs.
Re:Engineers (again...sorry) (Score:2, Insightful)
Re:Engineers (again...sorry) (Score:2, Funny)
High level languages (Score:2, Insightful)
All of these languages use a C program to
run.(interperter, VM).
First this guy suggest against useing
close source components are components
that you do not understand.
Well, what are these high level languages that
he is suggesting. There just a convinent
ways to write C. (Java excluded)
Maybe he thinks that you should read through
the ruby and python source before you
start using these languages?
I think he's suggestion is the reason
we have bloated unsecure software,
everyone trust that there languages
is in a little black box just because
it has a VM. What if the VM has a security
flaw, isn't this just like running a
secure program on top of windows.
Just keeping a developer from using pointers
is no way to insure a projects security.
Re:High level languages (Score:3, Insightful)
For example, try Common Lisp [cons.org], Objective Caml [ocaml.org] or Ada [gnat.com] (not that high-level, but not the worst idea if you care about security).
Re:High level languages (Score:3, Insightful)
Using a high level language is the best kind of software reuse. The reason behind this is simple, chances are good that you are never going to be as talented as Guido van Rossum or Larry Wall. Nor will your data structures get as many eye balls examining them as Python lists or Perl arrays. Borrowing the work of the hackers that created some of these languages only makes sense.
Now, I am not saying that these programs don't have bugs, because they do, but I would bet that they have less bugs than anything you have ever written. So while using high level languages doesn't insure security, it certainly does help.
Re:High level languages (Score:4, Informative)
When you critique someone's work, it is customary to first read it in its entirety. Besides the fact that it's just common courtesy, if you had read just one more paragraph you could've prevented yourself from committing such an egregious faux pas.
In other words; if you're going to insult someone don't reveal what a stupid twit you are in the process. Dumbass.
High level languages like Ruby, Python, or even Java are strongly recommended for all new projects. The reason these languages are more secure (in theory) is that they don't have pointers. Most security vulnerabilities that involve breaking program code involve manipulating pointers-in fact, many programming bugs are generally related to pointers in some way. As with the OS issue noted above, do not mistake this for invulnerability. You're simply less likely to be compromised using this particular attack vector with a high level programming language.
Re:Engineers (again...sorry) (Score:2, Insightful)
You can say the same thing for a bridge. It will only stand if all the parts of construction are good, which the developer (not the engineer) are in control of. If the design is inherently flawed, the engineering firm will liable. If the construction is flawed, the developer is liable.
The difference between software and your analogy is that the engineer/developer has complete control over the whole system. Developers don't. Microsoft doesn't. If the user of that same bridge goes and replaces all the rivets used, the developer can hardly be blamed when the bridge fails because of this.
If I build a huge structure right in the middle, and you build another, and CowboyNeal builds a third, much smaller building, and suddenly the bridge collapses, whose fault is that? The bridge developer? Me for starting the trend? CowboyNeal even though his was the smallest?
and then when we bring security into play, that is a whole different ball game. The engineer doesn't have to worry about people activly trying to make his bridge fail. If someone (say a tterrorist) plants shaped charges to destroy the main supports, and the bridge collapses under its own weight, no one would even think about sueing the engineer (except for maybe the lady that dumped coffee in her own lap, and somehow thought McDonalds was at fault).
In software systems we rely on everyone else to be well behaved. We also rely on the combination of everyone elses systems not interfering with our systems in unexpected ways. A system of mine could run fine without a single crash. A system of yours could run without a single crash. Together they might get spurious crashes. I have never had a crash on a fresh install of Windows while playing Freecell before I install anything else.
The same idea of liability can't be applied to software systems.
Re:Engineers (again...sorry) (Score:5, Insightful)
Because the customers don't want to pay the added cost of reliability beyond what they need. If you want absolutely, positively bulletproof software, you're going to have to pay a higher development cost (mostly in testing, but in extra liability insurance for the company too). For safety-critical applications, customers are willing (or should be willing anyway) to pay for the additional cost , but it's ridiculous to pay for it when you don't need to. Do some googling on the cost of the space shuttle software for instance...
Re:Engineers (again...sorry) (Score:2)
Re:Engineers (again...sorry) (Score:3, Informative)
Why Mainframes Rarely Crash [byte.com]
Re:Engineers (again...sorry) (Score:2, Informative)
Re:Engineers (again...sorry) (Score:2)
er, client / server (Score:3, Insightful)
Tell me, what is the compelling business reason for using windows that prevents me from using anything else in a corporate environment?
There is only one answer (or is it three?):
"Fear, Uncertainty and Doubt"
And that's one feature we can all do without!
things can be done with its credentials - nop (Score:3, Interesting)
plan9 offers a model that doesn't require trusting the client. It runs a dedicated authentication server and a dedicated CPU server and a dedicated file server. The three talk to each other behind the client's back.
http://plan9.bell-labs.com/sys/doc/auth.html
Re:things can be done with its credentials - nop (Score:3, Insightful)
Re:Engineers (again...sorry) (Score:2)
Doesn't need to be bulet-proof. But they should be liable for negligence, or for overstating their security. If the product is not meant to be used in a secure enviroment and with certain limitations and certain controls (say following an ISO standard), it should be stated in the license or outside the box (or somewhere).
If you get roOted, it can depend on a thouthand things. If the reason is because there was a huge hole in code and the company did not patch in 1 day (to name an example) they SHOULD be liable.
What companies want is a declaration of how secure the product is and a statement about how will a hole be handled and what to expect and how to proceed. The we fix as we go and don't blame us, but nonetheless we claim our products are as secure as everyone's else is unfair.
Not only that (Score:3, Insightful)
Real verified reliable design are, by necessity, very unflexable. You have to verify all the components and make sure they work together to insure that one won't cause problems. You then can't change the components, with out reverfing.
This just doesn't work for a desktop, where the user expects to be able to operate the system as they desire. that means that peopel can, and will, find combinations of software adn hardware that will fail. Hence, a software company can't gaurentee reliability in that situation.
Re:Engineers (again...sorry) (Score:2)
Well, let's see:
1.) MS has millions (like many many millions) of people using their products. Even a small percentage of liability could lead to bankruptcy.
2.) Lots of ppl hate MS enough that they malisciously work to create problems with it. (Nimda, Melissa, etc...)
3.) Windows based machines are built from a broad variety of hardware that MS cannot possibly vouch for. If Windows is unstable as a result of a bad driver, blame wil be misplaced.
Your wife's in-laws? (Score:3, Funny)
Wouldn't your wife's in-laws be your parents?
Sorry, couldn't resist... :-)
-B
Bad Programmers == Shitty Salary (Score:2, Insightful)
They're just paying for what they get. I tend to believe that its not so much bad programmers as it is a general apathetic attitude that good programmers have now. If there's no incentive to bust your balls, you're not going to!
Programmers are overpaid as it is! (Score:3, Insightful)
However, these people who are no more qualified to write code than a third worlder with no previous formal schooling trained to be an H1B in a cert mill -- yet are paid much more, for no good reason.
If anything, regular programmers who would ever, for example, use PHP's fopen() for a proxy like the article described should be paid like H1Bs and school teachers -- about $35,000 a year, at the most.
However, the ones who really know their shit -- like Mr. Bacarella -- should be the ones making $100,000 a year or more.
So basically... (Score:5, Informative)
He read a few books on the subject, and summarized the most simple concepts in an article.
Nothing new here.
Head to Amazon and find some books
Software Project Survival Guide by Steve C McConnell (Paperback)
Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs by Steve Maguire (Paperback)
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks (Paperback)
The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt, et al (Paperback)
Re:So basically... (Score:4, Funny)
Also holds the world record for "Shortest Book".
Re:So basically... (Score:2, Informative)
Anyway, here are a few more suggestions for books that apparently go beyond the basics:
Any others?
Re:So basically... (Score:3, Informative)
Why do I find that title funny?
Seriously now, I had the good luck to find and buy that book about 4 years ago, ever since I always go back and check some of the insights there. There's pretty much everything you need to write solid C code that's bullet-proof and easy to maintain/upgrade. Too bad they don't use the book in-house more often.
If something like Windows plays any part at all .. (Score:5, Interesting)
A non-Windows system is not a guarantee of invulnerability, but keeping a Windows system is guaranteed to put you at risk.
The real world seems to agree with him on these.
But why does Windows feel the need to ... (Score:2)
Not to mention Windows own unique security flaws.
Custom SW a huge security hurddle.. (Score:2, Interesting)
It wont matter much (Score:5, Insightful)
until you can get the COMPANY liable for their software claims. and make their claims open and public, not buried in legalease.. I.E. if you dont want to be liable for it not working then the packaging must state "MIGHT NOT WORK" on the front in big letters.
until then it will not change... not in commercial software anyways...
Useless advice? (Score:3, Insightful)
?????
While I have taken this out of context, its not worthwhile to dispense with systems coding issues - thats exactly where most security problems start and need to be stopped. Anyone can be safe in a sandbox.
Re:Useless advice? (Score:5, Insightful)
You can tell the difference between a developer who gets it and one who doesn't because the developer who doesn't get it is content to build a custom system using closed source components that they cannot understand, let alone keep secure.
when he goes on to say that
High level languages are usually more secure than C/C++
High level languages are built on layers and layers of things written by other people, things that you know nothing about. If you use C or assemlber, you're much more likely to be in control of the security of your code.
I guess the comment about C/C++ is aimed at coders who suck more than average; they're certainly better of using code written by other people.
Re:Useless advice? (Score:2)
bad coders (Score:2, Insightful)
Everyone has to start somewhere. (Score:5, Insightful)
I was a shitty programmer out of college and after moving between various jobs I learned along the way.
Business works by getting the most for the least amount of cash. Unfortunately most businesses don't have competent managers that can tell the difference between anything applicable in the real world and a buzz word they just read on CNet (most technical conversations are over their heads). That is my experience anyway.
Re:Everyone has to start somewhere. (Score:2)
Realize, though, that's it's often the so-called experienced programmers who are making mistakes, and these are the people that the article is criticizing. The newbie programmer will write a typical program in Python, because it's just so much damn easier. The e\33+ programmer will write it in C++, because C++ is a Manly Language. (In case you didn't read the article, one of the key points is that languages like C++ should be avoided.)
a good read (Score:5, Funny)
Call yourself a computer professional? Congratulations. You are responsible for the imminent collapse of civilization.
and
The user is pure evil.
Very true and sometimes misunderstood bits of information.
Re:a good read (Score:5, Funny)
2) Civilization is made up of users.
3) Computer professionals are responsible for the collapse of civilization.
4) Computer professionals will therefore destroy all evil.
Re:a good read (Score:3, Funny)
1) Users are pure evil. (Given.)
2) Civilization is made up of users and computer professionals. (Assumption)
3) Computer professionals are responsible for the collapse of civilization. (Given.)
4) Computer professionals will therefore destroy all evil and take themselves out in the process. (Conclusion.)
Jason.
Re:a good read (Score:2)
Would we then be considered self-sacrificing heroes or self-destructive villains? Hmmm, such a fine line here.
Of course... (Score:3, Funny)
"What you need doing? Daboo!"
going back to minding my fortress now...
m-
You get what you measure (Score:5, Insightful)
I used to work at a software house, and I noticed our code always adapted to whatever the organization cared about. When they cared about timeliness, we gave it to them, but the bug count went up. When they cared about a low defect rate, we gave it to them, but the volume of code (completed feature set) went down. When they cared about maintainability too, they got that, but app performance suffered.
Most competent programmers can probably make meaningful conributions to secure apps, especially if the efforts are led by good architects. Not everyone has to be the best. The only thing is, whoever is commissioning the software has to rank security (which includes a low defect rate) above timeliness and feature count. If that's done, most programmers can rise to the challenge.
Don't blame the programers. They're just adapting to their environment. They do have to put food on the table after all, so they'll do what their companies value.
Re:You get what you measure (Score:4, Insightful)
Look at airbags in cars, the government doesn't mandate side impact airbags, but some manufacturers put them in anyway because it's a selling point that some of the customers care about.
Now, I'm sure someone is going to point out that maybe we should have gov't enforced minimum security standards. However, I'm skeptical that government would be capable of doing it sanely right now.
Better languages (Score:3, Interesting)
High level languages like Ruby, Python, or even Java are strongly recommended for all new projects.
How about a high level, compiled language with static typing like Ocaml. More speed, more protection, and it's been officially certified as "The programming tool of choice for discriminating hackers".
Ocaml [ocaml.org]
So what about existing code? (Score:2)
Now how many Ocaml coders are there out there? Five thousand? Actually that number is probably generous. Just fess up that no one cares about this language regardless of its benefits. Its added to the list of Lisp, Haskell, and all of the other languages that could save the world if we just adopted them.
Even then, Ocaml does nothing to secure the monstrous existing C/C++ code base.
When coders run out of answers, they often resort to blanket claims of utopia delivered by a mysterious and obscure language.
Re:Better languages (Score:2)
Strikes me that a lot of code out there has to be written in low level languages because of the application, and ironically, these applications may just be the ones that need securing the most (think of a cascading failure in a router for example, depending on the data and network, it could be very very bad).
I could be entirely wrong, and embedded OCaml might exist - if not, I'm sure it's been though about - but I just don't see how it can work for embedded code (well, I guess you can abstract the device interaction from a core written in OCaml, but that still leaves the IO risky - that's probably where you want secure code right?).
What hubris. (Score:5, Insightful)
With such trenchant insights as "Don't use C/C++"! "Don't use Windows!" "Watch out for user input"!.
Wow. How truly insightful. I'm not even going to bother pointing out the utter absurdity of claiming that using or not using C/C++ has anything to do with it, or the added security problems with using high level languages (do you trust the implementation?).
I'm just going to say I've had bloody poops with more useful information in them than this article.
Re:What hubris. (Score:5, Informative)
Here is his professional experience on projects [bacarella.com]. You can actually see his code and the depth of his work is not at all impressive.
Re:What hubris. (Score:3)
A: I agree with everything he says in his article, and it obviously isn't obvious to most programmers these days, thus insightful.
B: Skimming through random code of his, it does seem that his code doesn't live up to such high standards that he may claim.
A: If you just look at the huge amount of high-level projects written in low-level languages such as C and C++, and the sheer amount of bugs, you can see he has a point.
High level languages may have implementations that add security risks, but the languages themselves make it harder to accidentally express bugs, including those that generate security flaws. A language's practical security value can be measured by the security level of its implementations. If you look at CPython's implementation (The one written in C), for example, you see some very good code, written by very good hackers. I have no clue about the bug-levels in Python systems like psych, Jython, or others, but they are probably of adequate levels. Perl has been around long enough to have probably been debugged as well.
Java is new and has some seriously crappy implementations with lots of bugs. But out of the vast amount of implementations, some must be safe.
Adding the language implementation code, is similar to adding any type of code to your project (libraries, system calls, etc). However, language code is probably better debugged, and only a very small base of its implementation has to be debugged for pointer flaws and indexing problems to be eliminated.
There is almost no doubt that Python has (nearly?) no pointer problems or indexing errors in typical configurations in its official sources.
B: Just skimming through his "light, secure, lightning-fast HTTP server" code, I saw some ugliness right off..
Using integers for enum values (even when an enum is declared!). Using complicated pointer arithmetic, where a simple indexing "for" construct can be used (to eliminate error-proneness). Using a static array of pointers to structures, malloc'ating each entry: This is combining the evils of static allocation (limited size, unused bytes for lower cases), and the evils of dynamic allocation (complexity of pointers), the need to malloc'ate (slower than not doing anything), memory fragmentation. Ofcourse he should have used a dynamically growing array of pointers (preferrably one implemented generically via macros/or void* lists, to reuse debugged code), or a static array of structures, but appearantly his code is second-class.
To summarize: while I think his code isn't the best, I do agree with the points he makes, and according to your claim that high-level languages cannot help security, I think that you are probably worse off.
Peon?! (Score:5, Funny)
Peons, indeed
Re:Peon?! (Score:2, Interesting)
They're puzzled wondering why their network is sorta-broken. Most web sites work just fine but some don't. Everybody can send out e-mail, but people are complaining that the messages are bouncing half of the time.
When they discover they've been black-holed, they don't understand why they're being punished for the actions of spammers that they think are out of their control. They want to what they spammers are doing with their network to be illegal, and they want the lawyers to make the problem go away.
Oh, all the trouble a little security knowledge could save.
Exactly! (Score:2)
That's precisely why the IT deparment of my company is setting themselves up to fall apart. My group's lead tech (lead not because of higher knowledge, but because he's hung around a while and sold himself) is convinced closed source is better. His arguments come from quoting Microsoft's advertising and web sites (which are basically just more advertising). Without even trying anything open source my company has whole-heartedly adopted
Ignorance may be bliss, but only for the person who's ignorant. They're happy... I'm not.
Oh, come on now... (Score:2)
"...Considering that most good programmers are pretty bad at security, bad programmers with roles in important projects are guaranteed to doom the world to oblivion..."
My!
We are the important little center of the universe, aren't we!
Oh! this is just book-marketing bullshit?
Or maybe hyperbole, if the author is literate to know what that word means...
t_t_b
Huge middleware isn't such a great idea (Score:2, Interesting)
We got stuck with the package because the client chose it, and refused to admit they were wrong. When the project when 10X over budget and people got fired, they still stayed with the graphics package and even upgraded it to the 2.0 version.
The only way out was to quote them an astronomical figure for upgrading our software to match the POS and hope they wouldn't bite. I cheered when they politely declined.
It's good to have a job where you can choose your clients.
It should be a acrime to teach C/C++ (Score:5, Insightful)
It should be a crime _not_ to teach C/C++. (Score:5, Insightful)
It's also very hard with C/C++. The most you break on any system without very broken protection-handling is the faulty program itself.
The reason Java is taught as an introductory language is that it was stylish about 5 years ago. The reason C# is taught as an introductory language is that Microsoft threw a lot of money at universities to teach it, and at marketing to attempt to make it stylish.
It boggles my mind that people in second-year programming courses at my university don't know what a pointer is, because it wasn't covered in their first-year programming course (which used Java).
Languages with built-in safeguards are great, if that's your primary concern, but programming courses in university are supposed to teach you about all aspects of programming that you might reasonably encounter. If someone graduates without knowing how to debug memory errors and then has to maintain a C++ program, God help us all. This is also why we're forced to learn Lisp/Scheme and exposed to Fortran at some point - exposure to the concepts is what's important.
As far as what's used in industry is concerned, first likelihood is whatever the shop has used for the past several years (anything from VC++/VB down to Cobol, depending on where you're working), and second likelihood is whatever the industry fad was when upper management was setting up specifications.
You can't obsolete C/C++ yet (Score:2)
High level languages are great for high level problems. Low level langauges are great for low level problems. Use the right tool.
That's great, but what about the real world? (Score:2, Insightful)
This is precisely why Java and C# SHOULDN'T be the primary teaching language at any serious institution. It doesn't just encourage bad habits in memory management, it breeds ignorance of the CONCEPT of memory management. I'm extremely glad I had a good background in C/C++ (and even some Pascal before those) before I ever learned Java or Python, or I wouldn't have a clue about half the concepts that a good C background forces you to learn.
Re:It should be a acrime to teach C/C++ (Score:2, Insightful)
IMO, this is part of the problem. Languages should not be taught. concepts should be taught,a nd those concepts will translate to any language. People are coming out of schools having only been taught in Java (C# / whatever) and have no concept of things like memory management, buffer overlows etc. These folks have never had to think about these issues before because they only wrote Java code in school. When these people get out into the industry, they will almost certainly have to maintain some code at some time that deals with issues like this. Sorry, but the world doesnt revolve around all of these high level languages yet. There is a lot of C/C++ code out there in the real world that will need to be maintained for many years to come. We haven't managed to kill off COBOL yet after all
Also, as others have mentioned, coding in these high-level languages can give you a false sense of security. Do you trust your Java implementation for example? Are you willing to say for certain that the JVM doesnt have any buffer overflows in it
Re:It should be a acrime to teach C/C++ (Score:3)
Languages like Java and C# give you controlled, well-known failure states for certain categories of bugs (you can still walk off the end of an array hosing your program, but the behavior is well defined, unlike C or C++). These languages also restrict your ability to specify unsafe things, but in doing so they take away your ability to specify certain useful ways of doing things. But there are still huge numbers of ways to put bugs into your programs in any language. Java and C# are not magic bullets, they're simply points along a spectrum of safety, power, and expressiveness.
Brilliant idea!?! (Score:2)
I guess we better throw out everything other language, since these are "strongly recommended for all new projects." Here's a better idea: why not just write the software in the language best suited for the job, or that you're more familiar with, and code it to check for unexpected data.
Wrong approach (Score:5, Insightful)
This guy is a little rough I think.
High level languages like Ruby, Python, or even Java are strongly recommended for all new projects.
This sentence should be continued "..for mediocre programmers.". Professional experts should use whatever language they are best at as long as it's reasonable for the project.
This article looks like he's giving advice on how to take a group of wanna-be progammers and try and get useful results from them. I think that's the wrong approach. What you should do is hire real experts. That way all the wanna-be programmers won't be able to get jobs and so they might realize "hmm.. maybe I should go back to school and get some real skills". Then we wont have as many of the problems that this guy talks about. Though maybe the schools aren't teaching the skills properly, but that's a different topic.
Re:Wrong approach (Score:2)
We Need To Consider 1980s DOD Practices (Score:5, Insightful)
Don't use the latest and greatest. Use something that has been in production for several years and has had the bugs worked out. The military used to do this on critical systems. Did I hate coding in Jovial on a machine that only had 64K? Yes. But I also knew the machine inside and out and had hand-checked the compiler's assembly code generation to make sure that it wasn't doing silly things. It didn't, because 5 years in production had wrung out all of the bugs.
Re:We Need To Consider 1980s DOD Practices (Score:2, Funny)
We're talking important stuff here, like e-mail and P2P networks, not silly ICBM toys
Now getting into a more serious attitude, the DOD has always done things in a way which is completly different from Corporate America, and Consumer America, where 2.0 is much better than 1.5, because it has more features, nicer GFX, whatever. Ohh, and 8.0 is much better, even if there was never a version 7.0, or 6.0, or 5.0, etc.
Do you guys think that the Marketing people as Microsoft were thinking about security when they gave the 8.0 number to the new MSN?? Unfortunatly, this is a marketing world, and the best marketing almost always wins. And if the loose, the marketing people try to make it look like they won anyway !!
Not an option in industry (Score:2)
Added to which, using outdated hardware is never an option in industry. You must write to you user's platform.
Re:Not an option in industry (Score:2)
Just what we need... (Score:5, Insightful)
Re:Just what we need... (Score:3, Insightful)
Is his point that people need to be more serious about security? Fine. But he's utterly unqualified to be giving technical advice or making technical judgements on a field he obviously knows nothing about (use Python, Ruby, or Java and never C++? I call buzzword bullshit bingo!) other than the vague general knowledge a "technologist" would have.
It's like me saying plastic surgery has become dangerous because there are so many quacks, and they all need to sharpen their scalpels and pay attention to sterility.
Very Good Work (Score:2)
This is one of the best all-around security articles I've read in a long time. If even 10% of the world's programmers read this and take it to heart, the world will be a measurably better place.
Re:Very Good Work (Score:2)
salt on the glass.... Big grains of salt! (Score:2, Insightful)
I hate to break it to this guy, but this article is basically a big rant of his personal opinions. Not that I have anything against that, but I feel anyone heeding this person's advice unerringly would be making just as big a mistake as if they didn't listen to any of his advice.
Open-source, closed-source, it doesn't goddamn matter. The fact is, code is written by humans, and is therefore imperfect. Realize that now and save yourself a lot of time. Open-source continues to have just as many flaws in it as closed-source. How many times has the bind package been updated in recent memory? And don't start the "many eyes" thing again, we all know it and we're all tired of it, and I realize open source gets fixed faster.
My point is, when I first got into Linux, I took a default install of Red Hat and threw it on there. I had read all sorts of advice that if I wanted a secure server, I should use *nix, so I did. Yeah... rooted. Rebuilt the box, using a way newer distro... rooted. My failing was trusting the code implicity based on what other people said. Old versions of open source stuff are just as vulnerable as old versions of closed source stuff! And you know what? I guarantee that this will always continue to be true.
Constant vigilance is your only safe-guard. The open-source/closed-source argument is secondary to this. If you can build, deploy and maintain a closed-source based system much easier/cheaper/faster than an open-source one, well, balance that against your security requirements.
Article missing key point (Score:5, Insightful)
Quality and security of a commercial software product is a financial decision, not a technical. Much like how software architecture is a strategic and not a technical decision, which many software developers do not realize.
When the cost of continuing to improve quality and security exceeds the income from support contracts, you have to draw the line. If you don't provide or charge for support, you draw the line when your investment exceeds your targeted income projections.
There are software products that are secure and virtually bug-free, but you and I can't afford them. They run nuclear plants, space shuttle command centers, etc etc. Hundreds of millions of dollars have been spent on that software, and it is not a question about "the user is evil". It's about having a thorough and mature development process and organization, preferable at CMM level [cmu.edu] 5.
So, I really don't know where the article would apply. Maybe when writing simple VB games for your website. Absolutely not when writing commercial grade software.
Re:Article missing key point (Score:2, Interesting)
I just spent the last 3 weeks cleaning up crappy programming from one of my project-mates. Pick something - not closing db connections, 18 points where infinite loops could occur (!), 48 cases where error points are ignored they didn't exist, and the program continues. In a program that is 60Kb of bytecode! I'm already rewriting code, and this is the first release!
This is not a low budget, miniscule project. But still, one bad grape and the whole bunch goes. Time and time again.
So for everyone chanting "hire experts!", count the number of truly solid programmers you know, and drum up a percentage against those you know that suck. For a while there, the industry was stretched across ALL of those people, good and bad, and dying for more techies. Do you really think that the good developers (i.e., the ones who know to slow down and get it write the first time) can take up the entire load? Do you think industry is gonna wait for these experts? Now how about CMM level 4+ rated groups versus all those developing code. Rinse repeat.
On a more humorous note, the budget problems would probably all disappear if it weren't for Slashdot, but I'm not exactly out to kick my habit...
Buffer overflows (Score:2)
For my application [maradns.org], I have made a special string library which is resistant to buffer overflows. Instead of a string being a simple pointer to a string of characters, terminated by a null, a string is a structure with the following information:
Some other practices:
- Sam
Who the f*ck is this guy, anyway? (Score:5, Insightful)
Qualifications?
Let's see...
Wow! Pretty exceptional, don't you think?
'bout the only thing going for the guy is he *doesn't* have a blog...
How the f*ck did this nonsense get put up on /. anyway?
What changed hands to get this deal done?
t_t_b
Re:Who the f*ck is this guy, anyway? (Score:2, Insightful)
Quote:
It should be a crime to teach people C/C++.
Then further into the article:
Whenever possible, use industry standards. For example: POSIX, ANSI C, OpenGL, SQL, etc. Resist using non-standard extensions, if you must have them, keep them limited.
I feel for his clients. Slashdot blew it on this story.
Enjoy,
Re:Who the f*ck is this guy, anyway? (Score:2)
The Slashdot crew MUST BE using a magic 8-ball to decide what stories go up, and which do not.
That's the only explanation I've got.
Re:Who the f*ck is this guy, anyway? (Score:3, Insightful)
Re:Who the f*ck is this guy, anyway? (Score:3)
Seriously though, this is one of the worst rants I have read. First of all, his claims about closed - open source are nonsense. He says that noone at Oracle could possibly understand the 1.2 GB codebase, and then says we should all understand every process on our own Linux box. Ummm.... And if my Linux box runs Oracle??
We trust our OS'es to be reasonably secure. Whether it is Windows or Linux or Plan9. Linux can be more secure due to it's open source nature. Conversely, one could state that Since Windows is the dominant OS, IE the one most attacked, it could evolve to be more secure than an OS that is rarely attacked.
I recall that in the last PC Week "Hack our Honeypot" contest, the Linux system was hacked long before the WinNT box, because the software was open source and could be combed for vulnerabilities. Is open source still more secure??
I am not trying to say that Windows is better, Linux is better, I'm just saying that when you make sweeping generalizations about design methodologies relating to product quality you deserve to be lambasted as an Idiot. Open source is not inherently more secure than closed source. Period. Yes you can review the source of open source, but who really does?? And for evey package, every revision?? Most OS'es are simply too complex for one person to get his/her brain around. Same for the Office suites and databases. I'm sure some Yakoff will shoot back that understands all X million lines of Open Office, but I doubt he will be telling the truth. Most folks can't be bothered to read the EULA, (this includes most engineers) but they can read the full source for sendmail??
Also, are we talking about the OS or its applications?? Outlook Virii are the by product of Outlook, not Windows. IIS is responsable for its own security bugs. The only real Windows Components I can think of with security problems outstanding is Shatter attacks on the COM subsystem (Local) and the remote help exploit. (Easily fixed.) Most of the other attacks can be avoided by having the latest patches, turning off the time service and UPnP, and not using IIS. (In linux it's: sendmail, bind, etc...)
OK, to qualify for the Linux Zealots out there: Linux has had more security advisories this year than Windows. (See earlier story) Many Windows "Security Vulnerabilities" require user interaction from outlook, etc.
The author posits that we should only use code that we understand to the letter, but we only program in Perl, Ruby, etc... What a joke. I'm supposed to understand C well enough to understand the entirety of the perl interpreter, but I'm not supposed to program in it. Speaking of which, I should read the entirety of the EMACS source too because that'll be my text editor. So, I should be able to start Coding in 6-8 Months. OOPS! Sorry, Kernel update and I have to read the entire source and all of my device drivers, give me another month or two.
Again, we trust our OS'es to be reasonably secure. Open Source, Closed Source, it's like Democrat or Republican. Some always choose one or the other, but the intelligent choose the best one (at the time) based on common sense and trust.
One must also assume that at the ripe old age of 22 (haha) he has tons of real-world application experience. Perhaps he'll be sending letters to Apple about interface design next.... Actually, considering he has another 43 years of software drudgery ahead of him (If he manages to get a job in the industry) we should be seeing high quality software pouring off of Long Island for the rest of my forseeable life. Hooray!
Perhaps his life was aimless until 22 when he broke his head and discovered the magic of stupidity.
And all that nonsense about the end of civilization.... Takes our job too seriously don't he. Yes dear, poor software design will be the end of civilization. Lets just ignore the fact that civilization A: existed before software and computers, B: continues even in the midst of all of this bad software.
I could just keep going on this. But I will finish by saying, "How the f*ck did this nonsense get put up on
This article... (Score:2)
Yet, his article appears on the front page of /., the very "home" of the people he offends. To quote Michael:
No it is definitely not.
Open Source = Broken Source (Score:2, Insightful)
Honestly, I applaud open source. I think it can be quite a boon to the rest of the world. However, I've definitely seen enough public code that looked like it was written by a wannabe compsci major. It's nice to see this topic discussed. Open source is a powerful tool, but without good management and high coding standards it's just broken source.
Re:Open Source = Broken Source (Score:2)
However, I've definitely seen enough public code that looked like it was written by a wannabe compsci major.
That may be true, but proprietary software I've experienced on a collective whole has been, far far worse.
At least with open source you can actually look at it and say that it's trash that's waiting to fall to pieces, no?
What are bad programmers always "the other guy"? (Score:2, Insightful)
But noooo. It's always "the other guy" and "the place I used to work", etc... Bah.
Heh I love these book titles.. (Score:5, Funny)
Who is this paranoid "idealist"? (Score:2)
What does he expect? One security expert per I.T. staff to watch over their shoulder and make sure they never do anything insecure? Maybe we should train everyone on the planet as a security expert, and dedicate 100% of every available resource we have to securing software.
I understand what he's saying, but give it a rest. We take chances all the time and adjust according to the outcome.
Crime to teach C/C++? (Score:4, Insightful)
Bull fucking shit.
It should be a crime to *start* students on a protected environment like Java. Programmers who start on Java begin with less understanding of what's going on, because it sweeps too much complexity under the carpet.
I realize this argument was made for assembler when C was introduced. BUT! There was a massive shift between assembler and C, which is why that argument is not valid.
C and Java both have pointers/references. They both have functions, etc. But Java's references are hidden from the user, and most students don't have a clue about a reference.
Asm. vs. C was a big difference, but Java and C++ share so much, but Java sweeps all that complexity under the carpet. If a programmer who's only used Java gets into a C++ project, he'll fsck it up so fast it'll make your head spin.
It should be a crime to teach Java as a beginners language. It's not a bad language, but under no circumstances could it conceivably be considered a beginner's tool.
Re:Crime to teach C/C++? (Score:3, Interesting)
Most programmers have logic (Score:2)
Many have already commented on the claim of supposed security of not using C/C++. So following his "logic" - you shouldn't increase the length the length of code by 4-8 times by using C++ (my paraphrase) -- but you should write all of your own code?
Sorry, but if I agree that one person can not make Oracle (by this I assume he means the database) secure - then wouldn't multiple people on the project at least help? Maybe they can see the things that I cannot see? AFAIK, the more that can find flaws in software the quicker it gets more secure (as in nothing will sever be completely secure)
Make up your mind? (Score:2, Insightful)
I wonder if... (Score:2)
file:///usr/share/latex2html/icons/nx_grp_g.png
are intentionally broken to show how easy it is to screw up.
I dunno.
C vs C++ (Score:3, Informative)
I've been wondering if there's much difference between C and C++ in security. C seems to be most used language for system and server programming nowadays, especially in Open Source projects.
C++ has many features that forgive your mistakes. With proper string, buffer, and other basic data type classes your bounds are always checked so there can't be buffer overflows which seem to be most common source of problems. In addition, automatic destruction of objects eases memory leaks.
You can, of course, do all the same things in C, but it's always syntactically more complex than in C++. You need to learn dozens of different coding rules just to avoid trivial problems. Often you forget to apply them; each time you create a risk.
For example, just today I noticed a dangerous situation when I initialized a callback function table with: While this works quite nicely, it's secure only if the struct always contains the two items. If a new item is added to the struct, all uses of the structure would have to be updated, but the compiler might not warn about this situation. In this case, the result would probably be a program crash. A more secure way would be: This is much safer. However, in C++, this problem simply wouldn't exist because structs are typically never used and classes have constructors that always initialize them properly and user doesn't have to care so much about possible changes in the classes.
This is just one example. There are plenty more.
On the other hand, stuff is more often allocated from heap in C++ rather than stack. Memory might therefore fragment more easily in C++ than in C.
Security: Misunderstood responsibility? (Score:5, Insightful)
I don't necessarily accept this assumption. Most good programmers are good at coding up the design and requirements they've been given. The customer/architect/business analyst/technical lead needs to identify security requirements before they can be coded. It's very expensive to leave identifying security requirements to programmers. Not every project has the same needs. Sure, the programmer could guess. But each programmer on the project would end up spending a different amount of time and money on the security aspect if it's not clearly prioritized.
Likewise, if security requirements are not specified well enough, a security test-plan cannot be written or executed. If you need security, ensure it's somebody's explicit JOB on the project to ensure security gets into the design & QA.
Security costs money before a single line of code is written. Decide how much you need, where it's to be applied, and ensure it becomes a critical requirement through coding and testing. You can't expect security to just "happen" simply by hiring some "good programmers" as the author says.
Its all about the benjamins (now at least...) (Score:3, Insightful)
Re:bad coders... (Score:2)
Florescent....
Poor soul.. you need to get out more..
Re:bad coders... (Score:2, Insightful)
If the people care about security now, you can bet the companies that succeed over the next decade will be the ones that satisfy that demand.
Re:The Solution? (Score:2)
I learned how to learn when I was in college. Circumstances forced me to drop out, and I applied that ability to learn, to move forward and upward.
I don't know about anyone else, but I have had -no- problem finding new jobs in this crap economy. Why? Becuase I'm not keeping my skillset static, and I can prove I have the skills, and the experience, to get the job done.
Franky, that's what employers are looking for, right now: the skills -and- the knowledge on how to most appropriately apply those skills.
Just because you know a dozen programming languages doesn't mean that you know when to use one language over the other, or one design philosophy over another.
experience? there is no substitute for experience.