The Peon's Guide To Secure System Development

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."

Comments

Engineers (again...sorry)

[jpt.d]

The P.Eng has one thing right - we need 'software engineers' or 'computer engineers' that are liable for their work (and the company that uses them are liable for too).

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)

[ch-chuck]

I think it, currently, is tied back to US 1st amendment Free Speech protection - a book is free speech, it doesn't have to be correct. If you read a book, follow it's advice and lose your shirt or damage something, the book publisher probably has a legal protection against being held liable for it ("we just published the false information, you're the one who acted upon it"). However, yelling 'fire' in a crowded theatre or 'fighting words'* is not protected speech - we might need to tie at least some software with potentially damaging consequences to something like that in some situations.

*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)

[ergo98]

How absurd. This whole certification thing is such a tired argument, though it's one that the IEEE is revving up as a new source of income (and I'm an IEEE member, but that doesn't mean that I agree with ridiculous certifications). Certifications and licensing are not, in most cases, a guarantee of quality. In reality in many cases these licensing boards turn into self-protective entities that allow their members to get away with things that they would never get away with if not surrounding by the shroud of, err, "persona responsibility" (see some of the medical boards that act more like shields against personal responsibility). Did you know that one of the P.Eng criteria, at least here in Ontario, is that you cannot discredit another P.Eng?

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)

[varith]

You don't need to make engineers liable. It management (executive management to be precise) that needs to be liable. Hell I keep getting turned down on projects to improve the code in my company. The only way I could possibly put reeally good security would be to put 20-30 hours a week of my own time in - past the 50-60 I already work. No thanks.

Re:Engineers (again...sorry)

[ACNeal]

The problem with this is that the whole system has to interoperate together. The system is only as secure as the total of all its components working together.

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)

[aero6dof]

If Microsoft's products are so good, why do they disclaim liability on it?

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)

[wiredog]

Yes. See the April 98 (!) Byte Magazine. "Why PCs Fail, and Mainframes Don't"

Re:Engineers (again...sorry)

[fferreres]

Do they have a option? I mean, is there any competing product that will be Windows compatible? Don't tell me Linux, because it's not Windows. And Windows is a monopoly you cannot get away to not using it in a coporate enviroment today. You can at most replace some servers and selected pals workstations.

Re:Engineers (again...sorry)

[jsahol]

Agree 100%. That's the problem, you can't sell anything to mgmt unless it makes them look good somehow, and security is not as "sexy" as new features. Hence companies like Microsoft can sell the garbage they do, because they just add more bells and whistles (bloat) each version.

Re:Engineers (again...sorry)

[fferreres]

If you want absolutely, positively bulletproof software

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.

Re:Engineers (again...sorry)

[esarjeant]

I think this is the link; a good read:

Why Mainframes Rarely Crash

Re:Engineers (again...sorry)

[fegu]

It is available from their archives. Not too bad actually.

Re:Engineers (again...sorry)

[SerpentMage]

Sorry but there I think you are absolutely wrong. I happen to be an engineer, not because of an economic barrier, but because I managed to study x years in a University.

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)

[Anonvmous Coward]

"If Microsoft's products are so good, why do they disclaim liability on it?"

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.

Re:Engineers (again...sorry)

[ergo98]

I happen to be an engineer, not because of an economic barrier, but because I managed to study x years in a University.

Yet plenty of people study >x years in University and don't get a P.Eng, yet suddenly they find barriers to their professions by arbitrary membership rules. If a professional engineering designation is a signal of education, then isn't that amply filled by existing programs?

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.

No, but it's job mobility. John pursued advanced computer monkeyology and then became an expert software developer in the field of Monkeyology. Jim went through and become a "P.Eng in Computer Software", knows nothing about Monkeyology, but you're saying that John should be barred from writing software as Jim is certified? _BS_ It is a barrier of job mobility specifically to maintain exclusivity for its members. The P.Eng is trying to get its greedy hands into software development (as a mandatory element of software development, rather than a "marketforce" certification much like an MCSE or Cisco certificate), and they won't have a chance in hell.

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....

Total agree with you here (and it's common for any certification/degree/diploma), but then you say...

You just need enough engineers to sign off legally on designs

Now that's just offensive. So we have some people who have joined the exclusive club, and now they have special rights and responsibilities to look over us common folks? I have known a couple of P.Eng's who were the dumbest (literally), laziest people I've had the displeasure of meeting (note that I'm not saying that all P.Engs are. Indeed, the same group includes some of the most honourable and brilliant. My point is that the membership in and of itself means exceedingly little), but suddenly these people are a signing force for a passport? How ridiculous is that. Don't tell me about the great responsibility they take by signing something, as the same holds true for ALL OF US: We all can have careers ruined, lawsuits, criminal complaints, etc, if we sign off on something negligent, incompetently, etc.

Re:Engineers (again...sorry)

[Iguanaphobic]

MS has millions (like many many millions) of people using their products. Even a small percentage of liability could lead to bankruptcy.

Or it could lead to more secure products. If a company gets sued for faulty products, they either improve the product or they go out of business.

Lots of ppl hate MS enough that they malisciously work to create problems with it. (Nimda, Melissa, etc...)


Nope. Think of it as a chicken and egg problem. I design a well thought out, highly secure piece of software. People try and try to hack into it, but the effort required is so high and the payoff so small, that hardly anyone persevers long enough to succeed. The opposite is designing a poorly concieved, bug ridden pile of steaming crap that anyone can hack into with no effort at all. The payoff for doing so is huge, attracting anyone who can load up VB.

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.


Nope again. Blame will be placed with the system that allows a faulty driver to take out the system. That would be like relying on a wet piece of spaghetti to hold together your braking system and then blaming the braking system when the spaghetti fails.

An earlier poster raised the point that MS already has the money, they just failed to deliver the product. Now the marketplace will make them pay for that.

Re:Engineers (again...sorry)

[Bun]

Ok, as a recent P.Eng. applicant here in BC, I have to take issue with a lot of what you said, mostly because it is the sort of drivel spouted by semi-trained clowns who want to call themselves "Engineer". In Canada, the terms "Engineer" and "Professional Engineer" are restricted to individuals accredited by the provincial associations and governed under various provincal legislation, such as The Engineers and Geoscientists Act of British Columbia. I think it's similiar in the Excited States as well.

In reality in many cases these licensing boards turn into self-protective entities that allow their members to get away with things that they would never get away with if not surrounding by the shroud of, err, "persona responsibility" (see some of the medical boards that act more like shields against personal responsibility).

Um, no. If anything, being a professional engineer exposes you to a higher level of liability than the layman. Putting your stamp on a set of plans makes you personally responsible, not only for the information the contained therein, but for ensuring that the Work in question is performed according to Accepted Practises based on Sound Engineering Principles (capitalized words have very specific meanings, according to the associations). A common story (probably apocryphal) is the one where the engineer who designed a lawn mower lost his shirt when his company was sued because there weren't warnings not to place your hand under the guard of a running mower. That's probably an extreme case, but it is not uncommon for engineers to be named defendants in suits involving work they've performed, many of which don't even claim malpractice. Are you aware of any cases where so-called "software engineers" were sued for malpractice?

Did you know that one of the P.Eng criteria, at least here in Ontario, is that you cannot discredit another P.Eng?

True (it's true in the Medical Profession as well...) That's so people don't go around saying, "Stay away from that guy, he sucks. I can do it better!", and debasing the profession in the eyes of the public. If an engineer believes a practising member is negligent, poorly trained, practising out of his area of expertise, a danger to the public, etc., it is his duty to report that member to his association for disciplinary action. The associations will also listen to complaints from individuals regarding their members, and take action where appropriate. Results of all disciplinary hearings are made public, usually in newspapers.

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.

*sigh*
The requirements for becoming a P.Eng. are public. In general, you can be sure that the member has completed a degree at an accredited institution or has passed a set of qualifying exams, has a minimum of four years of supervised experience in his area of expertise, and has passed a law and ethics exam, so that he is at least aware of his responsibilities. How many people who call themselves "software engineers" can claim the same?

The professional designation, P.Eng. is there to provide the public with the peace of mind that engineering work will be performed to at least a minimum standard of quality as determined by other practitioners in the field. You spout off here saying such things aren't necessary, but I doubt you'de ever go to a doctor with a mail-order degree in holistic medicine. And seriously I doubt you'd trust yourself to drive over a bridge designed by some guy who's sole training was playing with erector sets as a kid.

Re:Engineers (again...sorry)

[ergo98]

Ok, as a recent P.Eng. applicant here in BC, I have to take issue with a lot of what you said, mostly because it is the sort of drivel spouted by semi-trained clowns who want to call themselves "Engineer".

The classic defense of the P.Eng. (or applicant): The bogus attempt to portray it as a "higher level" that is only assaulted by those unworthy of its grand abilities. I find it especially laughable that the Professional Engineering associations have decided that they can coopt a basic english word (engineer or engineering), as you have masterfully demonstrated (how dare people think they are engineering if they haven't ponied up the dough!). How absurd. These "engineers" apply some grand, wide title over virtually anything they do, no matter how woefully unskilled in that realm. You're a P.Eng even if you're performing software design, even though your training was in building bridges (oh, right....engineers are god like creatures who are masters of all).

I find it heartening that Microsoft of all people, recently threatened by the PEO, basically responded after consulting their lawyers by telling them to bring it on, and continue to title their infamous MCSE title with Engineer. The reason, of course, is that if the PEO or other Engineering associations actually pursue their ridiculous campaign to own an element of the language (as you pretend they do) they will be put in their place.

The professional designation, P.Eng. is there to provide the public with the peace of mind that engineering work will be performed to at least a minimum standard of quality as determined by other practitioners in the field. You spout off here saying such things aren't necessary, but I doubt you'de ever go to a doctor with a mail-order degree in holistic medicine. And seriously I doubt you'd trust yourself to drive over a bridge designed by some guy who's sole training was playing with erector sets as a kid.

Firstly, I won't bother trying to reason as to why doctors and engineers are worlds apart (though Engineers will immediately proclaim that they wield power over life and death, such as in the infamous bridge collapse in Quebec which the fabled ring is hypothetically forged from. They wield as much power as the guy cooking the burger at McDonalds has if he fails to cook it to a high enough temperature, or that guy driving in the opposing lane looks at his radio and smashes into you. We ALL wield the power over life or death, with the responsibility and consequences, daily). Secondly, it's called "market forces": Companies will go to great lengths to impose a process of quality to ensure that the bridges that they build and the software that they create is of a high enough quality for the job at hand. Why? Well firstly they can be sued out of existence in a civil court if they fail to, not even considering the commercial aspects of negative implementations, but secondly because ANYONE , not just the fabled heroic "Engineer" with the masterful designation, can be held CRIMINALLY LIABLE due to negligence. There is virtually no additional onus that an Engineer is taking on that every one of us doesn't in our daily lives of doing our job. Engineers just like to make a big deal about it. As mentioned: When I drive down the road if I exercise undue care I can be put in jail for the rest of my life.

You

Bad Programmers == Shitty Salary

[kevlar]

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!

So basically...

[vasqzr]

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...

[Anonymous Coward]

Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs by Steve Maguire (Paperback

Also holds the world record for "Shortest Book".

Re:So basically...

[Shackleford]

Yes, it seemed that much of the article focused on security basics, such as the importance of disabling unnecessary services and not trusting firewalls to be a security panacea.

Anyway, here are a few more suggestions for books that apparently go beyond the basics:

• Building Secure Software
• Writing Secure Code

Any others?

Re:So basically...

[FattMattP]

Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs by Steve Maguire

Please note that this book is found in the humour section of the bookstore and not the computer section.

Re:So basically...

[Koyaanisqatsi]

Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs by Steve Maguire (Paperback)

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.

Re:So basically...

[budgenator]

much of the article focused on security basics... Every profession, vocation or occupation that I have ever heard of considers the basics to be the essensial building blocks for advanced skills. Most experts in any field make it look easy because they've mastered the basics, and frequently the solution to any given problem seems trivial once the extranious information is set a side and you've gotten down to the basics

If something like Windows plays any part at all ..

[burgburgburg]

in your system design, you should probably give up now.

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.

Custom SW a huge security hurddle..

[Havoc'ing]

I work for an IT security company that does works some pretty secure systems. When we come across custom apps we are amazed time and time again how the logic was put into developing them, not just security. Its one thing to code, its another to do it well. My favorite catch was an SQL developer who created a hyperlink to care and feed his system that simply had to many bugs and pushed to production. Its important that companies have good end to end IT polices, apps, usage and security, but in large part managements dont recognize the risk until its to late.

It wont matter much

[Lumpy]

The coders are still shackled to the management that are trying to push it out as soon as it compiles and runs.. management doesnt CARE about stability or security and sales/marketing doesn't even care if it works.

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?

[Ars-Fartsica]

To quote "It should be a curse to teach C/C++"

?????

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?

[Subcarrier]

He's contradicting himself here:

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?

[p3d0]

Right on. High-level languages, for better or worse, are just another kind of middleware.

bad coders

[greechneb]

When I look back at my programming classes in college, the majority of the people didn't have a freakin clue. I don't think most of them could install a program on their own. Unfortunately the teachers all walked them through it, and they ended up passing, because they had their hands held the entire way. Its scary to think that some of them could end up in high places.

a good read

[lactose99]

I found 2 quotes particularly enjoyable:

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

[Digital Mage]

1) Users are pure evil.
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. ;^)...Cool!

Re:a good read

[Tack]

This is almost true, unfortunately I must ammend 2) and 4):

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

[Digital Mage]

Doh!

Would we then be considered self-sacrificing heroes or self-destructive villains? Hmmm, such a fine line here.

Of course...

[ultramk]

the real question that any developer needs to ask...

"What you need doing? Daboo!"

going back to minding my fortress now...

m-

You get what you measure

[Max Coffee]

I really don't think the blame can be placed on the programmers here. Software development organizations get from their programmers what they measure and reward.

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

[aero6dof]

I agree with you and would go a little further. Its not only their internal company environment, but the environment of market too. Unless customers are deciding to purchase one product over another due to its security features, software isn't going to get more secure.

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.

Re:You get what you measure

[osolemirnix]

Yeah exactly. In the company I work for, the manager chose to ignore the programmers, techs and sysadmins decision (which, not out of coincidence, were all for the same product) and went for another because it looked so cute. Regardless to say the thing turned out to be a complete crap (and lots of money wasted).

Luckily the managers superiors saw his faults and fired him eventually (but not before the damage was already done). But the worst part is that the replacement they hired is just as bad.

So I cannot agree with the article, it should read instead:

Increasingly incompetent managers are creeping their way into important projects. Considering that most good managers are pretty bad at security decisions, bad managers with roles in important projects are guaranteed to doom the world to oblivion.

Better languages

[PylonHead]

It should be a crime to teach people C/C++.

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

Re:Better languages

[Mike McTernan]

What about embedded software? I read the FAQ/introduction and couldn't see anything about embedded software. In fact, I can't see how this language would cope with embedded things, where type castings and volatile addresses are *needed*.

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.

[ProtonMotiveForce]

This "technologist" is carrying on about bad programmers and security? Wow - I assume he's a seasoned professional with many large-scale projects under his belt?

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.

[stephanruby]

This "technologist" is carrying on about bad programmers and security? Wow - I assume he's a seasoned professional with many large-scale projects under his belt?

Here is his professional experience on projects. You can actually see his code and the depth of his work is not at all impressive.

Re:What hubris.

[frank_adrian314159]

(do you trust the implementation?)

I trust a language implementation a heck of a lot more than I trust a coder. What's the ratio of compiler bugs to programmer-sourced bugs? Almost nil in my experience and I've spent 20+ years in this industry proving it :-). People who deny that basic fact are sticking their heads in a very, very dark place. The use of high-level language is to be encouraged at every turn.

Re:What hubris.

[Peaker]

There are two points I'd like to make.

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?!

[gergi]

Everyone knows peons don't care about security. They just go around doing whatever they're told to do. Half the time, they're just standing around because there's nothing for them to do. They are oblivious to security breaches... I can't tell you how many peons I've seen getting hacked to death without them even noticing! And if they do notice, all they ever respond with is "Stop poking me!!!"

Peons, indeed

Re:Peon?!

[LostCluster]

This is the same as the school system admin who sets up a mail server for the school but fails to restrict its use to only the school's IP space. Suddenly it's discovered as an open relay, published on web sites, discovered by spammers, and they find their IP space in a black hole.

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.

Re:Peon?!

[BigJimSlade]

Everyone knows peons don't care about security. They just go around doing whatever they're told to do. Half the time, they're just standing around because there's nothing for them to do. They are oblivious to security breaches... I can't tell you how many peons I've seen getting hacked to death without them even noticing! And if they do notice, all they ever respond with is "Stop poking me!!!"

That's not true at all! Why, just the other day my peons built a barracks and several watch towers. You are right about the poking thing though... they don't like that one bit.

Exactly!

[truthsearch]

Open source systems offer this power to the end user (you), that is their real strength. 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.

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 .NET. I am so out of here as soon as possible.

Ignorance may be bliss, but only for the person who's ignorant. They're happy... I'm not.

Oh, come on now...

[talks_to_birds]

...I mean, really:

"...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

[Spy4MS]

Gotta agree with him on this one. I finally got out of a multi-year project where we used a gigantic POS graphics package as the back end. It added unnecessary complexity and over a year of hacked code to what should have been a month-long project (had we coded the graphics functions ourselves).

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.

Re:bad coders...

[RebelTycoon]

and the color of the sky in your world is?

Florescent....

Poor soul.. you need to get out more..

It should be a acrime to teach C/C++

[l33t-gu3lph1t3]

I agree whole-heartedly with the first of 2 non-superfluous statements the author makes: Why do you think Java and, to a lesser extent, C# are so popular right now? ESPECIALLY for teaching? Because with Java and C#, it's very, very hard to write code that can break the system it's running on. I also agree to some extent with his position on cyptography...most serious (non-IE/Outlook) insecurities aren't based on cracked crypto - they're in buffer overflows, and weak points in code. I don't pretend to be anything but a pathetic first year java student, but I can see where this author is coming from just be reading this website once a week...

Re:It should be a acrime to teach C/C++

[vendull]

Schools are teaching languages like Java and C# because there is so much hype surrounding those languages.

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++

[ChaosDiscord]

Because with Java and C#, it's very, very hard to write code that can break the system it's running on.

If I can break the system I'm running on with a user level program, be in C, assembly, or whatever, the operating system has a bug and should be fixed. Once your running in the kernel level, well, you can pretty easily break things in any language.

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!?!

[jaredcoleman]

Here's a wonderful paragraph...

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.

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.

Re:bad coders...

[Max Coffee]

I suppose that's a factor, but most of the non-secure software in common use today was written during a mad expansion, not a recession. At that point, the issue wasn't cutting costs, it was getting products out the door before your competitors did, and left you in the dust. Ultimately, app security comes down to the company's priority list. That, in turn, tends to be driven by the priority list of the market as a whole. Most people didn't care at all about security until very recently.

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.

Your wife's in-laws?

[Wee]

One time I was in the next state visiting the wife's inlaws...

Wouldn't your wife's in-laws be your parents?

Sorry, couldn't resist... :-)

-B

Re:Your wife's in-laws?

[EvilTwinSkippy]

Doh!

Re:Your wife's in-laws?

[AJWM]

Not necessarily. We used to visit my (first) wife's in-laws a lot. I suppose technically they'd be her former in-laws, the parents and sibling of her late first husband. (He died in a car crash a couple years before I met her.)

Wrong approach

[lazyl]

It should be a crime to teach people C/C++.

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

[maelstrom]

So are OpenBSD programmers good at coding in C securely? Are they not professionals? Have they not made mistakes that comprimised the security of the entire system? What was your point again?

Re:Wrong approach

[tshak]

Spoken like a true elitist. I've worked with many CS grad's who could write code that could run circles around mine when it comes to memory management and sorting strings efficiently. But when it comes to clean OO and application design in a Java or C# environment, they Just Don't Get It(tm). Many are caught with all of the cool optimizations they can do because they understand so much about things that just don't matter in these higher level environments. To be fair, I've worked with CS grad's who are overal excellent developers, but the point is that a "real expert" need not know how to hack Assembler for your next J2EE project.

hmm.. maybe I should go back to school and get some real skills

School does not give you skills (or at least not primarily), it teaches you how to think and how to learn. School can not make you an expert, it can only give you the tools that you need to become an expert.

Everyone has to start somewhere.

[BoomerSooner]

I guess you shot out of the womb with coding skills (doubtful). Everyone has to learn in their own way. In the end if someone wants to learn to program well, they will. Otherwise they'll just coast along until it's required.

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.

[Junks Jerzey]

I guess you shot out of the womb with coding skills (doubtful).

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.)

High level languages

[Anonymous Coward]

>High level languages like Ruby, Python, or even >Java are strongly recommended for all new >projects.

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

[__past__]

There's a simple solution to both the problem of hight level languages being "just a convinent ways to write C" (and I don't see why one should exclude Java here, but I don't think that this argument is valid anyway) and them being slow. Use high level languages that don't run in a C-based interpreter. Duh.

For example, try Common Lisp, Objective Caml or Ada (not that high-level, but not the worst idea if you care about security).

Re:High level languages

[Jason Earl]

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

[ranulf]

> Just keeping a developer from using pointers is no way to insure a projects security.

From the article:
It should be a crime to teach people C/C++.
[...] Java [...] The reason these languages are more secure (in theory) is that they don't have pointers.

This just shows that the guy really doesn't have a clue what he's talking about. Bugs in software are often exploited by targetting buffer overflows or protocol weaknesses. So, whilst Java tends not to be susceptible to buffer overflows in the traditional sense, it can still be a D.O.S. target, for example, if someone gives the program input that causes it to exceed the bounds of an array and that exception is never caught.

But more insidious are protocol weaknesses. If the programmers don't understand security then any app has the potential to be insecure no matter what language it's in. The obvious example is a simple server written in Java that takes connections on a given port and executes whatever command it is passed. Is this any more secure than an equivalent written in C?

The trouble is that more and more, people don't consider design enough and just believe that whatever they write is safe.

Re:High level languages

[Jason Earl]

I agree completely. The true answer to security is not "use a Free Software OS and a high level language." If that were true I wouldn't front my Zope application server (written mostly in Python) with Apache. Fact of the matter is that Apache is a lot more battle tested than Zope, and there are plenty of cases where Zope does the wrong thing (which is one of the reasons why the developers generally encourage using either Apache or Squid as a Zope front end).

However, I personally think that "a good design" is only part of the story. Sendmail doesn't have a particularly design, but it's become pretty hardened over time. In short, I think that security comes down to a combination of design, openness, language, and the amount of use the software gets.

Re:High level languages

[defile]

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:High level languages

[Jeremi]

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

True, there might be a security flaw in the VM. But the chances of there being a bug in the VM is much much smaller than the chances of there being a bug in the application code, so it's still a big improvement over writing everything in C directly.

A good VM is much more likely to be bug free for several reasons: (a) its task is much more clearly defined than that of the typical application, (b) it is much smaller than the typical application, (c) it was generally written by people who are very good at what they do, and (d) it has been used and tested by a large number of people and organizations over a long period of time.

Re:High level languages

[ranulf]

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.

That's nonsense. Generally, (and not I'm not actually talking about this specific article in this case), if something is garbage, you can work that out without having to read through the whole lot.

As it happens, I did read pretty much all of the article, including the paragraph you quote. But the fact is the author makes a bold statement, "Avoid The Cursed Languages", when in reality the problem is not the programmer's choice of language but the fact that they haven't thought about and sepcified exactly what their program is going to do before coding it. Almost invariably, coders developing like this pay little attention to security.

In fact, the point I was raising is only alluded to in one of his closing sections, "Don't Trust User Input", certainly not given a great deal of exposure in his article.

In other words; if you're going to insult someone don't reveal what a stupid twit you are in the process. Dumbass.

Pot. Kettle. Black.

Re:High level languages

[defile]

As it happens, I did read pretty much all of the article, including the paragraph you quote. But the fact is the author makes a bold statement, "Avoid The Cursed Languages", when in reality the problem is not the programmer's choice of language but the fact that they haven't thought about and sepcified exactly what their program is going to do before coding it. Almost invariably, coders developing like this pay little attention to security.

I'm not sure how that whole section on programming languages didn't convey the exact same point. If a moron doesn't have C/C++, their potential to do damage is far reduced. It is not eliminated, it is still possible to do damage. But if you have someone who doesn't care, this is a good place to start. The article is speaking to morons as a developer who is tired of dealing with them.

Why all of the "good" programmers were offended by an article that clearly targets sub-par programmers is beyond me.

We Need To Consider 1980s DOD Practices

[DoctorMabuse]

During the 1980s, I developed software for ICBM command and control systems and for ICBM targeting. One of these systems ran on a Rolm 16-bit computer and was programmed in Jovial, assembly and Fortran. At the time, this computer was already 5 to 10 years behind the commercial state-of-the-art. However, it worked and almost all of the bugs in the computer and the compilers were known, and THAT is the key to developing secure software.

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

[malraid]

Hey...
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 !!

Re:We Need To Consider 1980s DOD Practices

[tshak]

I had a Softawre Development Manager who worked for the Joint Strike Fighter program at Boeing who had the same philosophy. We never got projects done in a reasonable time, everything was done using dated technology that couldn't do what we needed it to do without a lot of developer effort, and half of our budget went to technical writers so that we could have huge libraries of documentation that would be outdated before it was even printed. Military grade software development simply doesn't work in most businesses. Eventually he got fired and replaced by someone who allowed us to get the job done, and to this day the system has never double billed a customer, or had any other significant breaks in production.

Just what we need...

[j_kenpo]

You know, theres something to be said for ignoring articles written in a degrading way towards its audience. It does make an interesting read if you imagine the comic book shop guy from the Simpsons was the author... worst article ever...

Re:Just what we need...

[ProtonMotiveForce]

The offensive part is the platitudes. It's one big general diatribe on nothing at all. Reminds me of the preachy father from Hamlet - all words and no content.

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.

Re:Just what we need...

[greenrd]

use Python, Ruby, or Java and never C++? I call buzzword bullshit bingo!

No, it's a valid point. "Programmers" who don't understand pointers shouldn't use C++ for production code, at least not until they understand what they're doing.

Very Good Work

[photon317]

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

[photon317]

fuck off

salt on the glass.... Big grains of salt!

[Hamstaus]

If something like Windows plays any part at all in your system design, you should probably give up now. Despite being closed source, holes are discovered constantly.

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

[bigmouth_strikes]

The article is a nice read, but it is obvious that the author have little experience in commercial software production.

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 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

[955301]

Your point is noted, but the author is speaking of the collective crappiness and the fallout that will occur.

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

[Kiwi]

One of the most common security bugs is a buffer overflow. BUGTRAQ often sounds like a broken record which says "buffer overflow"; obviously coding practices which prevent buffer overflows is desirable.

For my application, 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:

• The current length of the string
• The maximum possible length for the string
• The encoding of the string
• The length, in octets, of a single piece of data in the string

I then make sure that any manipulations to the string library always check to make sure we do not exceed the maximum length; I also have a three-byte cusion in every sllocated string to insure that one-byte buffer overflows do not happen.

Some other practices:

• Only give static strings to anything which accepts format (%s, etc.) strings.
• Do not use signal handlers; or use them with the utmost care.
• Do not use the system() call.

- Sam

Who the f*ck is this guy, anyway?

[talks_to_birds]

Surf to his web site, and it's just the same old self-absorbed bullshit that so many other people put up.

Qualifications?

Let's see...

• I was born on August 28th 1980, 4PM in Long Island.
• My life was pretty aimless until I broke my arm in the 8th grade, keeping me from most sports and physical activity. That's when I discovered the magic of computers. I haven't stopped poking them since.
• My chief interest is in information science (ie, computers). This interest involves my day job, my business, and most of my recreational activity.

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?

[NullProg]

I agree, what mindless drivel. All rant and no facts.

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?

[evilviper]

I think I've figured it out... Finally...

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?

[sien]

Looks like the editors just got trolled. 'Netgraft' indeed. Perhaps this guy is a mate of the Afghan with a C64 that so intrigued Katz, speaking of which, what happened to him ?

Re:Who the f*ck is this guy, anyway?

[Dalcius]

Jesus, dude. Ouch.

Parent of the parent: read own advice column. k thx d00d

=)

Re:Who the f*ck is this guy, anyway?

[HamNRye]

A story by Michael Barcella posted by michael... One and the same??

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 /. anyway? "

But why does Windows feel the need to ...

[burgburgburg]

repeat every Unix security flaw 15 years after it first found, three times, before attempting to correct it?

Not to mention Windows own unique security flaws.

This article...

[Dot.Com.CEO]

Is written by someone without any relevant experience in the field. Someone who has not put down any specific examples / case studies to support his case. He makes a point that he has not prove and we are supposed to argue about his unfounded and unproven theorem?

Yet, his article appears on the front page of /., the very "home" of the people he offends. To quote Michael:

It is well worth the time to read it

No it is definitely not.

Programmers are overpaid as it is!

[SexyKellyOsbourne]

Most programmers graduate from state universities with no real-world experience in security, hacking, and so forth and no connections to anything that's going on -- it's simply a pass from the university of a student molded from the dirt-poor standards of a mainstream college system to a corporate programming world of laziness and no liabilities.

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.

Re:Programmers are overpaid as it is!

[pongo000]

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.

Believe it or not, there are a few of us who have decided to take their $100,000 skills and work as teachers intent on bringing up a new generation of programmers for $35,000 a year. I'm one of them (yes, I've done some coding in my life, including much of the code that brings you color images from the IKONOS 1-meter satellites), and we are trying our damndest to prevent the likes of Mr. Bacarella from polluting the world of secure and robust programming with their silly views.

Someone has to keep fighting in the trenches...

So what about existing code?

[Ars-Fartsica]

First, Ocaml is one in a loooooong line of lanugage that claiming to be safer than C/C++ while simultaneously claiming to be faster. I have not seen one new language in the last five years NOT claim to (in "some cases") be faster than C/C++, yet they never can back this claim up in the average case.

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.

It should be a crime _not_ to teach C/C++.

[Christopher Thomas]

Why do you think Java and, to a lesser extent, C# are so popular right now? ESPECIALLY for teaching? Because with Java and C#, it's very, very hard to write code that can break the system it's running on.

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.

Re:It should be a crime _not_ to teach C/C++.

[Peaker]

Universities are not about teaching you how to work. They are supposed to teach you how to learn for yourself. They should cover the basics of as many areas as possible - and this includes programming and algorithms. This is why some language must be learned, or those areas can't be covered.

The purpose in teaching Java, or C, or Python in a university is not that you leave the university ready to code, but that you can learn what an O(2^n) algorithm is, or how important it is to write good code in general. With all respect to universities, people can and should learn to use pointers, debug, and other stuff on their own spare time.

University time should be spent teaching important basics. No, not important for the industry, important for the understanding and grasping computer science - and for that, pointers are completely useless.

Re:It should be a crime _not_ to teach C/C++.

[Peaker]

On a tangent, that's why I love Perl. It's like English: it's so flexible and can be so cryptic that a bad programmer can quickly create a mess. However, following the analogy with English, a good programmer can make a masterpiece in short time.

Try Python, it avoids the first property (making it easy to write cryptic code), while still allowing the latter (letting good programmers make masterpieces in short times).

I can't wait to see Perl 6 in action. Once they improve OOP style Perl, I'm set.

AND it has very nice OOP :)

Re:It should be a crime _not_ to teach C/C++.

[Christopher Thomas]

With all respect to universities, people can and should learn to use pointers, debug, and other stuff on their own spare time.

University time should be spent teaching important basics.

Reading these two lines in succession is either ironic or saddening, and I haven't figured out which.

Explain to me how the concept of pointers, or the modes of thought needed for debugging, are not both fundamental and extremely important?

Re:It should be a crime _not_ to teach C/C++.

[Peaker]

They are extremely important for industry programming. Not for grasping the Computer Science behind it.

Re:It should be a crime _not_ to teach C/C++.

[Peaker]

Have you heard of references?
With references, you can more easily implement trees and linked lists than with pointers (See Scheme, Python, etc).

Ofcourse, references are implemented via pointers, but that's uninteresting to the computer science student, albeit interesting to the industry.

Re:It should be a crime _not_ to teach C/C++.

[staplin]

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.

Heh. Now, it's been a few years since I learned C, but I remember one of my first programs utilizing pointers managed to read and overwrite some of the memory resident OS code on a DOS box. (They were the only boxes available int he lab at that time.) It's a quick way to reduce the box to incoherant beeps and chirps while spewing bits of a memory resident executable to stdout until it grinds to an unresponsive halt.

Moving my code to a unix box later introduced me to core debugging after a segfault. What a difference that makes, being able to examine why a program used bad pointers, rather than letting you know it did by crashing the machine...

You can't obsolete C/C++ yet

[Ars-Fartsica]

Point at one competitive OS, RDBMS or graphics editing program written in Java or C#. This is why C/C++ still matters and will for many more years.

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?

[VT_hawkeye]

When all these half-trained Java-based "CS major"s have to deal with real systems of all types, including those that require memory management by hand?

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:That's great, but what about the real world?

[tshak]

That's great, but what about the real world?

The real world is using Java and C# over lower level languages. Assembly hacking is great, and so is C/C++/Objective C, but you can't expect a programmer to be a master of each layer of abstraction. The knowledge of points is useless for many programmers, and will be for the rest of their careers. A programmer!=Computer Scientist and visa versa. I know a CS guy who's quite brilliant (could probably contribute a lot to Google's search algorithms and distributed data indexing algorithms) but would do horribly developing the next J2EE app for our Fortune 100.

I will agree that Java shouldn't be the _primary_ teaching language at a university, but many CS grad's go on to become professional programmers, and need to be taught how to think at the proper layer of abstraction.

Not an option in industry

[Ars-Fartsica]

Using an obscure, outdated toolkit may get you a sense of security, but you often have a harder time hiring programmers at competitive salaries. People with obscure skills charge more. This is but one reason why many firms use the prevailing language (however it became prevailing is another issue) - because they need to aim at the widest possible hiring pool.

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

[arkanes]

SOMEONE has to use the new stuff, in order to get the bugs worked out. Hire skilled, intelligent people who stay on top of new technology and are able to intelligently evaluate it's strengths and weaknesses, as well as compensate and correct any new bugs in less-tested systems. That way you can get the benefits of new technology, and you don't need to get bitten by every bug that comes along.

Re:Not an option in industry

[Ars-Fartsica]

Or reeducate the user.

And say what??? "Don't buy new hardware" ??? Good luck outspending Intel's advertising dept....and Dell's...and IBMs.

Who is this paranoid "idealist"?

[swagr]

Guess what, every choice every entity makes regarding anything is a compromise. Security is no exception and so long as it costs money and takes time, it will never be THE ONLY FACTOR as this guy thinks it should be.

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++?

[Pyromage]

Horsehockey.

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++?

[J. J. Ramsey]

I started off with Java and perl and had to go back and learn so many fundamental, lower-level aspects of programming and computers in general. I think it's tougher to do it this way rather than starting off with something like C or Assembly.

Actually, you probably did things in the right order. Learning is often iterative. Sometimes you have to first learn the rough general picture and then fill in the details and more advanced stuff later, which is more or less what you did.

Re:The Solution?

[paitre]

Dude.
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.

Most programmers have logic

[no soup for you]

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?

avoid third party code whenever possible. Take the time and reinvent the damn wheel.

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)

Not only that

[Sycraft-fu]

But you have to have a verified design. Actually MS does offer solutions like this, inderictly, with Windows Datacentre. With a Datacentre server you can get things like gaurenteed uptime and so on. What happens is you contact an SI that is authorised to sell it, and you work with them to design the hardware and software you are going to use. They build and test the whole thing, and then sell you a gaurentee with the system and service contract. You then can't mess with the system. You can't go and install whatever software you want, because the software might break the system.

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.

er, client / server

[DrSkwid]

You don't need secure clients, you only need secure servers.

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!

Re:er, client / server

[bahwi]

An infiltrated client, considered trustworthy by the server, if a break-in of the server. Thus, to secure a server you must secure your clients. Whether it be an overflow in IE that installs a key recorder and gathers the passwords to the server of an encrypted e-mail system. Suddenly you have access to that users e-mail, and all outgoing e-mail can "come" from that user. Secure clients are as necessary as secure servers.

Make up your mind?

[kelcey]

Earlier in this article, we see the inflammatory statement: It should be a crime to teach people C/C++. But later in the very same article: Whenever possible, use industry standards. For example: POSIX, ANSI C, OpenGL, SQL, etc. Beg pardon? If we use C or C++ (industry standards, I believe), should we then be imprisoned or lauded? Or is it just possible that the author is getting a little carried away with himself? "Programming languages without mandated security don't break systems. Bad code written in programming languages without mandated security breaks systems." Kelcey

I wonder if...

[ZoneGray]

I wonder if the image links on the page, eg:

file:///usr/share/latex2html/icons/nx_grp_g.png

are intentionally broken to show how easy it is to screw up.

I dunno.

Re:"Keep It Simple, Stupid "

[arkanes]

Bah, it's only hard to do your job because you don't know what your job is. Your job is to make the environment the way the coders want it. If that means leaving everything open so the hackers can walk in, that's what you should do. Then you get all the shitty coders fired, you hire new, good coders, and you respect thier opinions and don't force them to come up with cheesy hacks like web services because you refuse to open up anything except port 80.

C vs C++

[magi]

Article says: "It should be a crime to teach people C/C++."

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:

somestructtype myfuncs = {myFuncA, myFuncB};

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:

somestructtype myfuncs;
memset (&myfuncs, 0, sizeof (myfuncs));
myfuncs->func1 = myFuncA;
myfuncs->func2 = myFuncB;

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.

things can be done with its credentials - nop

[DrSkwid]

that's the thing you see, trusting the client is plain wrong and assumptions made with that model will get you in trouble.

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

[fferreres]

If your client uses windows you need to provide a windows interface (sometimes you can get away with a web interface, sometimes you cannot. Even if you get away with it, any flaw can hamper your bussines as you have to trust that your customer is really asking you to do what he appears to me trying to do - say transfering some money).

So nope, if you need to interface with Windows you have to understand windows and try to fight back any vulnerabilities. Of course, under windows you will be using a lot of the window API so you are always at risk that YOUR application will be a problem for you.

In a client server enviroment you can't trust your client, but you MUST trust what they are trying to acomplish and who they are.

On your server it's up to you (as long as Windows can interface with it, today that is simple but don't take that for granted. Passport and other things can make it difficult for you in the future to do your own thing, not because it will be imposible, but because the USER will ask you to - the lazy user).

Re:things can be done with its credentials - nop

[fferreres]

In fact, you are trusting the client. Not blindly trusting it, but if you provided this client then they will blame you. And if you didn't provide the client (say IE) then you allowed them to access your services through an unsecure client.

Re:things can be done with its credentials - nop

[WNight]

There's a difference between trusting a client, and trusting a password supposedly typed on the client.

If you ask me for a secure unix server, it's not my business if you'll be SSHing in, or telnetting to the SSH port and working out the encryption with your pocket calculator.

Trusting the client would be if the client said "the user wants document X, I checked his password and he's okay", and you blindly trust it because you don't think it could be hacked.

Re:things can be done with its credentials - nop

[fferreres]

Agreed, but you can't walk away with "Oh I trusted the password. Our server is secure, only your info is insecure". You need to provide a secure way (client/server application) to your clients, and that includes the client of course. That's why they ask Microsoft to offer some security, because they are using Windows clients, and companies need them to be secure gateways to their server. That is, they need to be able to trust windows to offer key services like banking services, etc.

I don't know if it makes sense to you. It's my opinion.

The Humans

[3fthiandrising]

This is missing the point. Security is not a destination to be reached, but a room tempature set to the preferences of the occupants. Do you ever lock your car doors when driving through the bad part of town? Do you think that we secure our homes the way we want our airports secured? Can you not acknowledge that we all tolerate specific levels of risk in many areas of our lives? Some one had a great point when they pointed out that Nuclear power plants, the space shuttle, ICBM warz are all very secure and mature systems. Do you really think that when Joe Bloggs starts designing an autopart inventory control system, that he is thinking about preventing unauthorized access to the extent of a powerplant? Or that the building engineer for a 12x12 parking lot PhotoMart cares about making his hut as difficult to enter as a bank?

Windows

[CaptainSuperBoy]

He lost me right here,

"If something like Windows plays any part at all in your system design, you should probably give up now."

Just another piece of FUD from an OS elitist, who apparently has amnesia about the numerous past exploits in Apache, BIND, Sendmail, OpenSSH, etc. Nevermind the fact that every single Fortune 500 company uses Windows in some form. I guess they all need to give up now, their systems will never be fully secure.

Furthermore, the article says it's for developers but it seems to be filled with information for IT people - don't trust your firewall, watch out for Oracle, watch out for Apache, don't use Windows. I thought I was going to be reading an article on software best practices, instead I'm just reading a guy ranting about why IT pros should use open source. Bleh.

Worthless article

[njdj]

He thinks it's a crime to teach C++. He says Ruby is much better. His arrogance is equaled only by his ignorance.

C++ has its faults. But at least it means something to say that a program is written in C++. The language and its library are reasonably well-defined. Not perfectly, but well enough that in almost all practical situations, it's possible to say with certainty what a well-written piece of C++ code should do, by reading the said piece of code and the specification of the C++ language and its library.

This is certainly not the case for Ruby. The only way to find out what many Ruby programs are supposed to do is to run them. You then know what they do under one specific release of the interpreter, on your particular machine. Ruby isn't a programming language, it's a learning experience for its author and a toy for its users.
Any "programmer" who used it for anything that mattered deserves to be fired on the spot.

Re:If something like Windows plays any part at all

[shadow303]

> One can be hacked on any operating system by someone more clever than themselves.

Well, like the parent post said, a non-windows system is not a guarantee of invulnerability. Granted, I wouldn't call MS=security risk insightful either- it's just common knowledge.

Re:"Keep It Simple, Stupid "

[arkanes]

Shrug, you're running into the classic problem of security vrs convenience. And thats actually a policy decision, so either you have that power and it's not hard, you just tell em they can't do that, or someone else makes the decision that they can, and you better give them what they ask for. Sounds like your problem is a screwed up org chart more than the skills of your people.

My data point vis-a-vie C++

[rufusdufus]

I am personally aware that one of the largest internet traffic servers there is (top 10 or so) was written in C++ by a programmer with no training who might rate as an intermediate coder.

That system, despite being a big name, has never been compromised. Ever. [I wont name them so as to not encourage hackers to prove me wrong]

The reason for this is security through obscurity. The code is proprietary, and the code is completely custom. Hackers totally fail because they have no information about how the system works.

The system is immune to worms too, again because it is totally non-standard. Any system built with any turnkey system is going to be vulnerable.

Thus I know of a case that roundly contradicts the author's idea that C++ in the hands of beginners is dangerous.

Security: Misunderstood responsibility?

[dstone]

From the article: "Considering that most good programmers are pretty bad at security,"

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...)

[ydrol]

It seems that Security aware coding is moving towards a situation akin to the bean counters that decide whether to recall a certain model of a car ... People didnt set out to write insecure code. But usually thay have a set of requirements to meet in order to get paid. Apart from a few industries where large sums of money or human life were directly involved , meet the requirements ASAP and get paid... Even "closed source" development projects have Quality Assurace processes where some dude checks your code (whether they know what they are looking for is another issue)... But particularly with bespoke code, people write according to a set of requirements. "I want it to do this, I want it to do that..". If it doesnt I can sue/refund/get free upgrades, if it gets hacked by some snotty nosed kid , tough, that kid wasn't in your requiremnets. Security is not easily specified as a requirement and is hard to insure against (financially) .. so pretty soon you will see the emergence of "security support contracts". This is the direction Micro$oft are going in .. (sustainable revenue is good for any business) Yes, there is a wide range of programmers with varying abilities. but (apart from open source products), certain companies have realiazed they can/will charge big bucks for more security oriented support contracts, so what do they care. For non-opensource companies lack of security/defensive programming has changed from being a liability to a profit generator. Either they'll make a lot of money or open source will prevail. Also expect a lot of specialist code review/certification/QA companies to pop up "This product is independantly DeadBolt certified" and hence costs $30 more + $30 a year for the latest security upgrades...." (multiply those figures as appropiate!)

The ACM's opinion on software engineering

[Adrian Lopez]

ACM's position on software engineering is that software engineers should not be licensed as professional engineers. Follow the link for lots of reasons.

My own opinion is that liability can exist without licensing. Companies working on safety-critical projects should be careful about people they pick to work for them. They should have adequate quality control procedures in place and should be held liable for negligent behavior. On top of that you could have regulation addressing specific safety concerns as you do for car and medical equipment manufacturers.

Secure Programming for Linux and Unix HOWTO

[dwheeler]

If you want to learn how to write secure programs for Linux or Unix systems, read my freely-available book, Secure Programming for Linux and Unix HOWTO. You can get it from http://www.dwheeler.com/secure-programs.

Those were quotes from the article

[burgburgburg]

Quotes I felt best encapsulated the opinion of the author.

Also, it isn't cynicism, it's experience that says that Windows guarantees a security risk. It's an intrinsically unstable, risky platform.

So the bashing was hardly gratuitous.

ever wish you could un-post

[DrSkwid]

sorry about the clueless

On reflection I'll retract that

Logic that makes my eyeballs twitch

[Darth_Burrito]

1) 1) Users are pure evil.
We don't know if there could be sources of evil outside of Users.

2) Civilization is made up of users.
We don't know that Civilization is made up solely of users.

3) Computer professionals are responsible for the collapse of civilization.
That we are responsible for the collapse of civilization does not mean that we destroyed all users.

4) Computer professionals will therefore destroy all evil
The assumption is made that Evil is a non transferable entity. For example, a user could corrupt a system administrator via constant abuse. The sa then gets the evil idea of deleting all home directories. Even if Users contained all Evil in #1, the switch to future tense in #4 invalidates #1 as a given. Users are pure evil means that NOW users are evil. It doesn't say anything about whether or not they will be pure evil in the future.

Hm.

[Shoten]

He kind of sounds like a bit of an a$$hole, to be utterly honest. He repeatedly slams just about every computer professional on the planet (except himself, of course) for everything from writing bad code to not knowing ALL the details of EVERY service running on EVERY machine they have responsibility for. I can, off the top of my head, mention a hundred organizations who are so small they cannot possibly afford a person of this depth of knowledge.

He also ignores the facts of the world, choosing instead to think that everyone else needs to bend. Programming languages are being written insecurely by everyone alive? Don't whine about it, try to come up with a better way that won't make it so hard to write secure code with the available workforce out there. Let's face it; the infrastructure that exists needs supporting, and we can't wait until all the monkeys out there learn the One True Way(tm) of making everything secure. Telling everyone that they need to know everything is a stupid way to tackle the problem.

vasqzr proves he is a wizard.

[twitter]

Oh great vasqzr, your library is most impressive as are your great deductive reasoning skills. I would never have come up with your summary of the article nor recomended the same books after reading that article. What a grasp you have on the following quotes:

If something like Windows plays any part at all in your system design, you should probably give up now. Despite being closed source, holes are discovered constantly. The Windows system is also far too massive, complex, and user unfriendly for human beings to have any hope in securing it.

It should be a crime to teach people C/C++.
This isn't an attack on the language itself (although there are plenty). The problem is that people use it to write high level applications....High level languages like Ruby, Python, or even Java are strongly recommended for all new projects.

Actually, I think you are a troll. You read the article, know about the boycot on Amazon, and wrote the most infuriating and leat informative thing you could. Thanks.

For those of you just tuning in, I like C, but the author's got point about using it to write high level stuff.

Security and Systems Software Design (RANT)

[hackus]

IMHO the vast majority of todays problems stemm from the fact that we have an increasing need for computer programmers, so we build systems that an idiot can run. So, we DO have idiots running and maintaining computers.

Case and point, Microsoft Products.

Microsoft Windows and its philosophy of design to try and make systems easy to use by making it a snap to put servers up and running in a jiffy with a minimal background of how any of the services actually works, is a HUGE problem.

No DNS admin of a Windows box I personally have run into actually understands how DNS works. They use Wizards to setup the DNS server and well, presto, usually a wrong DNS server with malformed records or BAD zone lists.

The problem with this approach, is that computing is not that simple.

It never will be that simple of a system, computing in general that is.

Microsoft's seeming objective is to code every possible wizard configuration for a Word processor, server or whatever so that it "just works". This enables people to turn services on without understanding Jack or Jill.

Why even Aunt Emma can be a XP server administrator.

The point is, that when you have computer code making decisions increasingly, you run into systems that are hugely monolithic, and dangerous form a security perspective. People make mistakes as IS, but making security policy from service Wizards that are designed by people is a recipe for DISASTER.

Case and point, even small changes or patches to such systems can have unintended consequences. Microsoft products are HUGELY monolithic, and the enourmous amount of computer code built into them making decisions automagically for the system operator through Wizard based services setup can get one into big trouble.

Linux is TOTALLY OPPOSITE. Linux is NOT monolithic. In fact, you can strip Linux down very easily because services are in affect partitions, seperate software packages that have NOTHING TO DO with kernel or OS services.

Linux is inherently, no, not inherently, IT IS more secure because you can strip it down to the bare essentials and have a smaller running server with fewer lines of code. Fewer lines of code, means fewer execution pathways and unintended bugs that could compromise security. Plus a human is at the helm and 100% in control. Not a wizard making all sorts of setup decisions automagically.

Out of the box, inherent in its design, Linux is more secure because you can run it with fewer lines of code to do many of the same things. In fact, you can run Linux without a video card, and many people do if you are building a router. (You use your wireless Zaurus to ssh into the box for example.) You can run Linux as a DNS server and not have a login keyboard of any kind, no Applications running or EVEN LOADED for that matter.

Fewer lines of code means the server is also simpler to maintain and recover. Hugely monolithic installs like Microsoft Windows XP means longer backup times and longer still restore times.

Whats more lots of software running in the background means you have to have very complex backup daemons running, using backup obscura kinda methods to unlock secret systems files by the THOUSANDS and all sorts of party dancing to get a server backed up. No WONDER it is a very complex and very expensive endeavor to backup and restore a Windows machine so that it actually WORKS if you lose the hard disk...

Linux is just the opposite. Since the system can be stripped and customized by the admin, Linux backups become a simple file system backup. The kernel doesn't interfere with your decisions to load or unload applications. In fact it couldn't care less.

In the end, I find Linux prevents many MBA's for example from waking up in the morning and saying "Oh, I am bored with my job. I think I will be a programmer..." Presto, they load up a Visual .Net Studio and start thier "Wizards..." (OK, so I had to deal with a MBA guy who decided he wanted to program in Java...for about 3 years and I couldn't take it anymore...the guys was thicker than a BRICK WALL when it came to Software Design.)

The final point I would like to make is that automated software construction makes for REALLY BAD software. Case N Point, more Wizards.

I certainly don't mind SOME help, but some of the drag and drop code I have seen in for examples, Microsoft's Visual Studio .Net (Beta 3) for COM, DCOM, Active X and .Net C# code is just plain BAD.

But it is OK because it allows you to put together an application in 2 hours? More and more I hear Microsoft Balmer explaining: "We have the finest tools that bring value to the development process, that our competitors can't match. TCO (Total Cost of Ownership) is far lower because you can build systems much faster with Windows than Linux."

Man, don't get me started!

Anyone who knows anything about software engineering studies will tell you, the cost of owning software isn't in the design or construction portion, its the debug and MAINTANCE cycles of the softwares life span which is most expensive.

The code that these wizards pump out is not something I would like to try and maintain...

GOD HELP YOU if you should ever LOOSE the Visual Studio software because debugging the crap would drive any sane person to the old folks home for crazy and insane, burned out programmers!

(Note: Alot of the Java wizard tools for Swing are just as bad...maybe even worse than Visual Studio's code output...)

Most of the code output by Wizards is not very intelligible. Maintaining it is an invitation to a nightmare and cost that only a fool who would buy into that sort of argument.

Not too difficult anyway if you are already paying for Microsoft products, so fools are in good company long after they build .Net Studio software, in 3 different languages, with thier nice little wizards and three years from now exclaim: "Hey, we reused our Cobol, C, and Visual Basic code we invested in....Oh whats that? Yeah, we have 3 different guys here maintaining the same software our competitors use only 1 person to do the same Job because they ditched all those environments and used Java instead."

Hack

Re:Question:

[greenrd]

Java is the obvious answer.

I need something that can be compiled

The vast majority of Java VMs compile the performance-critical stuff at least down to native machine code. For faster startup time (and sometimes faster running time) you can use gcj, but only for non-GUI stuff.

Swing GUI performance was just about acceptable when I started using it five years ago - and since then it's got faster and is running on much faster CPUs. However, bad coding processes, like running long non-GUI computations in the GUI thread, can make Swing seem much slower than it "really is".

can offer some type of event-driven operation,

Yep. addActionListener etc.

will work with a GUI toolkit of some sort

You have a big choice! AWT, Swing, SWT, OpenGL and more... Qt/KDE bindings are currently out of date and therefore broken but I'm hoping they will be updated soon. Anyway, I would recommend Swing - it seems to be the most flexible.

and is "safer" than C++

Yep. No pointers, no segmentation faults (in theory), no array overflows (unless you turn off checking in gcj for performance), etc.

I don't need the candy-coated interface, but I do need a language that will provide those things in a reliable fashion.

JDK 1.4 has a really appalling bug that makes it crash on 24-bit mode on some Linux distros (the workaround is to use JDK1.3 or lower IIRC), but apart from that I've found it to be pretty reliable.

There is a big choice of IDEs, including some free ones like NetBeans (but that's quite bloated and slow).

Re:If something like Windows plays any part at all

[sql*kitten]

A non-Windows system is not a guarantee of invulnerability, but keeping a Windows system is guaranteed to put you at risk.

Let's parse this sentence for actual meaning:

"If you don't use Windows you are at risk, if you do use Windows you are at risk".

The entire article can be summarized in one sentence: "C is too difficult for me, and I've heard it's cool to bash Windows". Looking at his pages, he no commercial experience, and not even a CS degree. There are people writing on software quality, like Yourdon and McConnell, who have more experience than this kid's been alive. The fact that this article got posted at all speaks volumes for the editor's own software engineering expertise. Baracella is full of contradictions, like don't use C, but use C to verify the underlying platform. What? Or his ideas on reinventing the wheel, how are you supposed to do that if you on;y have high-level scripting languages? I haven't read so much rubbish since /. posted that article by someone who wanted Oracle to rewrite their server in Perl.