OpenBSD Journal

Safety in a cyclone?

Contributed by jose on from the typesafe-languages dept.

anonymous asks: "The OpenBSD system has been hit by a few buffer overflows lately, with serious security implications. I've thought for a while "it's time to stop using C. No bounds checking, weak type checking, and many other dangerous qualities put it on the edge of safety." But Java is not going to be an acceptable solution to most of the OpenBSD developers. What about Cyclone , billed as a "safe dialect of C"? Cyclone guarantees type safety and memory safety, while retaining a very C-like syntax, and in fact the ability to compile some unmodified C programs. The performance overhead is small. The compiler is GPL and the libraries are LGPL. What do you think? I'm putting this out for discussion, not intended as a trolling."

I've actually used Cyclone on OpenBSD, it should work just fine after convincing the build system it's OK. It passes the regression tests. The Cyclone community is increasing in activity these days. However, I doubt a project as large and complex as OpenBSD would ever move wholesale into this language and compiler for a variety of reasons, including the limited number of platforms the compiler supports. However, anyone here play extensively with it?

(Comments are closed)

Comments

  1. By Michael () on

    For the OS, I'd say let's stick with C. The overhead for Cyclone is not big at all, but any overhead is bad at that level.

    However, for user land programs - cyclone is more than adequate. If you are doing any sort of input/output, then overhead is not your bottleneck. Not to mention the fact that Cyclone is fairly easy to pick up.

    I think what is needed is a Cyclone module for gcc. Once we have that, people may start to take a second look at it and say, "Hey, this looks pretty slick."

    Comments

    1. By Michael () on

      ^gt;If you are doing any sort of input/output, then overhead is not your bottleneck. --- <If you are doing any sort of input/output, then overhead is probably not your bottleneck.

      Comments

      1. By Michael () on

        >If you are doing any sort of input/output, then overhead is not your bottleneck.
        ---
        <If you are doing any sort of input/output, then overhead is probably not your bottleneck. I am retarded.

    2. By Anonymous Coward () on

      There's overhead from propolice, and that's being used.

      Comments

      1. By michael () on

        Good call - forgot about that.

        I suppose then that we should keep the overhead as low as possible. It seems like the issues addressed with ProPolice are essentially the same issues that Cyclone takes care of. So....I'm not sure where I'm going with this.

        It may be a moot point -> cyclone is on version 0.6 as far I can tell. It's probably not a good idea to write an operating system with beta material.

        --michael

      2. By tedu () on

        overhead is about 1%, and didn't require rewriting anything (developer overhead).

        Comments

        1. By Anonymous Coward () on

          Just that cyclones performance hit should be comparable to that of propolice, which is already in use, so I don't think cyclone would be rejected for performance reasons. Its not like "be the fastest OS" is one of OpenBSD's goals.

      3. By Anonymous Coward () grey on http://www.cansecwest.com/core03/theo-csw03.mgp

        You might want to read the presentation Theo gave at CanSecWest '03 where he discusses (briefly) some of the overhead penalities incurred for ProPolice, W^X and various other things implemented in the past year or so. Overall the feeling seems to be that most of those protections should incur 1-3% overhead. Theo did say something to the effect of, all of these 1-3% slowdowns could add up to a much larger slowdown if more similar performance penalizing things are implemented. (Very very loose paraphrase).

        That said, while not technically a dialect, some might argue that OpenBSD's use of alternate str* functions already constitutes some shift from standard C. You might want to read http://openbsd.org/papers/strlcpy-paper.ps as Todd & Theo provided some arguments for why they chose to go that route, and see how well alternate safe C programming extensions or dialects match up.

        There are a lot of other interesting security minded projects outside of OpenBSD to be sure; but they're not always destined to work together, or sometimes just not quite yet (opencm comes to mind as an example).

  2. By djm () on

    The recent problems haven't been traditional strcpy(tooshort, toolong) buffer overflows, they have been a fair bit more subtle than that. Astute readers of source-changes@ would notice that a sweep of the entire tree was made for similar problems shortly after the discovery of the ones in OpenSSH.

    Comments

    1. By Giovanni () nospam@nospam.org on mailto:nospam@nospam.org

      Was anything found ? I'm not a source-changes@ reader at all.

  3. By Christian Stork () on

    Check out the CCured project at

    http://manju.cs.berkeley.edu/ccured/

    for a different approach. Probably, this one is more applicalbe since less intrusive.

  4. By henning () henning@ on mailto:henning@

    no, we've not been hit by what one usually calls "buffer overflows" lately, and there were no "severe security implications" from that. I keep wondering where that myth comes from.
    it's out of question that the ssh buffer stuff was bad and a bug - but please enlighten me how that is a real security problem, at least on OpenBSD. at worst, this is a DoS.

    Comments

    1. By Anonymous Coward () on

      The 'myth' that there were severe security implications from the last OpenSSH bug comes from some (unknown) individuals blatantly lying in various public forms (like Slashdot, etc) by claiming they were OpenBSD users who 'had the exploit' and it could confirm that worked against the newest version of OpenBSD. In other posts -- probably by the individuals -- it was implied that OBSD's 'Only one remote hole' claim was a lie, and citing the failure to add this incident to the list as evidence. Some losers personal smear campaign I would guess. Of course most casual readers would just take the initial claim at face value since it *could* be true as far as they know.

      Comments
      1. Comments

        1. By Anonymous Coward () on

          Hmm ... a possibility that hadn't occurred to me. Maybe Theo has a dark alter ego personae I hadn't suspected .... 8^)

      2. By Anonymous Coward () on

        And what makes you say that they were lying? Have you got perhaps some proof to the contrary or are you just another clueless self-congratulating 'genius'?

        Comments

        1. By tedu () on

          yes, i have proof that there is no exploit. however, i would prefer to keep my analysis techniques to myself, so i won't be sharing it.

          Comments

          1. By Anonymous Coward () on

            and this makes you different from the people claiming to have exploits.......how?

          2. By Anonymous Coward () on

            though i dont know what tedu has done, i will second his opinion. if you look at the details of this bug, it would be a hard, hard thing to exploit on openbsd.

            its the infinite saw thing. could an attacker with infiniite time and inifinte resources exploit this? perhaps so. in the real world, finding a bug that does x is nothing too special, working out how to turn x into a local/remote vulnerability is where the beauty and skill of exploit writers comes from. nonetheless, turning this bug into a local/remote exploit i will happily eat my hat or shoes or whatever it is americans eat if they're wrong.

            Comments

            1. By Michael () on

              happily eat my hat or shoes or whatever it is americans eat if they're wrong.

              It is proper for an American to eat their bowling shoes if s/he is wrong.

        2. By Anonymous Coward () on

          No, I'm not a genius, but I am telepathically linked with Tedu, and I know what he knows. Yes, I have the proof that this is absolutely true, but I can't share it with the world either, because if others learn how telepathic links are established, it could be horribly misused.

        3. By Elvis "The King" () on

          It's true just because I said so. Since I have 50 millions fans worldwide I just can't be wrong.
          Btw love me tender...

      3. By RC () on

        It's not just slashdot. If you read through the bugtraq posts, you'd have seen several individuals that _claimed_ they had machines rooted, and that OpenSSH was the culprit.

        I don't think there is any question that there are numerous people who are dead-set on doing everything they can to give OpenBSD a bad reputation, and we've certainly seen a few of them posting regularly here on deadly.

        I too will believe it when I see an exploit, but the fraud is much more than a couple idiots on slashdot.

  5. By jose () on http://monkey.org/~jose/

    i should have looked and not assumed that because cyclone worked at 0.3 it will still work now. it doesn't. it looks like its hitting the W^X restrictions. it bootstraps itself (or tries to) and dies in the build process. basically the code builds a function and then tries to execute it (i think) by pushing it on the stack. you'll have to enable PROT_EXEC via mprotect() to get this to work. but after an hour of hacking and learning mprotect() stuff i'm no closer than this.

    if anyone wants to start hacking on this, that would be very cool.

    enable gcc -g in Makefile.inc, build, debug ... you'll see it died in gc/mark.c here:

    #0 0x1c0e575f in GC_mark_from (mark_stack_top=0x3c0410a8,
    mark_stack=0x3c0410a8, mark_stack_limit=0x3c0490a8) at mark.c:648
    #1 0x1c0e526a in GC_mark_some (
    cold_gc_frame=0xcfbefee4 "

Latest Articles

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.]