Slashdot Mirror


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

7 of 326 comments (clear)

  1. So basically... by vasqzr · · Score: 5, Informative



    He read a few books on the subject, and summarized the most simple concepts in an article.

    Nothing new here.

    Head to Amazon and find some books ...

    Software Project Survival Guide by Steve C McConnell (Paperback)
    Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs by Steve Maguire (Paperback)
    The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks (Paperback)
    The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt, et al (Paperback)

    1. Re:So basically... by Koyaanisqatsi · · Score: 3, Informative

      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.

  2. Re:Engineers (again...sorry) by ergo98 · · Score: 3, Informative

    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.

  3. Re:Engineers (again...sorry) by esarjeant · · Score: 3, Informative

    I think this is the link; a good read:

    Why Mainframes Rarely Crash

    --

    Eric Sarjeant
    eric[@]sarjeant.com

  4. Re:What hubris. by stephanruby · · Score: 5, Informative
    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.

  5. C vs C++ by magi · · Score: 3, Informative
    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.
  6. Re:High level languages by defile · · Score: 4, Informative

    When you critique someone's work, it is customary to first read it in its entirety. Besides the fact that it's just common courtesy, if you had read just one more paragraph you could've prevented yourself from committing such an egregious faux pas.

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

    High level languages like Ruby, Python, or even Java are strongly recommended for all new projects. The reason these languages are more secure (in theory) is that they don't have pointers. Most security vulnerabilities that involve breaking program code involve manipulating pointers-in fact, many programming bugs are generally related to pointers in some way. As with the OS issue noted above, do not mistake this for invulnerability. You're simply less likely to be compromised using this particular attack vector with a high level programming language.