OpenBSD Journal

[MUSESS 2002] Louis Bertrand's presentation online

Contributed by Dengue on from the god-how-did-I-miss-Louis dept.

Louis Bertrand has made his MUSESS 2002 presentation available online. He covers some of the gritty details of the OpenBSD auditing effort in good detail.

Ok, I have to ask: What does MUSESS stand for?

(Comments are closed)


Comments
  1. By fansipans () on

    In response to the question asked:

    Further information:
    MUSESS '02: McMaster University Software Engineering Symposium


    mcmaster university has some bomb diggidiy software/security classes =D (look dem up on google)

  2. By Anonymous Coward () on

    I hope other presentations are available similarly. Make a presentation, put the slides on the web site. Great looking presentation. Now just add a audio streaming of the talk....

  3. By Anonymous Coward () on

    While I admire everything the OpenBSD team has done, when I read that presentation, I couldn't help but think that OpenBSD is taking the wrong approach sometimes. Instead of exhaustively auditing code to get rid of strcpy(), and unsafe input formating bugs to prevent buffer overflows, why not instead write network services in a language that doesn't allow direct access to memeory and doesn't have anything like pointers or strcpy? That seems to solve that whole set of problems.

    Comments
    1. By Anonymous Coward () on

      if you thought about that question for say, 10 seconds, you would realise what a stupid idea that was.

      just recently my mechanic told me my car had a leaky pipe that needed replacing. i asked him if he could make a car without pipes for me.

      Comments
      1. By jesse s. () on

        i am by no means a professional developer but that approach would, without a doubt, break a lot of compatibility between other networking implementations and go against the strong openbsd development ethic of writing standardized code.

        not a bad idea, just seems like a very long, arduous task.

        cheers

      2. By Anonymous Coward () on

        I have thought about this for 10 seconds. A lot more than 10 seconds. Here's the logic: Let's say we have a general-purpose language, such as the Java bytecode. If we exhaustively validate the bytecode interpreter and can guarantee its correctness (ie, freedom from buffer overflows), then anything which is written in the bytecode will also be free of buffer overflows. You might say, "Well, if you're going to spend all that time validating the JVM, then why not just validate the servers directly?" The answer is scalability: Once you validate the JVM, then you can take a buggy, million-lines-of-code experimental application and run it and it still won't be vulnerable to buffer overflows. By using a small validated interpreter such as the JVM it means you have one small thing to validate instead of having to validate every single thing you run on the machine. You could respond to that, "Don't write sloppy code" but correct, validated, audited code is a lot more expensive to write than code that doesn't require all that auditing. This is just from a business viewpoint. "We could spend $500k to write the application in C, and then spend another $500k to hire some top-notch code auditors to make sure it's correct, or we could spend $500k to write it in Java and we don't need to worry about buffer overflows." That's the question for many businesses.

        Comments
        1. By Anonymous Coward () on

          so you believe the openbsd developers should find a nice JVM, validate that, then re-implement everything in java (or similar)?

          im not going to crap on about what businesses should do here. im not saying that is not a worthy topic of discussion, but this is openbsd land, and i think its a stupid idea.

        2. By Anonymous Coward () on

          dude. the amount of code produced by $500,000 if left unaudited and designed by monkies (i shall refer to non-code auditors as monkies) WILL HAVE BUGS and WILL BE VULNERABLE TO ATTACK. it doesn't matter what language it's written in. either it's engineered right, or it's vulnerable as f***. security is not a goddamned product. you can't just "buy a secure jvm" or "program in the right language". It's not one thing. It's a f***ing process, you use the right tools, you put code together that works (using your brain to think about the code )). it's engineering. if you don't understand that then...then...you're missing out on some damn good code.

        3. By Anonymous Coward () on

          We could spend $500k to write the application in C, and then spend another $500k to hire some top-notch code auditors to make sure it's correct, or we could spend $500k to write it in Java and we don't need to worry about buffer overflows

          I'm assuming from the rest of your comment that you favour the second (Java) approach. Well I'm sorry, but the correct approach from any sane perspective is:

          "Spend 500k on writing the application in C using coders who know what the f*ck they're doing."

          I've seen the results of the "get it coded quick in some sweatshop somewhere" approach - any time or cost savings are rapidly offset by getting it fixed. That's if you can find good coders who want to bore themselves fixing someone elses f*ck ups.

          Chris

    2. By fansipans () on http://dub.gmu.edu/~fansipans/

      I'm sure 95% of the flamewar this thread will turn into will be basically this argument: "Focus 'secure' software development in one area, and let that one area 'solve' all the problems for other areas of code" vs. "Write Code in a solid and precise manner and you won't have security problems. Code elegantly, code exactly, and know your interfaces"


      This is one of the most played out arguments on -misc recently, and it comes down to people not understanding that 'security' isn't even a factor when programs are properly constructed (when programs are truly engineered then they don't have as many bugs, and have a lot less to worry about in the security/vulnerability department). Nevermind the fact that adding more code to a system to 'manage' security necessarily does two things: ONE: inflate the size of the system (increasing the number of lines of code theoretically vulnerable to attack, witness the recent LIDS vulnerability HAHA), and TWO: it gives programmers an incentive to not care about proper coding practices because the 'security program' or whatever extra thing is added on to 'provide security' will 'make things secure'.

      This is yet another case of LPWWTWSCAGAWIVSRP:
      Lazy Programmers Who Want To Write Spaghetti Code And Get Away With It VS. Real Programmers

      --fansipans

      Comments
      1. By pravus () on

        i just want to add that it's also not always about the code. the semantics of a program play just as a big a role in security as the code. as you said though, when projects are engineered, the overall design lends towards a more overall secure process and you get away from the patch thought process.

    3. By Anonymous Coward () on

      I don't think java is the answer, but I do think it is past time to start using a more appropriate language for networking daemons, and for that matter most userland code. I really don't understand why a revised C language with appropriate run and compile time checks in place can't be engineered.... I suspect indifference, momentum, and some of the negative aspects of human nature (knee-jerk hostility towards change) are at work...

      Comments
      1. By Anonymous Coward () on

        no-one is saying it cant be done, no one who can do it wants to.

        why dont you?

      2. By Anonymous Coward () on

        There is such a language. It's called Java. If you write enough C code you will eventually write something with a pointer error. You could write an infinite amount of Java code and never have a pointer error because there aren't any pointers. That seems like an advantage to me.

        Comments
        1. By fansipans () on

          You could write an infinite amount of Java code and never have a pointer error because there aren't any pointers. That seems like an advantage to me


          That's why I code everything I write in BASIC, I don't have to worry about all of the "features" that are in modern languages. Right now I'm workin with some networking and OpenGL libraries, I've found a couple of each for BASIC and the performance isn't that bad, and I don't have to worry about having data and methods accidentally being "public" like I could in c++/java, because now I don't have objects and classes to worry about. I've started to look at the work needed to port the kernel and some of /bin and the booting tools (mdec.exec,biosboot.exe,bsd.exe) in openbsd from C to BASIC, and it doesn't look that bad. So if anyone wants to help, or has done some work on porting from C to BASIC, lemme know, I could use your help.

          Also I'd like to add that I think a shift from C to BASIC will very much benefit the user base of openbsd. And for that reason all openbsd developers should support the switch from C to BASIC, because without users all the openbsd developers would just be hackers making programs....


          --fansipans

    4. By Anonymous Coward () on

      Uhm, Ok, let's re-write it in Java. Then no one will use it because it is too slow. You have to consider performance, not just pure safety.

    5. By Anonymous Coward () on

      Uhm, Ok, let's re-write it in Java. Then no one will use it because it is too slow. You have to consider performance, not just pure safety.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]