Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security

A Developers Security Bugs Primer 35

CowboyRobot writes "ACM Queue's current issue on Open Source Security includes a short article by Eric Allman of Sendmail on how to handle security bugs in your code. "Patch with full disclosure. Particularly popular in the open source world (where releasing a patch is tantamount to full disclosure anyway), this involves opening the kimono and exposing everything, including a detailed description of the problem and how the exploit works... Generally speaking, it is easier to find bugs in open source code, and hence the pressure to release quickly may be higher.""
This discussion has been archived. No new comments can be posted.

A Developers Security Bugs Primer

Comments Filter:
  • by Anonymous Coward on Sunday February 25, 2007 @12:12PM (#18143444)
    Check with local law enforcement first, as this is illegal in most prefectures.
  • Priority... (Score:4, Insightful)

    by Architect_sasyr ( 938685 ) on Sunday February 25, 2007 @12:19PM (#18143504)
    Something I have noticed with the development team at my current place of work (I'm not on the team thankfully) is that they tend to do jobs in the order they were received... it make's the KPI's look damn good (all jobs are knocked over within x time frame) when in reality they should be setting a priority on each of these jobs.

    We recently (1 month ago) had a form in an easily accessible place vulnerable to SQL Injection due to a failure to validate ANY of the data passed to it. This job was only just patched this past week (and all updates have been run). This time frame, as far as I am concerned, is entirely unacceptable for a job that was so easy to fix yet so dangerous to our business.

    On disclosure: Add it to the release notes. If you roll out a patch for one problem, then the problem will be described in the release notes. If the release is internal then the problem will (SHOULD) also be documented in the testing plan and proceedure.

    My $0.02.
    • Re: (Score:3, Insightful)

      by --daz-- ( 139799 )
      Why are people still generating SQL? Don't all the major DB engines favor prepared statements anyhow? Note: prepared statements =/= Stored Procedures, though in some engines, stored procedures are just another FORM of prepared statements. Using prepared statements (or parameterized queries, etc, etc) pretty much eliminates all SQL injection problems.

      Parsing is messy business and there's usually ways to thwart it by a determined h4x0r.
  • by Spazntwich ( 208070 ) on Sunday February 25, 2007 @12:20PM (#18143510)
    This is an extremely narrowly focused article. He doesn't account for anyone else's choice of apparel, and Netcraft has recently confirmed that Kimonos are dying anyway. There can't be that many users of such an outdated technology.

    Next time take into consideration those who choose to wear sweatpants, moo-moos, and the increasingly popular among furries peanut butter suit + placard.
    • Surely no one has tried a peanut butter suit since the Human Sh-t debacle many year ago? (1. peanut butter oils embed themselves in the skin. 2. It quickly goes extremely rank and nasty. 3. It rubs off on anything you brush against. 4. weapon of mass destruction against the peanut intollerant.) It's on the same Do Not Want list as using hot-melt glue to attach costume bits to flesh.
  • Shouldn't that be "A Developer's Security Bugs Primer"?

    This site has editors, right?

    • by nateb ( 59324 )
      I think you're confusing them with people that have pride in their work.
    • Or maybe it should be "A Developers' Security Primer." Either way, the editor's' we're not paying attention.
      • by flosofl ( 626809 )
        The article a is used with singular nouns. So no, it would not be Developers'
        • Re: (Score:1, Informative)

          by Anonymous Coward

          The article a is used with singular nouns

          Yes, such as "primer". "A (Developers' (Security Bugs) Primer)" is a valid way of describing a primer for developers regarding security bugs.

  • Sendmail? (Score:5, Funny)

    by jfedor ( 27894 ) <jfedor@jfedor.org> on Sunday February 25, 2007 @12:55PM (#18143802) Homepage
    Getting advice on how to handle security bugs in your software from someone who works on Sendmail is like getting advice on dealing with relationship problems from someone who was divorced seven times. I mean, sure, he's got experience...
    • Re: (Score:3, Interesting)

      Getting advice on how to handle security bugs in your software from someone who works on Sendmail

      It could be worse; it could be advice on how to write readable code from the person who wrote qmail.
  • +tag irony (Score:1, Flamebait)

    by Tack ( 4642 )
    Take a step back and bask in the irony.
  • It's not the bugs (Score:3, Informative)

    by VENONA ( 902751 ) on Sunday February 25, 2007 @02:20PM (#18144360)
    ...which I don't really think now occur in sendmail at a higher rate than some other infrastructure bloatware. People are sometimes very slow to upgrade from very old versions, when problems were more common. For whatever reason (I lean toward complexity of administration), I see this a lot more often with mail systems than other infrastructure plumbing.

    But here's a bit of irony: the ACMQueue article would seem to indicate that Allman believes in transparency. OK, the sendmail security page lives at:
    http://www.sendmail.com/security/ [sendmail.com]

    But you have to know that, find it via Google, or just guess. When the page loads, you'll find a pagetop navigation bug at the Resources secion. But pull open the Resources section, and you find no link to it. Nor will you see it from the site map.

    My overall take is that if you already know the ins and outs of sendmail admin (and other bits that it may be talking to, such as LDAP) you're running software which carries no greater than mainstream risk.

    That said--this is complex software, and complexity is the enemy of security. If you're planning a new installation (particularly a small installation), and don't need all of sendmail's features, you should consider possible alternatives offerred by your Unix/Linux vendor.

    • Re: (Score:2, Informative)

      by Jubal Kessler ( 7025 )
      Huh? The "Security" link on the front page of http://sendmail.org/ [sendmail.org] works fine.
      • by VENONA ( 902751 )
        Indeed it does, but I was on about sendmail.com, not .org. The commercial company founded by Allman for sendmail support. You'd think that the commercial company founded for support would have a prominent and functioning link to their security page, right? As a sort of, well, *support* thing? Nope.
  • by Anonymous Coward
    What about the B developers? Do they not get a security bugs primer?
    • by beady ( 710116 )
      If that's true then once you get as low as C Developers, then they don't stand a snowballs chance in hell of avoiding Security Bugs.
  • The title, "A Developers Security Bugs Primer", is incorrect.

    Developers = more than one developer.
    Developer's = the term following belongs to the developer.
    Developers' = the term following belongs to more than one developer

    We are supposed to learn this in 5th grade.

    It is embarrassing that grown men, employed by the most prominent IT website, will publish an article where the title would fail 5th grade English.

    If we are to hold ourselves to a higher technical standard, we should at least be able to spell an

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Working...