Security Shaming

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 714297

    Comments posted to this topic are about the item Security Shaming

  • Robert Sterbal

    SSChampion

    Points: 10947

    Are their competing schemes? I'd like to have the links for my wiki.

    412-977-3526

  • David.Poole

    SSC Guru

    Points: 75031

    When someone says "ok so what do I do?" We're pretty vague

    That pretty much sums it up for me. No-one sets out to write bad software. There is a limitless supply of critics and wise after the event merchants but the people who identify problems, illustrate why they are problems and demonstrate how to fix the problems are few and far between.

    Thinking back a decade or two one of the common problems was vulnerability to buffer overruns. It was quite hard finding out how to spot the vulnerability and even worse trying to find out how you were expected to deal with it.

    I recently saw a post identifying the"if" statement as an antipattern. It was thoughtfully written explaining why and what needed to be done. Unfortunately I get a 404 error from the bookmark I had. We need a lot more articles explaining the fixes.

  • x

    SSC-Insane

    Points: 23349

    David.Poole (8/8/2016)


    When someone says "ok so what do I do?" We're pretty vague

    That pretty much sums it up for me. No-one sets out to write bad software. There is a limitless supply of critics and wise after the event merchants but the people who identify problems, illustrate why they are problems and demonstrate how to fix the problems are few and far between.

    Thinking back a decade or two one of the common problems was vulnerability to buffer overruns. It was quite hard finding out how to spot the vulnerability and even worse trying to find out how you were expected to deal with it.

    I recently saw a post identifying the"if" statement as an antipattern. It was thoughtfully written explaining why and what needed to be done. Unfortunately I get a 404 error from the bookmark I had. We need a lot more articles explaining the fixes.

    Might be this one (edit: or a similar sentiment):

    http://antiifcampaign.com/

    I think these guys narrowed in on the "if" construct to make it catchy and marketable, because undesirable code complexity is probably already a thing and they can't claim that as their own. Their "code monster" isn't even in English. I don't have anything against non English speakers, but if the about page is in English, and the "code monster" is in a different language, it seems slightly dishonest.

    There do seem to be some valid gripes elsewhere, like the "arrowhead pattern" that actually do seem to talk about some genuinely undesirable qualities that you can be on the lookout for in your code, but they avoid latching onto an actual programming language keyword like the referenced page / campaign.

  • Eric M Russell

    SSC Guru

    Points: 124948

    Isn't that what the various hacker organization are doing; shaming our goverment and political organizations into implementing better security practices? 😎

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 714297

    robert.sterbal 56890 (8/7/2016)


    Are their competing schemes? I'd like to have the links for my wiki.

    ?

  • Gary Varga

    SSC Guru

    Points: 82166

    patrickmcginnis59 10839 (8/8/2016)


    ...I recently saw a post identifying the"if" statement as an antipattern. It was thoughtfully written explaining why and what needed to be done. Unfortunately I get a 404 error from the bookmark I had. We need a lot more articles explaining the fixes./quote]

    Might be this one (edit: or a similar sentiment):

    http://antiifcampaign.com/

    I think these guys narrowed in on the "if" construct to make it catchy and marketable, because undesirable code complexity is probably already a thing and they can't claim that as their own. Their "code monster" isn't even in English. I don't have anything against non English speakers, but if the about page is in English, and the "code monster" is in a different language, it seems slightly dishonest.

    There do seem to be some valid gripes elsewhere, like the "arrowhead pattern" that actually do seem to talk about some genuinely undesirable qualities that you can be on the lookout for in your code, but they avoid latching onto an actual programming language keyword like the referenced page / campaign.

    Their "code monster" has errors. It wouldn't compile (missing brace spotted in about 20 seconds). The website appears to be quite old (looks untouched in a couple of years). And assumes poor coding practices are being uses (that code would be broken down into separate methods if appplying best practices now).

    Also whose "boss" would know enough detail to say the following:

    "... All that’s needed," the boss continues "is to add a small piece of functionality to that class method you’ve been working on... it shouldn’t be too complex..."

    ...the cynic in me at this stage would want to highlight that the website is an author's company's one with a book or two to sell. It is called something like "Waaaaaah! Royalties"[/url].

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • TomThomson

    SSC Guru

    Points: 104707

    David.Poole (8/8/2016)


    When someone says "ok so what do I do?" We're pretty vague

    That pretty much sums it up for me. No-one sets out to write bad software. There is a limitless supply of critics and wise after the event merchants but the people who identify problems, illustrate why they are problems and demonstrate how to fix the problems are few and far between.

    Thinking back a decade or two one of the common problems was vulnerability to buffer overruns. It was quite hard finding out how to spot the vulnerability and even worse trying to find out how you were expected to deal with it.

    It seems to me that your buffer overrun example is one which, for anyone who knows a little history, rebuts the statement in the preceding paragraph.

    Buffer overflow problems are pretty straightforward. They were noted rather early on, and by the late 60s eliminating them was being addressed in several ways:-

    (i) Operating System (or Monitor or Executive or whatever it was called by whoever wrote it) interface design - requiring an application which requested input to provide a buffer of known length and not transferring more data than that into it) - if the hardware suppliying the input needed a bigger buffer, either refuse the input request or stage it through a big enouah buffer which it itself allocated internally. But along came Unix, which didn't do that in some early versions, and since Unix was so thoroughy overhyped that kind of buffer overflow was not wiped out.

    (ii) Operating system internals and hardware: store which could be written and store which could be executed as separate stores, with status of each area controlled/specified by the OS and enforced by hardware - usully done with virtual addressing, but not always. This didn't eliminate all buffer overflows within the OS, but did prevent overflow into executable code (whether at user level or at OS level); usually done with Virtual Addressing, but sometimes just by having a bitlist with a single bit mark for each page to say whether it was read/execute only or not.

    (iii) programming language design: having string type which had a length as well as a start point. But then along came C which left out string length to buty performance at the expense of security and bug-freeness, and C was so hyped that it almost took over the world (and carried it's hopeless pointers forwards into C++).

    (iv) hardware supported bounded strings which could (a) support (iii) above and (b) assist (i) above; by 1969 both Burroughs and ICL were using languages with this property for writing operating systems which did (i) for hardware which did both (ii) and (iii), but Unix wasn't going to take up much of "that nonsense" (nor, later, was Windows), and neither was C (nor, later, C++).

    By 1969 hordes of people had pointed out what was needed to eliminate buffer overflows, and at least two signicficant companies were doing those things on a large scale. The ICL stuff is still going strong (now sold by Fujitsu - who regularly try to recruit people with experience of ICL's VME-B, so I guess I could find a job there if I wanted to); I don't know whether the Burroughs stuff is still going or not.

    Both the problems and the solutions were very well documented in technical journals, trade press, and books. But most people in computing couldn't give a toss - they knew that they were too clever to need things like bounds checks on strings, that bound checks cost performance (false on sensibly designed hardware) and that hardware that did boundchecks or knew what was read/execute only was expensive (true, unfortunately).

    That "the people who identify problems, illustrate why they are problems and demonstrate how to fix the problems are few and far between" could only be true for one extremely simple reason. Perhaps most such people eventually became fed up with beating their heads against a brick wall, and being regarded as loony weirdos or ivory tower wankers because they think things like buffer overflow matter and prefer languages like S3 (or other Algol 68 dialects) or SASL to C, Miranda to C++, Haskell to C#, F# to JavaScript, and Javascript to Visual Basic. And actually I'm pretty sure it isn't true, because we get used to being accused of lunacy and ivory tower attitudes

    Anyway, if you don't want buffer overflow in your software, just write your sofware in a language in which buffers (be they strings or arrays or anything else) have limits which are enforced and run it on hardware-OS combination that prevents both buffer overflow at the OS API and OS-internal buffer overflow.

    Tom

  • TomThomson

    SSC Guru

    Points: 104707

    Gary Varga (8/9/2016)


    Their "code monster" has errors. It wouldn't compile (missing brace spotted in about 20 seconds). The website appears to be quite old (looks untouched in a couple of years). And assumes poor coding practices are being uses (that code would be broken down into separate methods if appplying best practices now).

    No need to look at their code monster. They already demonstrate their lack of knowledge or experience on their home page, where " Avoid dangerous IFs and use Objects" shows that they think that polymorphism is something that happens only in OO languages. It was in lisp in 1958 and in several algol-like languages with abstract data types long before the term "object oriented" was coined, and is in many languages that don't have "objects".

    Also whose "boss" would know enough detail to say the following:

    "... All that’s needed," the boss continues "is to add a small piece of functionality to that class method you’ve been working on... it shouldn’t be too complex..."

    ...the cynic in me at this stage would want to highlight that the website is an author's company's one with a book or two to sell. It is called something like "Waaaaaah! Royalties"[/url].

    I'm inclined to agree with you on that, and I'll also admit to thinking it extremely unlikely that their books are worth reading if fixing the example of poor code on their home page is the best they can show us.

    Tom

  • Gary Varga

    SSC Guru

    Points: 82166

    Tom, the book title was all I needed to read to get a first impression that nothing else could shift.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply