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

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: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:Open Source = Broken Source

[Anonymous Coward]

This is a horrible attempt at trolling.

You need more flesh and to play a bit more of a condescending role.

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 [amazon.com]
• Writing Secure Code [amazon.com]

Any others?

Re:Engineers (again...sorry)

[esarjeant]

I think this is the link; a good read:

Why Mainframes Rarely Crash [byte.com]

Re:Engineers (again...sorry)

[fegu]

It is available from their archives [byte.com]. Not too bad actually.

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 [bacarella.com]. You can actually see his code and the depth of his work is not at all impressive.

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.

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.

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: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 [apeg.bc.ca]. 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 [apeg.bc.ca]. 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