OpenBSD Journal

[OpenSSH] OpenSSH vulnerability to be announced

Contributed by Dengue on from the keep-a-weather-eye-out dept.

In an email addressed to BUGTRAQ , Theo de Raadt urged users of OpenSSH to upgrade immediately to OpenSSH 3.3 and, most importantly, enable Privilege Separation ( UsePrivilegeSeparation yes in sshd_config ). There is an upcoming vulnerability, credited to ISS, which will be released early next week. Privilege Separation , by reducing the amount of code running as a privileged user process, greatly reduces the risks associated with running processes requiring root authority (such as sshd).

Upgrading to OpenSSH 3.3 on all versions of OpenBSD enables privilege separation by default (default behavior new to release OpenSSH 3.3). Users of Portable OpenSSH should upgrade immediately to OpenSSH 3.3 and work with their vendors to ensure that Privilege Separation works on their platform.

Read on for the complete text of the message:

- - ------- Blind-Carbon-Copy

Subject: Upcoming OpenSSH vulnerability
Date: Mon, 24 Jun 2002 15:00:10 -0600
From: Theo de Raadt

There is an upcoming OpenSSH vulnerability that we're working on with
ISS.  Details will be published early next week.

However, I can say that when OpenSSH's sshd(8) is running with priv
seperation, the bug cannot be exploited.

OpenSSH 3.3p was released a few days ago, with various improvements
but in particular, it significantly improves the Linux and Solaris
support for priv sep.  However, it is not yet perfect.  Compression is
disabled on some systems, and the many varieties of PAM are causing
major headaches.

However, everyone should update to OpenSSH 3.3 immediately, and enable
priv seperation in their ssh daemons, by setting this in your
/etc/ssh/sshd_config file:

        UsePrivilegeSeparation yes

Depending on what your system is, privsep may break some ssh
functionality.  However, with privsep turned on, you are immune from
at least one remote hole.  Understand?

3.3 does not contain a fix for this upcoming bug.

If priv seperation does not work on your operating system, you need to
work with your vendor so that we get patches to make it work on your
system.  Our developers are swamped enough without trying to support
the myriad of PAM and other issues which exist in various systems.
You must call on your vendors to help us.

Basically, OpenSSH sshd(8) is something like 27000 lines of code.  A
lot of that runs as root.  But when UsePrivilegeSeparation is enabled,
the daemon splits into two parts.  A part containing about 2500 lines
of code remains as root, and the rest of the code is shoved into a
chroot-jail without any privs.  This makes the daemon less vulnerable
to attack.

We've been trying to warn vendors about 3.3 and the need for privsep,
but they really have not heeded our call for assistance.  They have
basically ignored us.  Some, like Alan Cox, even went further stating
that privsep was not being worked on because "Nobody provided any info
which proves the problem, and many people dont trust you theo" and
suggested I "might be feeding everyone a trojan" (I think I'll publish
that letter -- it is just so funny).  HP's representative was
downright rude, but that is OK because Compaq is retiring him.  Except
for Solar Designer, I think none of them has helped the OpenSSH
portable developers make privsep work better on their systems.
Apparently Solar Designer is the only person who understands the need
for this stuff.

So, if vendors would JUMP and get it working better, and send us
patches IMMEDIATELY, we can perhaps make a 3.3.1p release on Friday
which supports these systems better.  So send patches by Thursday
night please.  Then on Tuesday or Wednesday the complete bug report
with patches (and exploits soon after I am sure) will hit BUGTRAQ.

Let me repeat: even if the bug exists in a privsep'd sshd, it is not
exploitable.  Clearly we cannot yet publish what the bug is, or
provide anyone with the real patch, but we can try to get maximum
deployement of privsep, and therefore make it hurt less when the
problem is published.

So please push your vendor to get us maximally working privsep patches
as soon as possible!

We've given most vendors since Friday last week until Thursday to get
privsep working well for you so that when the announcement comes out
next week their customers are immunized.  That is nearly a full week
(but they have already wasted a weekend and a Monday).  Really I think
this is the best we can hope to do (this thing will eventually leak,
at which point the details will be published).

Customers can judge their vendors by how they respond to this issue.

OpenBSD and NetBSD users should also update to OpenSSH 3.3 right away.
On OpenBSD privsep works flawlessly, and I have reports that is also
true on NetBSD.  All other systems appear to have minor or major
weaknesses when this code is running.

(securityfocus postmaster; please post this through immediately, since
i have bcc'd over 30 other places..)

- - ------- End of Blind-Carbon-Copy

(Comments are closed)

  1. By Anonymous Coward () on

    Last time I posted a comment to the effect that it might be smart to rewrite a lot of the network services (ssh, smtp and httpd in particular) in Java because it seems like there is a new vulnerability, especially in OpenSSH, pretty regularly. I get ridiculed for such posts. People say things like, "Just write good quality code and you won't have any problems." Theo et al. are masters of writing stupendously good quality code, and yet as you can see above, even Theo admits that when you write 27000 lines of code, even if these lines are written by paranoid security fanatics, some bugs will creep in here and there.

    So, he does something smart, which is prevsep. Great.

    Why not take this to the next level, though, and code the whole thing in a language which doesn't even allow the program direct access to memory? The brilliance of privsep is that instead of having 27000 lines of code running as root, you have only about 2000 lines that need to be exhaustively verified, making the chances of bugs much much smaller.

    Java is the same idea: Instead of veryfing every single line of a huge program for memory safety, you only have to verify one small section of the JVM. If that is correct, then you know for a fact that there can't be dangerous buffer overflows in any code that runs within that JVM. It's the next logical extension of privsep.

    I'm not criticizing Theo and the OpenBSD crew. They are masters, and they are paranoid (and that is a complement). But, they are human.

    1. By Justin () on

      It has been my experience that Java is much slower and eats a lot of CPU clock cycles. I am not a Java OR C programmer but I don't want to have to upgrade my system to run sshd, httpd and smtp because it is all in Java. Maybe it would be more secure (maybe not) but that is a trade off I am not willing to make. Plus, this is the heart and soul of open source software IMO. No one said "OSS is the greatest, most bug free code ever to exist". People have the chance to band around each other and make things work, you are not dependent on one company to fix all of the problems.

      And who is going to write a Java sshd and httpd and smtp that is good enough for OpenBSD? If the major developers don't know Java well enough to do it, it probably wont get done because they are busy fixing bugs and writing new code in the language they know.

      Maybe I am not even close to how it really is as I mentioned I do not know Java or C (I am learning Perl now)

      1. By Anonymous Coward () on

        Speed always comes up when we're talking about Java. When it first came out, Java definitely had performance problems. The problems are mostly gone, but the reputation lingers on. Java is usually, but not always, a little slower than carefully written C. Sometimes much slower, but sometimes maybe a little bit faster. The reason for this is that a C compiler can only optimize code as its compiling. The JVM can optimize what it is doing by seeing what the code is doing as it is actually running. In short, Java is plenty fast these days, and CPUs are very very fast. You would not have to upgrade your machine to support Java SSHD, but even if you did, how much does a 2ghz cpu cost these days? $200 or so?

        The much bigger issue is that the OpenBSD team is 100% C, and Java would not fit in well with them. I am not sugesting that OpenBSD should start doing their stuff in Java. It's not their thing. Maybe that someone (like me) should start writing some critical network services (like ssh) in Java, and people who want to try those out instead of OpenBSD's stuff will try it, and if they like it, great, that's what open source is all about, right?

        One good bit of news is that some of the services are already done, or well under way. Tomcat is a great http server, with a great security record (because the JVM is basically a jail for the code to run in). Also, James, a Java smtp server, is more or less ready for the real world. That leaves ssh and dns as the two big services we still need which don't yet exist in Java. Guess what I am working on one of those right now.

        I just upgraded my ssh on my OpenBSD 2.8 box. Always fun when the box is a long flight away and no one can help if you screw up. It all went smoothly, though. Privsep is a very good idea.

        1. By Chris Wagner () on

          Java is still a speed problem, the JVM isn't very intelligent about optimizing the running code. As for getting a new CPU. In addition, you would probably need to clarify what you mean by "carefully written C." Are we talking M$ code here? My experience is that Java is considerably slower than a carefully (in my experience and opinion) coded C program.

          The CPU itself might be $200 (For an Athlon, add a bit for an Intel), you also have the cost of the board ($100-150) because you need a new board to support the chip, plus new RAM (at least $60-120), etc..

          As for security, yes, I will admit, it has the capability to be more secure, but I still think C is a better bet.

          I'm also a little uncomfortable with having to go back to Sun for my JVM, seems a little monarchial to be, but then again, I'm weird.

          Thanks for listening to my rant! :)

          - Chris

        2. By Insignificant Other () on

          It doesn't work well with graphical stuff (though it has been done, however it can compile java to native code and has most of the libraries you'd need for network apps.

          You still get the advantage of bounds checking, but you get native code. Really improves the use of Java in situations like this.

          1. By Anonymous Coward () on

            That is a very good idea for writing these kinds of services. Sure, it is not as fast as well-tuned C code, but let's get real here: How much load is SSH anyway? You log in to your favorite machine for a shell. Maybe this shell consumes 1% of CPU? So Java is twice as much of a hog and consumes 2% of CPU?

            Ok, after my DNS server is done (it's almost there) I'm going to get to work on a SSH server.

            1. By Insignificant Other () on

              I don't know who you are, but if you do, set up a website (or some focal point) for it, and I might be able to help. Most of my time is taken with work, but I'd love to work on a java ssh server.

              It will probably need a little C code to get user info from openbsd, but it would be a very tiny portion. All the network/crypto could be done in java.

              There's a good java crypto library under bsd style license (it's reasonably lightweight as well) at:

              I'm sure there'd be a few other java people interesting in doing this. I know I love the idea of the challenge.

              1. By Anonymous Coward () on

                Ok, I'll put you on my list for this project, but how do I contact you? You can send me email at the letter h, twice, followed by the word for astronomical time (ends in "real"), in the beautiful tld of Kazakhstan.

            2. By Anonymous Coward () on

              It really depends on what you are doing with your sshd. I've seen sshd using up to 6% of CPU time during a large scp job over a 100Mb switched network (600MHz P-III w/512MB RAM before you ask). Double that for Java and you have a sizeable chunk of the CPU time used. Then start adding in other users on a multi user machine... I guess I'm just saying that doubling resource usage is a bad idea.

              1. By Anonymous Coward () on

                Ok, so you took a low-end machine, and were able to saturate a fast switched 100mb link and use only 6% of the cpu in the process. Thank you for proving my point! ssh doesn't take up a lot of cpu and even low-end machines these days have gobs of cpu to spare. The usage you described is the worst-case usage for ssh and it still only needs 6% of the cpu. Are you going to have a dozen users all doing that at the same time on that low-end machine? I didn't think so. ssh is a lightweight protocol and the crypto is very fast these days so let's not even talk about performance on this.

                It all comes down to economics: If a Java ssh gives us a little more security than a C ssh, and if it requires, say, $100 extra hardware for the same performance, the question is simply, is the extra security worth the extra $100? There is no generally right answer on this. It all depends on the particular case. I won't try to make that decision for you ahead of time.

                1. By Anonymous Coward () on

                  It all comes down to economics

                  there is a lot more to the internet than first world countries capable of spending extordinant amounts on new equipment every few months. a good portion of my firewalls are 486's scraped together and put into use.

                  recycle - reuse, some parts of the world realise the multiuses of the first world's trash, and we're damn happy that Theo blesses us with modern software capable of running on ancient hardware.

                  I'd much rather patch every few months than supply a landfill every few months.

                2. By Anonymous Coward () on

                  The link wasn't saturated, the bottleneck seemed to be the write speed of the receiving disk. So there's room left for other users to be utilising the network and demanding CPU time. Doubling resource usage for no real gain in security (buffer overruns are not the only security flaw as others have correctly stated) and a significant performance loss is a bad move. I can see the conversation with the boss now...

                  "So, you want me to upgrade all the server hardware at $whatever for trivial security gain and this will slow the servers down as well?"
                  "Yes but we get to use Java!"
                  "Yeah, whatever. Forget it"

                  1. By Anonymous Coward () on

                    also ... WRT the ssh cpu usage, i did a little test ...

                    $ ssh 'dd if=/dev/zero bs=1m count=100' >/dev/null

                    in this case, ssh used approx 35% cpu and sshd used about the same. of course, this is not a real world test because "how often will this happen?", but i think it might help support your statements a little.

                    also, it would seem to me that people who use the "hardware is cheap" argument in support of *bad* software usage/employment decisions are being a wee bit short-sighted. these types of arguments "hardware is cheap" only go directly to the point of supporting "planned obsolescence".

                    planned obsolescence is generally a very bad thing for society at large. fixing a broken toaster used to be the way of doing things until manufacturers decided that tossing the toaster in a landfill and replacing it with another one was better for their bank accounts...

            3. By Jim () on

              Great, so you go from being able to service 100 simultaneous users to 50.

              Besides that, in my experience the slowdown wrt. reasonably written C is more like a factor 7 or 8 than a factor 2.

              And then you go from a usable server to servicing something like 10 people. :-/

        3. By BSD fun () on

          I just installed JEdit on MacOS X (i-Book 600Mhz 128 Mb RAM) The box is enough to play Quake in 640x480 but it is impossible to edit ANY text file in JEdit which is bigger than 32Kb, especially if there are long lines. SLOW you will cry ! I see the Java sucks, at least on Apple hardware. But it is enough for me to mark it SUCKS.

        4. By Chris () on

          Java is plenty fast these days, and CPUs are very very fast. You would not have to upgrade your machine to support Java SSHD, but even if you did, how much does a 2ghz cpu cost these days? $200 or so?

          I write Java and C code every working day, and I can categorically state that Java is slow. The fact that I still have to code my backend apps in C is proof enough of that. I have experimented with C and Java implementations of the same program. Know what? The C versions were three to four times faster, easier to debug and easier to deploy (no worrying that the JVM is only available on a handful of my target platforms).

          And if fast hardware is so cheap, perhaps you could send a 2Ghz processor and motherboard my way.


          1. By Anonymous Coward () on

            Send one my way too except I don't need the motherboard, just cpu. Seriously though, I don't see how someone can use that reasoning.. just because hardware is cheaper doesn't mean we should all be running bloated software. I can see why I would need brand new hardware to run OS X due to all its bells and whistles, but I shouldn't have to depend on a 1ghz cpu to run sshd.

    2. By Anonymous Coward () on

      sun owns java. java is just now getting ported to
      run on openbsd. mcnealy is just as much of a nutcase
      as billg. java is slow as shit. you might as well
      run the code on vmware its so slow. its kind of like
      driving a 57 chevy with 25 year old shocks. Yeah its
      a sweet ride and you get a log of chicks, but man
      its slow and you couldn't cut a tight turn if you
      wanted to.
      did I mention that SUN owns java. Yes java should be
      running the world, BUT mcnealy is as much of a nutcase
      as billg or larryE. java is not free.

      1. By Anonymous Coward () on

        omg i want a log of chicks!@

      2. By Anonymous Coward () on

        Stick to comps jughead. You know shit about cars.

    3. By Ken Wronkiewicz () on

      No, you just exchange one set of bugs for another.

      You are relying on the JVM to be bug-free, itself free of exploitable conditions, etc. Theo and the crew don't have time to deal with a complete JVM and any bugs, interactions, and explitable conditions.

      I have become a semi-believer in formal methods. Write a 2000 line piece of code that is formally proven to be correct and then have everything else rely on it.

    4. By Chad Loder () on

      That's pretty dumb. OpenSSH requires very little RAM or disk space for the binaries. You can run it on small general purpose embedded devices, routers, and what have you.

      Java is OK for some things, but OpenBSD's native Java support is still limited. Requiring a native 25mb JVM port for a small, fast network service like SSH is silly.

      1. By Anonymous Coward () on

        write it in ML, then.

    5. By bengt kleberg () on

      Given that there are several other languages that are better (more secure, less complicated, higher level, smaller, faster, cleaner) than java, i would answer:
      _yes_, a server in java is still a dumb idea.
      just as dumb as a server in c. admitedly in other ways, but still, just as dumb.


    6. By Anonymous Coward () on

      it was a dumb idea when you first posted it, it was a dumb idea the last time you posted it and it is still a dumb idea. get over it.

      public key crypto in java? hah! i'd like to be able establish a ssh session in under five minutes personally.

    7. By Garett Spencley () on

      Aside from all the other really good points against using java there's one other that I would like to mention:

      Java is *just* a programming language.

      Sure it has built in bounds checking so it's damn near impossible to have a buffer overflow in a java app but that's the only thing that it does. Buffer overflows are only one type of millions of different software bugs that can be exploitable.

      Eliminating buffer overflows will not protect you against file race conditions, insecure temporary files, bad authentication algorithms, format string vulnerabilities etc.

      Now since no details have been released regarding this supposed "security hole" how do you know that it's a buffer overflow and/or that using java will fix it?

      Java by itself is not more secure. It's just a language.

      Another point that no one else has addressed is porting the entire 27k lines of code application over to another language. No one has the time, resources or motivation to do such a silly thing.


    8. By Roo () on

      Heres one issue :
      The JVM would surely have to run at root privs to accomplish the same function. What's worse is that you not only have the SSH code to exploit but the JVM code and interactions between them too !

      The setuid paper on the complexities of portable priveledge management was an eye-opener... You're stuck with C for now anyways and you may as well stick with it because the OS is written in C too.

      If you're looking for a better language than C for systems stuff there are more appropriate alternatives such as PL/1 (Multics), BCPL (Actually seems more portable than C) and even Algol-60 !


    9. By drauku () on

      this is definately worth looking at if you wish, but buffer overflows, tmp races, etc are not the only flaws in secure programming. a program can be written incorrectly, i mean in it's logic and how it stores things like passwords for instance.

      what is more important, i think that the actual language a program is written in, is the skill and overall knowledge of the problem he/she is working with.

      this issue is much bigger than a language, yet i think java is a bit of an overkill... sure we can have just as equal alternatives in python, perl, ruby etc...

      i like the way openbsd is moving (while keeping KISS in mind), developing openbsd into a trusted system like os without the trusted system stuff. like privsep and systrace, and the thinking of "does one REALLY" need to be root for this??".

      just my thoughts, and again, this is alot bigger than a single language. nothing makes up for good design and programming with a secure frame of mind (and knowing what tha heck you are doing).


    10. By Vincent Foley () on

      I agree that they should use safer languages, but not Java. First, Java would maybe pose some licensing problems. Then, there's no native Java support on OpenBSD yet (AFAIK).

      If such things were to be rewritten in a safer language, I would vote for O'Caml []: it is very safe, very fast (equal and even superior to C++), memory mangement is done in a very efficient manner by the garbage collector.

      There's only one downside to using O'Caml: the size of the binaries is much larger than that of C programs. But I place safety above drive space.

      See how O'Caml fares against other languages in terms of speed (2nd), memory usage (2nd) and less lines of code (1st).

    11. By Nobody You'd Know () on

      SSH is big, slow, and in very common use. Writing it in a language where your average program takes 2-3 times as long to perform a given task is like setting back the clock three to four years in terms of hardware speed. If security starts to seriously impinge on performance, people quit using secure systems. It is better to be almost perfect and fix things quickly than to be perfect and have no users except a couple of college students and three Java fanatics. I bet even Gosling himself would not do ssh in Java.

      Also, who are you suggesting will write this new code? Do YOU have time to write 25-30k lines of new code, debug it, and maintain it? I know for a fact that Theo doesn't.

      Finally, why on earth would OpenBSD's developers support a proprietary language whose owners refuse to support OpenBSD? That's just fucking stupid.

      In short, you are a complete fucking idiot driven by Java hype rather than rational thought. Have a nice day.

      1. By Roo () on

        1) Anyone is allowed to implement a Java compliant compiler/JVM/library.
        2) You only need to get the "proprietry" blessing from Sun if you call it Java.

        I don't think Java is "evil" from that point of view. Sun have a good track record of creating standards and letting anyone play, even if a lot of that stuff seems as if it could be done a lot better.

        "In short, you are a complete fucking idiot driven by Java hype rather than rational thought"

        I think you're suffering from a rational thought deficiency yourself dude. ;)


    12. By Anonymous Coward () on

      You don't code, you pretend to understand technology and then you suggest something that no one with a clue would suggest...

      You must be a manager.

  2. By LT () on

    Ok this is not a flamebait. I really want to know.. since OpenSSH is enabled by default on OpenBSD for a while now, would this vulnerability invalidate OpenBSD's record of five years without a remote hole?

    1. By Josh Jore () on

      Yes, the statement is that if you perform a stock install and change nothing - is *that* exploitable. I take it that this is so the catch-phrase needs to be updated.

      That isn't quite the point though. I run OpenBSD because it's done well and I can sleep at night. Bugs are inevitable, what you do to prevent them and in mitigation make the difference (assuming programmers of equal skill).

      1. By LT () on

        Yes, I understand. I run OpenBSD for the same reason.

        Catch phrase it may be, but the loss of that record would make it slightly more difficult for me to sell OpenBSD to management.

        1. By Anonymous Coward () on

          fine, sell it to them this way:

          five years with 1 remote hole.

          feel better?

    2. By Sal Ajander () on

      I believe Privilege Separation has been enabled by default in OpenBSD for some time, and therefore i think this means it is not exploitable. Ergo, record stands?

      1. By LT () on

        But privilege separation wasn't even around five years ago. It wasn't even included in the OpenSSH version that came with OpenBSD 3.0.

      2. By Anonymous Coward () on

        Privilege seperation is not enabled by default in 3.1, and PermitRootLogin is. Not a very smart choice all around.

    3. By frustrated sysadmin () on

      The claim of "five years without a remote hole in the default install" can only be true if one plays a twisted game of semantics.

      Apparently, a "default install" does not mean a fresh install from a released version of OpenBSD, presumably from an official CD set sold by the OpenBSD team. No, a "default install" means that you have to keep applying all the latest patches as soon as they come out, and then you'll be safe.

      Which, as I'm sure most of us will agree, is an absolute crock of horse dung. "Default" does not mean "heavily patched and obsessively maintained" - it means "out of the box", or in a natural, unmodified state.

      Also, a slight change to the meaning of "remote hole" means that any included daemon cannot be a "remote hole" if it was not installed and activated by the OpenBSD installer.

      Given that OpenSSH before (and up to 3.3) has been shown (and now, merely claimed) to have vunlerabilities, I'd say it's about time for Theo DeRaadt and crew to face facts: their code isn't perfect, remote holes happen, and let's all be honest with each other about how secure OpenBSD really is. Nobody benefits from false advertising, and informed sysadmins look for well-written patches (see my comment below) in a timely manner, not empty claims of security.

      1. By Anonymous Coward () on


        This is the first remote root exploit in the default in five years. Do your homework....or is this an intentional troll?

        1. By Anonymous Coward () on

          Yes, the streak has been broken. I knew all sorts of trolls would be coming out of the woodwork. They are going to screech with glee that a remote hole has finally been found, disregarding the fact that their favorite OS slogan should be "five hours without a remote hole."

          Even Joe DiMaggio's 56 game hitting streak had to come to an end. And that record hasn't been broken for 61 years (assuming the guy on the Marlins doesn't make it).

      2. By Anonymous Coward () on

        > The claim of "five years without a remote hole in the default install" can only be true if
        > one plays a twisted game of semantics.

        While the rest of your post is complete horse poop, this is somewhat true. It is a statement that relies on semantics. The default install is what you get from the official CD set, or from the released version on the FTP sites. You must not disable any services, or enable any services. You must be able to gain access remotely, without re-configuring any of the services. For example, a hole in sendmail does not count as it cannot be exploited remotely unless you change the configuration to allow remote connections.

        You shouldn't rely solely on such statements to make decisions anyways. OpenBSD has a track record that speaks for itself. Not only are the developers very security conscious, they have created a very stable and robust operating system. I say kudos to Theo and crew for putting in the time and effort to make OpenBSD available.

        1. By BokLM () on

          Yes, OpenBSD is a really good OS.
          But this sentence does not mean anything.
          If it means no remote hole at all, then it is not really possible.
          If it means no remote hole in the default install without modifying anything that's ok, but that does not mean at all that the OS is secure or not, and it's not very usefull (unless the default install is enought for you, but I don't think a lot of people use it like this).

          But I really like OpenBSD, that's why I use it everyday :)

    4. By Anonymous Coward () on

      Yep it is toast. It was bound to happen sooner or later. Still, 5 years is a pretty damn good run!

    5. By _azure () on

      I hate to be the person who suggests that we wait to see what the announced hole is before we start making decisions for them about what does or doesn't belong on their website, but I will.

      We don't have enough information to be starting this thread yet.


    6. By drauku () on

      I believe that if you are using openbsd cause of this
      one statement, then you shouldnt be using openbsd.

      also as a sidenote, i dont believe it really meant much anywho, as basically nothing was running by default... it should have been in the FAQ instead of something out of a marketing department (tm) or something.

      i personally use openbsd because i believe that the developers have KISS and know what they are doing, for the most part. This is a project where people honestly care about doing the job right, and not trying to cram as much crap that users want into the kernel and maybe clean up the mess later.

      even if it doesnt sell as much cd's as fbsd or redhat, i believe that this is still the correct way to go about developing software.

      if you dont feel this way, and cant read the FAQ (this isnt directed at any one person, but in general), and dont have that desire to be curious and play... then maybe you made a mistake in choosing openbsd.

      just my 2^2 cents

    7. By BokLM () on

      I think the sentence "The proactively secure Unix-like operating system." would be better than "Five years without a remote hole in the default install!" on the main page.

      But that's not very important :)

      1. By Justin () on

        Or to quote off the cd case "Multiplatform Ultra Secure Operating System"

    8. By Mark () on

      My understanding was the the remote exploit had to be posted to bugtraq? Has this been done? No one is saying that the code is not remote exploitable. If they are so active that they release fixes for the exploits before the exploits themselves are released on bugtraq - then that is a good thing. Lets wait for the anouncement.

    9. By Not Really Anonymous () on

      Who really cares about that statement?!

      Honestly, would you stop running OpenBSD if that statement was broken? I know I wouldn't, I would patch my servers and keep on humming.

    10. By check out the site () on

      One remote hole in the default install, in nearly 6 years!

      everyone happy?

  3. By Two Coors and a shot of Jack () on

    Here is after upgrade to 3.0-stable:
    $ssh -v localhost
    OpenSSH_3.3, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
    debug1: Reading configuration data /etc/ssh_config
    debug1: Rhosts Authentication disabled, originating port will not be trusted.
    debug1: ssh_connect: needpriv 0
    debug1: Connecting to localhost [::1] port 22.
    ssh: connect to address ::1 port 22: Connection refused
    debug1: Connecting to localhost [] port 22.
    ssh: connect to address port 22: Connection refused
    now connection refused is because sshd won't start ahd here is why?

    $sudo sshd
    /etc/sshd_config: line 75: Bad configuration option: UsePrivelegeSeparation
    /etc/sshd_config: terminating, 1 bad configuration options

    I mean wtf? If I disable privsep, sshd works fine.
    I recompiled the kernel before this, of course.

    1. By Anonymous Coward () on

      um all the ssh config options are in /etc/ssh/ now... not in /etc read your docs and fix jor stuffs!

      1. By Ray () on

        That's weird. In none of the man pages do I see any mention of /etc/ssh. I only see it in the upgrade instructions for OpenBSD 3.1. Is it a typo? Or can sshd_config be in either /etc or /etc/ssh? Or does /etc/ssh only apply to OpenBSD 3.1? It works fine for my 3.0 system in /etc.

        Also, if I run top and I see the user logged in as owning an sshd process, that means that privelege separation worked, right? Otherwise, it should show root, right?

        1. By Jeff () on

          ayup, you're correct about the "user" owning an sshd process...

          for example:
          -+= 00001 root /sbin/init -+= 32183 root /usr/sbin/sshd -+= 25461 root sshd: jan [priv] (sshd) -+- 28008 jan sshd: jan@ttyp9 (sshd) --= 16696 jan -zsh (zsh)

        2. By Anonymous Coward () on

          /etc for 3.0, /etc/ssh for 3.1. When you log in on your computer and type "ps ax | grep ssh" you should see something like

          15730 ?? Is 0:00.01 /usr/sbin/sshd
          28745 ?? Is 0:00.08 sshd: username [priv] (sshd)

          If you have the [priv] on the line that means it is running with priv.sep. enabled.

    2. By Colitis () on

      It's not working because you can't spell.

      Privilege, not Privelege.

    3. By Anonymous Coward () on

      It's privilege, not privelege or priviledge or privilidge or whatever funny spelling some people insist on using.

  4. By frustrated sysadmin () on

    ...if they gave some indication that in order to compile this version of OpenSSH on OpenBSD version 2.8, you'll need to have a newer version of OpenSSL (0.9.6 or newer). This isn't documented *anywhere*, and the compilation breaks horribly until this gets fixed. And no, their OpenBSD 2.8-specific patch doesn't happen to include this, or any workarounds.

    It'd also be really nice if they happened to mention that OpenSSH, ever since version 3.1, has been broken for password authentication on OpenBSD 2.8. OpenSSH 3.1 didn't work when it was released, and OpenSSH 3.3 doesn't work now. Yes, public key authentication does work, but password authentication should work too. What changed between 3.0.2 and 3.1 that broke this?

    Of course, I'm well aware that OpenBSD 2.8 has been marked as "no longer" supported and that they are no longer releasing patches against it. Yes, I know that the best option is to upgrade to version 3.0 or newer, but when you're running three full-time web servers with a few dozen clients and their virtual domains, mail accounts, and PHP/Perl scripts, you can't really afford a lot of downtime to upgrade, play the patch game, and suffer through a horribly-documented ugprade process in order to make sure that you have no remote holes or other silly vulnerabilities.

    I've griped about this before, and I know I'm not alone. After having used OpenBSD in a full-tim environment for more than a year, I'm thoroughly displeased with the way the team releases patches, ends support for "older" versions, and generally does a poor job of documenting what they do, and how to keep up to date.

    I am *this* close to installing Gentoo Linux on the server. Somebody convince me why I should stay with OpenBSD.

    -- frustrated sysadmin.

    1. By Anonymous Coward () on

      Yeah go ahead using linux, with 4 different kernels, 100 distro's, 100 package formats and more bugs than m$... and still complain about OpenBSD...

      If you want a better product without paying for it, HELP the OpenSSH team... You are using a FREE product and you are returning something like "i'm gonna use linux if i don't get help soon"
      Go documenting and testing stuff... that's the way it works...

      1. By Anonymous Coward () on

        I really love the hypocrisy of this group. They advocate open source software at the top of their lungs and claim it to be better than the alternatives, but when a serious problem arrises it becomes "you get what you pay for, deal with it." Completely ridiculous.

        1. By Preben "Peppe" Guldberg () on

          Just wondering - are you sure it is the same group of people advocating and saying "you get what you pay for"?

          Oh, and don't trust Anonymous Coward - he is decidedly schizophrenic.

          Rage away...

        2. By pravus () on

          i personally use opensource software. i tell other people about opensource software. i show them what is possible and how it compares to proprietary software.

          i also say, however, that if you can't swim, get out of the ocean. if you can't get your opensource software to work the way you want, switch to a proprietary solution. it's not like i force people to use it. they do so by their own will.

          i just get really tired of people who try opensource software, get to a point to where they depend on it, and then decide that just because they use it, someone owes them something. like using opensource software gets them some special privilege or something. get real. if you want service, you have to pay for it.

          1. By Anonymous Coward () on


      2. By LT () on

        I really hate this attitude that I keep seeing among the open source community. It's this really bad attitude that when users complain about a certain feature that's missing or bad documentation, etc., open source bigots would start saying "Why don't you do it yourself?"

        Well users don't always have the time to code or write documentation, etc. Not everyone has that motivation or energy to contribute to an open source project. Users aren't so free (as in time, not beer nor speech).

        When users complain, open source developers should see this as a problem, and if they can't handle it themselves, they should advertise the problem and try to get someone out there who's interested to fix it. We shouldn't get back at the user and say "go do it yourself".

        1. By Anonymous Coward () on

          When users complain, open source developers should see this as a problem, and if they can't handle it themselves, they should advertise the problem and try to get someone out there who's interested to fix it. We shouldn't get back at the user and say "go do it yourself".

          OpenBSD developers are users. the whole reason they started developing in the first place was b/c they were once users who complained about a problem and decided to solve that problem.

          They complained about ssh and eventually decided to roll their own. They complained about ipf and decided to roll their own too. It seems to have worked for them (for the most part), why can't it wok for others?

          does "LT" stand for "Large Troll"? I'll save everyone else the trouble: IHBT. IHL. HAND.

          1. By LT () on

            Yes I agree that OpenBSD developers are users.. however, not all users are OpenBSD developers. So not all users are interested in development. They may not have the time or skill. That's why it won't work for others.

            No LT does not stand for Large Troll.

        2. By pravus () on

          you seem to be assuming that most people think that the casual user *should* use open source software. i personally could care less about who uses open source software. i'm glad it's here because i use it. apparently there are quite a few people that seem to also be glad that open source is here. but the people that say "open source is for the common user" and chant the "desktop, desktop, desktop" mantra are just kidding theirselves. it's good to have goals... reasonable goals that is.

        3. By Anonymous Coward () on

          I think the, "I am *this* close to installing Gentoo Linux on the server. Somebody convince me why I should stay with OpenBSD" type comments are what set people off. Especially since switching to another OS wouldn't solve any of the problems he is talking about.

    2. By fansipans () on

      use what you know, use what works for you. i'm still running 2.8 on a fileserver at home, but that's because i'm the only person that uses it, and it's officially treated as 'insecure' in every way possible. but there's no way i would endager people who rely on me for their servers by running software that's two years old when there's shiny new stuff i can install, not just for their sake but mine (how would you feel if you forgot your mod_perl/php/blah was 14 months old and had three different ways to break into it). there's so much going on these days (at an average installation) that one can hardly keep track of everything, and a good way to keep your bases covered is through continuous & diligent upgrade cycles for all of your systems & their software


    3. By Hans Insulander () on

      So, you business relies on an operating system that is known to have many known bugs that the vendor officially says it will not support.

      Please understand that this is a volunteer project - if you want 2.8 patched and fixed, why don't you do it yourself?

    4. By Rodolphe Ortalo () on

      I understand that backporting bug fixes, especially security fixes, can be really desirable for a competent administrator. And raise frustration when not possible.
      However, I understand also from your intervention that your requirement for continuous uptime may be even higher than for security. (This is not a criticism! After all, only useful systems deserve security consideration...)
      You need to take in consideration the fact that your own maintenability requirements may be very difficult to match, especially by external developpers working over an off-the-shelf OS.

      Maybe the clue is to address the problem at the same level: what about (re)thinking your system operation in order to allow, first the co-existence of multiple versions, and then the switch and retirement. Instead of breaking some functional setup, I always recommend to add a newer system in parallel as a testing system. Once full testing is completed, in general, that newer system is ready to fully replace the original one.

      But, of course, your mileage may vary,

      Rodolphe, in struggle for maintenability.

      1. By Gioffreus () on

        i agree with you fully on the co-existence of multiple versions ... switch and retire strategy. i do this myself on my two workstations (both are critical).

        one of the HDs on station #2 the older, less capable machine is used exclusively for tracking and testing -current, making build/release snapshots, etc...

        i also am running -current from 2002-06-21 as primary system on station #1 (main workhorse =)). i've been doing this for a while now. never had any significant problems as a result...

        i've mostly automated the build/upgrade process to where i can make upgrades and merge changes without worrying about losing important local configuration info.

        works for me... =)
        NOTE: these machines only support 2 actual users.

    5. By Miod Vallat () on

      The maintainence work on previous releases takes a non-trivial amount of time. Especially since patches tend to make use of features not necessarily available on older releases, or simply when some vulnerabilities occur and they can not affect recent releases, usually nobody will bother to check if they can affect older releases as well and do the necessary patch work.

      When it was time to drop 2.9 support, we have considered maintaining it for one more release period, i.e. six months. However, this did not happen, because nobody had a spare machine to dedicate to -stable building and testing, and nobody was also interested in following ipf development and importing fixes when necessary.

      Keep in mind that OpenBSD is a small team and can not do as much maintainance of old releases as we would like to do.

      1. By niekze () on

        the 3.0 Apache patch worked flawlessly on my 2.9 box ;) a lot of times, the code that is being patched hasn't changed much (or at all) between neighboring releases. Not a rule of thumb however. Always good to run a diff on the source on the files to be patched over both release versions.

        Therefore, there are some patches that would require only trivial amounts of time to backtrack. Who's gonna do it? Hellifiknow

    6. By Anonymous Coward () on

      Did you think to apply any of the patches that go all the way back to 2.7?

      How about reading the damned upgrade faq?

      Goahead and run linux. Im sure youll find the documentation sooo much better and installing openssh-portable should be a snap compared to openssh.

    7. By Rojareyn () on

      Here's a suggestion for you:

      Have a spare machine for keeping up-2-date with OpenBSD-current. Keep a copy of your web server configuration on there and make sure that upgrades don't break it. If they do, document what you had to do un-break it. Also, plan for upgrading your production web servers once per year. When it's time to switch the web servers over to OpenBSD 3.latest-n-greatest then you're better prepared for the transition.


      p.s. At least OpenBSD is *admitting* that there is a flaw in OpenSSH. Not all vendors (including some Linux distributors) are so willing to announce potential security holes so readily.

    8. By Anonymous Coward () on

      > I am *this* close to installing Gentoo Linux on the server. Somebody convince me why I should
      > stay with OpenBSD.

      Let me disagree with most of the other people on this forum:

      If you think that Gentoo Linux better suits your needs, use it instead. OpenBSD is very good, but not perfect, and if it's not doing what you want it to be doing, you should seriously consider other alternatives.

      Let me also point out that I think that the cost of switching to Gentoo Linux will be greater than the cost of upgrading OpenBSD. The OpenBSD upgrade process is well documented. You can, in advance, read the upgrade minifaq and download etc31.tgz so that you aren't hit by any surprises. When you sit down to upgrade, you need only boot the install disk, upgrade, and then move a few files. I'd estimate that you would have about fifteen minutes of downtime total. Compare that to the hours that you would spend installing a new operating system. Seeing as you're considering Gentoo, consider how long it will take you to compile everything. Each of your systems will be down for hours, if not days.
      And you still have bugs, compatibility problems, and upgrade issues.

      I'm going to guess here that while you've been using OpenBSD for over a year, you've not tried to track -stable as the OpenBSD developers intend for you to do. If you read the documentation with the expectation that you'll track -stable, you'll find a fair amount of help. And if you decide you'd still rather not, that's your cue to install Gentoo Linux.

      (I've never understood what most people's fascination with Gentoo is. Why would you want to compile everything from scratch every time? Aren't you just making more work for your processor? Wouldn't you rather download binaries? And you shouldn't even have a compiler on a secure production machine!)

      1. By LT () on

        I've never understood what most people's fascination with Gentoo is. Why would you want to compile everything from scratch every time? Aren't you just making more work for your processor? Wouldn't you rather download binaries?

        By compiling everything, Gentoo will supposedly result in a performance increase because every program is compiled in a target-specific manner. However, personally I don't have the time to wait half a day just to get the darn thing to install.

        OpenBSD works for me.

      2. By Anonymous Coward () on

        (I've never understood what most people's fascination with Gentoo is. Why would you want to compile everything from scratch every time? Aren't you just making more work for your processor? Wouldn't you rather download binaries? And you shouldn't even have a compiler on a secure production machine!)

        The point behind compiling is optimization. I compile everything on my Gentoo based p2/266 laptop with 'CFLAGS="-O3 -march=i686 -mcpu=i686 -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -malign-functions=4"'. It's orders of magnitude faster. This is a damn usable machine under XFree 4.2.0 and KDE3.0.1. With Redhat 7.2 it was excruciatingly slow. These optimizations DO make a difference.

        Did it take more time to set up and/or upgrade because I have to compile things? Yes. I start a compile and go to bed.It's done when I wake up.

    9. By George W Bush's black cock () on

      try the openssh portable release
      it will compile on many older releases of openbsd
      just goes to show you where other operating systems
      are at ;)

    10. By pravus () on

      install Gentoo... who really gives a damn whether you run OpenBSD or not? i know i don't... my upgrade went flawlessly.

    11. By knomevol () on

      i'll upgrade all three machines for you. maximum downtime of one hour per machine and i'll do it during the midnight of your preferred timezone. $2000 plus travel expenses.

      you're just upset, of course you wouldn't do anything as ridiculous as change to linux. i mean, listen to yourself... you've been running a business on obsd 2.8 this whole time? i guarantee you if that had been your bucktooth linux distro it wouldn't have had this uptime.

    12. By couderc () on

      Of course, I'm well aware that OpenBSD 2.8 has been marked as "no longer" supported and that they are no longer releasing patches against it. Yes, I know that the best option is to upgrade to version 3.0 or newer, but when you're running three full-time web servers with a few dozen clients and their virtual domains, mail accounts, and PHP/Perl scripts, you can't really afford a lot of downtime to upgrade, play the patch game, and suffer through a horribly-documented ugprade process in order to make sure that you have no remote holes or other silly vulnerabilities. Well this is a false problem. You can create your own tarballs (man release) on a single box and then update each box in less than 15 minutes (in the case of all your boxes uses same arch).
      This should be preceded by a preparation phase for updating manually /etc (you should do it on a copy of /etc, and then switch after binary update with tarballs). So you can really save your time by using tools that the team is offering to you ...

    13. By BokLM () on

      Gentoo is good if you want to have the latest version of any program, but I think it is not really good for a server.

      OpenBSD is a lot more stable and secure, Gentoo is not yet stable (and maybe that's not their goal).

    14. By Markus () on

      there are patches for running OpenSSH 3.4
      on OpenBSD 2.8, just check the the website:

      i don't understand what you complain about,
      since i spend considerable time on producing patches for openssh on openbsd 2.7 and later.

  5. By lorenzo () on

    the 'privilege' thing requires a /var/run/sshd directory. so if you have /var/run mounted as tmpfs, be sure to change it and create /var/run/sshd otherwise you'll lock yourself out of your servers if you'll have to reboot.

    Just wanted to tell you.

    1. By Gioffreus () on

      what OS does your statement apply to..?

      this does not *seem* to be the case on OpenBSD. IIRC, tmpfs is a Linux thing (mfs on *BSD)... i believe your /var/run/sshd most likely corresponds to /var/empty on OpenBSD . Note: ICBW ...

      1. By lorenzo () on

        yes, I was talking about linux. Sorry, I came here following other links and while I posted I was taking care of servers with /var/run as a filesystem in RAM.

        Sorry people I screwed this up :)

  6. By Vig () on

    I've recently upgraded a machine that isn't running OpenBSD to OpenSSH 3.3p1, I notice that in the manpage for sshd_config it has the following regarding the UsePrivilegeSeparation:

    "The default is ``yes''."

    The UsePrivilegeSeparation directive is listed in the sshd_config file included with OpenSSH 3.3p1 but it is commented out. The confusing issue here is that a number of posts related to the upcoming OpenSSH vulnerability explicitly advise you to enable this in your sshd_config file which seems rather redundant if the default is enabled.


    1. By Gioffreus () on

      maybe it's not so confusing..?
      what if someone decided to disable privsep..?
      in that case advising to enable it would not really be redundant i think...

      as per the sshd_config:

      # $OpenBSD: sshd_config,v 1.56 2002/06/20 23:37:12 markus Exp $
      # The strategy used for options in the default sshd_config shipped with
      # OpenSSH is to specify options with their default value where
      # possible, but leave them commented. Uncommented options change a
      # default value.
      #UsePrivilegeSeparation yes

      1. By Anonymous Coward () on

        there exists the possibility you are running a version of openssh which supports privsep but doesnt have it enabled by default. in this case adding "UsePrivilegeSeparation yes" to your sshd_config, adding the appropriate user/dir, and restarting sshd is the quickest solution.

    2. By drauku () on

      They are there to show you the defaults, and can easily change it.

      not that big a deal.

      also notice that rc.conf has all the defaults in ther e as well. same thing.

    3. By Todd T. Fries () on

      One other thing that might be worth pointing out is that some versions prior to 3.3p1 did not have it enabled by default, and
      therefore you would be able to run privelege separation before
      upgrading. Note the wording that there is better support for
      some configurations of privelege separation in 3.3p1 .. even in
      current OpenBSD, kerberos is broken wrt privelege separation. This is being fixed, however. ;-)

    4. By Theo de Raadt () on

      We have just removed the phrase
      "Five years without a remote hole in the default install!" from

        1. By John () on

          Is a Fact. See

          1. By BokLM () on

            Yes, so maybe that was not a fake :)

  7. By Anonymous Coward () on

    I have several servers, dns, web, etc.
    I usually run them on snapshots, and they WORK!
    Uptimes in the hundreds of days. Some of these are busy, mission critical.

    In the past I just grabbed the latest snapshot and if it stayed up for a day or two, and all the needed ports or packages ran, then I put it online and it just WORKED! Ran forever.

    Recently I needed to replace a web server that had been running OBSD 2.5 on an Intel P3-350. I grabbed the latest snapshot, installed great, then tried to install the net-snmp port and got all tangled up. Reading the mailing lists, I found out that another package - maybe ssl - had changed and to get net-snmp working would take some real debugging, or waiting for the developers to adapt to the new version of ssl. My Bad, I had been burned by the "snapshot bleeding edge" syndrome.
    So I installed 3.0, net-snmp runs fine and off I go.

    But what is the easiest way for getting to stable? Must I go through the Install 3.1, CVS the STABLE branch, recompile everything way? I'm a snapshot kind of guy, and it has been good to me, thanks to the careful work of the OpenBSD crew.

    Just this time I would like to see snapshots made of the stable branch, so I don't have to spend time compiling and fixing. BTW I buy multiple copies of each CD released, even if I just run snapshots. Works for me, up to now...

    1. By Anonymous Coward () on

      If you are the "snapshot-kind-of-guy" shouldn't you be able to figure it out by yourself then? Snapshots are for developers and people that like to tinker with their computer. It is not for running servers that needs to be up and running all the time.

      1. By Anonymous Coward () on

        Snapshots are for developers and people that like to tinker with their computer

        Maybe so, but I have had uptimes of 300+ days on snapshots on production systems. DNS servers with a host file of 10,000 entries. I have been burned once. I don't have a lot of time to spend compiling everything. Generic kernel works fine.

        If they didn't work so well, it would not be a problem. Ha! How is that for a situation, the snapshots are too good.... I think I'll go try one.

        1. By Anonymous Coward () on

          I have had uptimes of 300+ days on snapshots on production systems.

          and i have had uptimes of 100+ days on Windows 95. Ran my TV software and setiathome on a P-133/44. Only went down for hardware changes. But i'm still not gonna use it in a production environment b/c it's not meant for that.

          1. By Anonymous Coward () on

            Wasn't Windows 95 supposed to run no longer than 32 days? After that time it reboots? And didn't it take about 5 years to find this out, because nobody ever tried to run Win95 even for 32 days ?

        2. By fansipans () on

          yeah dude! like the snapshots right before they backed out UBC! when random i386 testing boxes of mine would crash every day! oh yeah! and when the team does massive pf changes and nat breaks (as it is right now iirc). dude yeah! run current! that guy's only been burned once! and the '10000' domain's he hosted only got burned once too! cool! that's only ten thousand domains! let's have people not be able to rely on computers because we have big dicks! *MOMF*!

          in summation: don't run -current unless you know what you're doing and a people aren't relying on you.


          1. By Anonymous Coward () on

            Learn to read. He said 10,000 hosts, not domains. And if a snapshot has been running for 100 days, that means it hasn't been replaced with a later, unstable snapshot. Duh. Following the mailing lists makes it pretty easy to avoid snapshots when major changes are producing waves.

            1. By fansipans () on

              Following the mailing lists makes it pretty easy to avoid snapshots when major changes are producing waves.

              exactly. so people who know what they're doing and aren't being relied on can mess around with snapshots. and despite my 5am post being incorrrect wrt hosts instead of domains, point is: 10000 somethings are relying on a snapshot, and that's just asking for trouble (in principle, maybe not in practice for his case, but i tend to live my life by principles as opposed to what seems to maybe should work out)


              1. By Anonymous Coward () on

                10000 somethings are relying on a snapshot

                Well the principle seems to be, if it stays up, good, if it crashes then go to a stable release.

                From what I have seen, Theo pleads for everyone to test snapshots right before a code freeze in 1preparation for release. That means a some more testing, but not scads more. Mostly it is just new stuff that is not getting added.

                So a release is a snapshot that got
                more testing. Feedback, Feedback, Feedback.

                1. By fansipans () on

                  right, so if you know what you're doing and can actually donate quality feedback, and nobody is relying on you or the interruption in service would be acceptable then go for it. but if you're running a dns server or web proxy for a small university or medium-sized business, and you're operating under the phrase 'if it crashes go to a stable release', you might have some explaining to do to your boss as to why 'they only lost access to the internet for 45 minutes or so'. the initial message which started this thread seemed to imply that snapshots are something you can just chuck on a server and expect to work. that's the kind of statement which perpetuates idiots posting questions to -misc and technical staff screwing over their organization


  8. By Justin () on

    Takes a comment to possible hurt the pride of people to start major threads! Usually there are only 1-5 comments per story on This one is over 80 already. Sheesh. Calm down, patch your system (or if it is too old, upgrade it) and continue with your life.

    1. By pravus () on

      ignorance is like a vine. give it an inch and it'll take the entire planet.

  9. By Jedi/Sector One () on

    It looks like there's another very serious flaw that has just been fixed in OpenBSD's resolver library (maybe other BSDs are affected as well, the FreeBSD code looks very similar) .

    1. By fansipans () on

      yep was just updated to add 007 w/a link to a very soonly forthcoming patch (next few hours i'd assume as mirrors sync up)


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