Slashdot Mirror


Stack-Smashing Protector

XNormal writes "It's not exactly new but for some reason it doesn't seem to be getting the attention it deserves. The stack smashing-protector developed by Hiroaki Etoh at IBM's Tokyo Research Lab is a patch for GCC that provides effective protection against buffer overflows. It protects against cases not covered by StackGuard and StackShield. It it well-supported on multiple versions of GCC and multiple platforms. Why is it not getting enough attention? Perhaps it needs a CatchyName instead of 'ssp'? I'll ponder this question while I'm recompiling all my executables that have an open port and the libraries they depend on."

6 of 28 comments (clear)

  1. This vs. Non-executable Stack? by Anonymous Coward · · Score: 2, Interesting

    How does this compare to OpenBSD's new non-executable stack? I am confused by how this works, and also how a non-executable stack works. I would appreciate it if someone could explain this in laymans terms.

  2. I don't think it's the name... by funkhauser · · Score: 4, Interesting
    I really don't think the name is the problem. I mean, gcc gets by fine with a rather non-descript name.

    It seems like it would be difficult to get a whole lot of developers to move over to this at once, so perhaps that's why it's not catching on? If one major group of developers (Red Hat, Debian, whoever) started using this patch, perhaps their influence could sway others? It's not like the world of M$ where the necessary constant upgrading forces users to switch to technologies that Microsoft thinks are important. (Although buffere overflows are a very important issue, I'm just commenting on the fact that it's Microsoft that pushes the technologies, not the needs of the developers.)

  3. Many developers just don't want it by maeglin · · Score: 5, Interesting

    The reason stack protection stuff isn't being widely used isn't because it's got an obscure name or something simple like that. It's because not everyone can agree whether it's effective or just lures people into a false sense of security. There have been a couple of "discussions" of this on the Linux Kernel Mailing List and the end result is always a stalemate.

    dan

    1. Re:Many developers just don't want it by moncyb · · Score: 3, Interesting

      Why does the Linux kernel set the exec flag for stack pages? I don't see any reason why it should. If the program needs to load code, then it can just use one of the lower level calls to allocate the memory as executable. Pages used only for storing data should not be executable. I think I'll try to find this patch...

  4. Re:Microsoft Visual C++ .NET has a similar feature by Anonymous Coward · · Score: 1, Interesting

    Right, and if I recall correctly this was the subject the the 1st .Net "exploit".

    True it was hyped as an exploit when it really isn't, but it goes to show that there is no replacement for skilled and careful coding.

    See http://www.cigital.com/news/mscompiler-tech.html for more info.

    Jesse

  5. Re:Microsoft Visual C++ .NET has a similar feature by Mr.+Slippery · · Score: 2, Interesting
    On functions subject to buffer overrun problems

    How is this determination made? Is it just looking for functions that make certain calls, or what?

    Seems to me all the attacker has to do is figure out how to spoof the security cookie. What prevents this?

    --
    Tom Swiss | the infamous tms | my blog
    You cannot wash away blood with blood