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

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Security Software BSD

String Cleanup Results On OpenBSD 53

Posted by timothy from the theo-apologizes-for-a-pun dept.
Dan writes "OpenBSD's Theo De Raadt provides an update on his team's efforts to remove potential buffer overflows within OpenBSD code by always calculating what the bounds of an operation are. They have been going through the source tree cleaning out all calls to sprintf(), strcpy(), and strcat(). Theo says that they have removed (replaced) approximately 2000 occurences of these functions." (The same buffer overrun-squashing effort was mentioned earlier this month.)
This discussion has been archived. No new comments can be posted.

String Cleanup Results On OpenBSD More

String Cleanup Results On OpenBSD

Comments Filter:

  • BSD Coding Standard. (Score:3, Insightful)

    by UnknownSoldier ( 67820 ) on Tuesday April 22, 2003 @09:47AM (#5781005)
    Does the BSD team have a list (or rules of thumb?) that mentions other safe coding practises? There has to be book on this, right? (I've always been impressed by the pro-active stance BSD takes towards security -- I just wish the rest of the commercial world could afford the time to do things right, instead of the cheesy no liability out-clause in the EULA.)

    If most developers are still using these "trivial" funcs, I'm scared what other funcs are just as buggy!

    Funny how one can forget all about these "harmless" bad practises. Time to add it to the internal coding standard. :)

    • Re:BSD Coding Standard. (Score:5, Informative)

      by TilJ ( 7607 ) on Tuesday April 22, 2003 @10:23AM (#5781276) Homepage
      There's a summary of good practices at http://www.openbsd.org/porting.html#Security. The white papers that the team has produced (for example, on the str "l" variants) are also good reading.
      • Grandparent posteth:

        If most developers are still using these "trivial" funcs, I'm scared what other funcs are just as buggy!

        Funny how one can forget all about these "harmless" bad practises. Time to add it to the internal coding standard. :)

        eliciting parent's informative reference on proper coding practices.

        I wish it were that simple. Recently starting at a new position, I was horified at the number of strcpy()s, strcat()s, and sprintf()s peppered throughout code -- mostly building up a string to be

        • I know this will be an unpopular statement... But security is important only for programs that are accessible via the internet. Who cares if an application like gimp (to pick a name at random) has code like

          char buf[20];
          GetUserInput("Input the number of seconds since you last ate something", buf);

          when the only person who has access to that vulnerability is the user himself? I bet 95% of all the useful programs out there fall into this category. It's a waste of time to put an ultra-secure lock on the do
          • Not only is it an unpopular statement, it is completely wrong. Ever heard of a "local exploit"? Not all programs run with the permissions of the user that executed them.
            • [Sorry, playing the devil's advocate a bit here] Say there is sloppy non-buffer-checking code in a drawing application (I don't know if there are any in a particular program so I won't be specific). The kind of code that would lead to a vulnerability if it were in an internet server. This program doesn't run setuid and doesn't listen to any sockets and the only way the overrun could be exploited is for the user to do it himself. Tell me how this is a security problem.
              • Programs can get used in unusual ways. If you happen to have a drawing application which is started up by your web-browser then a malicious piece of content on the web could hack into your account that way. Setuid programs may call external programs which don't normally run with elevated privs (sudo is a really common way of doing this).

                There are two different ways of dealing with this -- either auditing your entire system for exploits assuming that any piece of code may be running with elevated privs a

    • (I've always been impressed by the pro-active stance BSD takes towards security -- I just wish the rest of the commercial world could afford the time to do things right, instead of the cheesy no liability out-clause in the EULA.)

      You're thinking of OpenBSD.

  • OpenBSD (Score:1, Troll)

    by duffbeer703 ( 177751 )
    These guys have been claimng to be super-secure and constantly performing security audits on the OpenBSD code for years.

    Yet they've launched a major effort to cleanup 2,000 unsafe string functions in the last two months...

    What has Theo been doing all this time other than being an obnoxious prima donna and re-writing packet filters because of some minor squabble?
    • This is like asking why Chevy didn't recall a car that blew up even though they didn't know about the problem ahead of time.

      Security is a constantly moving target (Format string vulnerabilities are very new on the scene for example). The string functions that were replaced did not have holes, they were replaced because they wanted to avoid even the possibility of a vulnerability and because they wanted to clear all standard string operations out to make searching for possible future vulnerabilities easier

      • Re:OpenBSD (Score:2, Flamebait)

        by duffbeer703 ( 177751 )
        According to Theo, the OpenBSD team is continuously auditing OpenBSD code. Is Theo re-writing grep because he has an issue with whomever wrote it thirty years ago?

        Unchecked string problems have been known since the standard C libraries came out. I first heard about them around 1995.

        All I'm trying to say is that OpenBSD would be a much more secure system if Theo spent more time working on it rather than grandstanding.
        • It's almost refreshing to see someone complain that the most secure OS could be more secure. Oh, wait. Let the guy do his job -- maybe if he wasn't doing such a great job his grandstanding wouldn't be as acceptable.
    • Why don't you download some GNU package and see how many occurences there is of those functions? Why don't you go and fix those? Why complain when people are actually fixing things?
    • They aren't unsafe if used properly. They're just easy to use unsafely. Furthermore, they're slightly slower than their bounded cousin functions.

      I'm sure use of unbounded string functions were looked over and checked for possible bugs. This just makes it harder for another kernel bug to cascade into a kernel compromise.

      Believe me, this is way, way more than our friends in Redmond have been doing.
      • They're actually slightly faster than their bounded cousins; their bounded cousins have to check the bound on every iteration through the loop (all these functions are fundamentally just loops), whereas the unsafe versions can simply not do that check.

        Jeremy

    • Re:OpenBSD (Score:3, Interesting)

      by glitchvern ( 468940 )
      A valid question if you don't know the answer, you shouldn't have been moderated as a troll I think. These "unsafe string funtions" sprintf(), strcpy(), and strcat(), are only unsafe if they are used incorrectly, which is easy to do. OpenBSD's source has been audited in the past to make sure they are used correctly. Now instead of making sure these calls are used correctly they are ripping them out and replacing them with calls to safer string functions. Interestingly it appears Theo is being successful
      • Thanks for the explanation, that really clarifies everything for me.

        For someone like me who doesn't really use BSD and sees everything going on with it as a spectator, sometimes the political and other issues surrounding it obfuscate the technical detail.

  • Shifting so much (Score:3, Interesting)

    by mnmn ( 145599 ) on Tuesday April 22, 2003 @10:10AM (#5781173) Homepage
    I wonder when Theo can say they have removed ALL occurrences of these functions??

    But more importantly, why wasnt it possible to replace the functions in the library with something (if a bit slower) robust?

    Are we witnessing the evolution of the New Libc(tm) ?? Can I patent it?
    • If you check the man pages for the 3 functions, you'll see that they just take char * pointers with no lengths specified, so they'll just copy from the source data until they hit a zero char or cause a buffer overflow exception.

      To answer your question, it's not possible to replace the original functions in libc because there's no maximum length param in those functions (unlike the safer "n" equivalents like snprintf()).


      • Exactly, the bugs are in libc, not the calling programs. OpenBSD should remove all dangerous libc functions, like sprintf() and strcpy(). Then unsafe user programs will not even compile. If OpenBSD is really, really serious about security, they could then disallow these unsafe programming practices. Source code ported to the new restrictive OpenBSD libc would benefit on other platforms, too.

        If forever removing strcpy() and friends is just too radical, OpenBSD could use a transitional approach by moving the
        • At least functions that call that stuff could produce a warning to stderr, like other functions are known to do.

          Would be pretty neat.
        • The problem with removing strcat and strcpy is that you can use them safely if you put some thought into what you're doing. There's no reason to ban them from libc just because some programmers don't check their buffer sizes. Removing the old string functions would make a lot of code not work on OpenBSD.

          Also, the OpenBSD team isn't going to touch most of the third party code in the tree: "We are obviously not doing this to some parts of the tree which we borrow from other projects. In particular, the gn
  • ...when his mother/SO said, "I think you should do some spring cleaning."
  • Something that irritates me about using MSVC:

    #include
    void main(void){
    char buff[1024];
    snprintf(buff, 1024, "Test"); /* wont compile */
    _snprintf(buff, 1024, "Test"); /* will compile */
    return;
    }

    GRR!! Very annoying when trying to write code for both win32 and *nix.
  • Some of you might have noticed that we have been doing a 'string cleaning'. (I should probably apologize for this northern-hemisphere specific pun).

    Groan. Umm, we do spring cleaning in the southern hemisphere too ya know! Our spring follows winter (the cold one) and preceeds summer (the hot one) as well!! The only difference is the time of year.
  • Some people on here are asking what the obsd group has been up to over the past few years. Some are claiming that they have spent a couple years rewriting packet filters, and are just now checking for unsafe string handling. This is not true. The source tree was/and is continuously being audited. strcat/strcpy/sprintf can be dangerous functions, BUT BUT BUT BUT, if they are used with proper condition checking code before they are called (as the obsd src does), then they are no more dangerous than strncat, e

Slashdot Top Deals

"Hello again, Peabody here..." -- Mister Peabody

Close