OpenBSD Journal

Only two remote holes in the default install, in more than 10 years!

Contributed by merdely on from the two holes in 10 years is almost celibate dept.

As previously reported, there is a security issue of "incorrect mbuf handling for ICMP6 packets" which can lead to remote code execution or system crash.

The importance of updating OpenBSD systems was further illustrated today with a post by Theo de Raadt on misc@ urging OpenBSD users to "have our latest patches installed." If you can't immediately patch your systems and do not use IPv6, put "block in inet6" in your pf.conf. Then visit the 3.9 or 4.0 errata pages for the patches.

While this is a blemish on OpenBSD's stellar security record, only two remote holes in more than 10 years is still amazing.

(Comments are closed)


Comments
  1. By Anonymous Coward (68.165.27.172) on

    is this fixed on the 4.1 cd?

    Comments
    1. By tedu (71.139.164.105) on

      > is this fixed on the 4.1 cd?

      yes

  2. By Anonymous Coward (70.162.93.223) on

    Damn.

    Comments
    1. By Chazza (69.109.104.15) on

      not sure if this is a mistake. the patch's file name is "020_m_dup1.patch", but the contents of the patch state:

      patch -p0 < 010_m_dup1.patch

      Comments
      1. By Chazza (69.109.104.15) on

        > not sure if this is a mistake.

        duh, forget it. sorry, need sleep.


  3. By Anonymous Coward (213.119.198.47) on

    This only shows that to err is human and that security still is a process, not a single product. At least everyone's already patched :-)

  4. By Anonymous Coward (195.159.118.253) on

    what happend to W^E? Shoudn't that feature provide some protection against this type of attacks (code execution)?

    Comments
    1. By Chris Rohlf (66.192.62.90) chris@calyptix.com on http://blog.calyptix.com/2007/03/second-openbsd-remote-hole-in-more-than.html

      > what happend to W^E? Shoudn't that feature provide some protection against this type of attacks (code execution)?

      Its called W^X and it is implemented on pages (virtual memory) in userland programs. This overflow however occurs in the kernel and allows for a function pointer overwrite and another technique involving the linked list pointers that the mbuf subsystem uses to gain control of execution.

      We wrote up a quick summary on our blog

      http://blog.calyptix.com/2007/03/second-openbsd-remote-hole-in-more-than.html

      chris

    2. By Igor Sobrado (sobrado) on

      > what happend to W^E? Shoudn't that feature provide some protection against this type of attacks (code execution)?

      W^X (write xor exec) is certainly a good protection against certain attacks; but it depends largely on hardware support. Some platforms have a full support for this technique (e.g., amd64), others do not have per-page execution bits and will set permissions for larger segments (e.g., the i386 architecture) or do not support this protection scheme at all.

      On the other hand, shared libraries on ELF operating systems have .got and .plt sections that need to be both executable and writable on certain architectures.

      Comments
      1. By Chris Rohlf (66.192.62.90) chris@calyptix.com on www.calyptix.com


        This can also be implemented in software without having a processor with an NX bit. OpenBSD includes this for architectures like x86 Intel. It is using the CS segment to draw line between where memory is executable and where it is not.


        > > what happend to W^E? Shoudn't that feature provide some protection against this type of attacks (code execution)?
        >
        > W^X (write xor exec) is certainly a good protection against certain attacks; but it depends largely on hardware support. Some platforms have a full support for this technique (e.g., amd64), others do not have per-page execution bits and will set permissions for larger segments (e.g., the i386 architecture) or do not support this protection scheme at all.
        >
        > On the other hand, shared libraries on ELF operating systems have .got and .plt sections that need to be both executable and writable on certain architectures.
        >

        Comments
        1. By Igor Sobrado (sobrado) on

          > This can also be implemented in software without having a processor with an NX bit. OpenBSD includes this for architectures like x86 Intel. It is using the CS segment to draw line between where memory is executable and where it is not.

          I was not aware about this improvement (computer security is certainly not my research field!). Nice to know that workarounds exist for these less secure architectures. As I never read about the TLB hacks (out of the arm architecture) I supposed that i386 had a weak W^X implementation as a consequence of a careless design in the architecture.

        2. By Anonymous Coward (87.79.237.121) on

          > This can also be implemented in software without having a processor
          > with an NX bit. OpenBSD includes this for architectures like x86
          > Intel. It is using the CS segment to draw line between where memory is
          > executable and where it is not.

          This is not possible for CPL 0 (kernel ring) though.

      2. By Igor Sobrado (sobrado) on

        Chris Rohlf is right. I am just outlining how W^X is supported in a general way, not speaking about *this* specific kernel-related security problem, as the (anonymous) original poster asked about "this type of attacks". The state of the art security improvements implemented in OpenBSD (W^X, ProPolice, privilege separation and so on) prevent a large number of attacks against the operating system but cannot stop any possible attack. I certainly would recommend reading the "Exploit Mitigation Techniques" slides presented at the AUUG'2004 annual conference by Theo de Raadt.

  5. By Cabal (Cabal) Cabal on http://www.enginuity.org/

    Given the prevalence (or lack thereof) of IPv6, is it something that should be enabled by default? I would imagine most people capable of using IPv6 (and often tunnels) are capable of recompiling the kernel.

    Comments
    1. By Jeff Quast (dingo) on

      > Given the prevalence (or lack thereof) of IPv6, is it something that should be enabled by default? I would imagine most people capable of using IPv6 (and often tunnels) are capable of recompiling the kernel.

      'block inet6' is so easy its not even funny

      Comments
      1. By sthen (85.158.44.148) on

        > 'block inet6' is so easy its not even funny

        don't forget about any 'set skip on...'

  6. By Jeff Quast (dingo) af.dingo@gmail.com on

    Does anybody in the states have ipv6 connectivity?

    I wish this vulnerability applied to me :(

    Comments
    1. By Brandin (63.228.83.239) on

      > Does anybody in the states have ipv6 connectivity?
      >
      > I wish this vulnerability applied to me :(

      Try this:

      Have another host on your local network segment running some version of an O/S that supports IPv6. That host gets compromised, and leet haxor crafts a packet that takes over your OpenBSD box. May not happen at home where you are the master of your domain, but for others in production networks with mixed systems (read most of the world's organizations) it can happen.

      My days work is cut out for me.

      Comments
      1. By sthen (85.158.44.148) on

        > Have another host on your local network segment running some version of an O/S that supports IPv6.

        No need for the attacking host to support IPv6, it just needs to be able to put packets on the wire.

    2. By Igor Sobrado (sobrado) on

      > Does anybody in the states have ipv6 connectivity?
      >
      > I wish this vulnerability applied to me :(

      I wish to have native IPv6 connectivity too! A simple protocol, with few fields than IPv4 in the default header, 32-bit aligned fields (so can be quickly processed on current routers), and that does not require NAT.

      Until last summer (when the 6bone phased out), I was using the service provided by Hexago... but tunneling all my traffic to Canada was certainly annoying, as it was setting the IPv6 address on our end of the tunnel for each change on the public IPv4 address (alternatively the scripts provided by Hexago could be used, but it was not a very clean set up).

      It would be nice having some OpenBSD services migrated to IPv6 too (syslogd, and Apache[*], probably others). Full IPv6 support would be a good goal for OpenBSD, though.

      [*] KAME has some patches for Apache 1.x, but these changes will modify the Apache API. I think that Apache is not IPv6-ready yet, I would be glad to know if I am wrong.

      Comments
      1. By Anonymous Coward (87.79.237.121) on

        > [*] KAME has some patches for Apache 1.x, but these changes will modify the Apache API. I think that Apache is not IPv6-ready yet, I would be glad to know if I am wrong.

        MirBSD has applied these *and* the OpenBSD patches,
        so if you want a secure *and* IPv6 capable httpd,
        get the sources from MirBSD src/usr.sbin/httpd and
        try to compile them on OpenBSD (probably easy, just
        add -D'__RCSID(x)=static const char __rcsid[] = (x)
        __attribute__((used))' to the command line, other
        than that, there isn't much to do, but didn't try).

        Comments
        1. By Igor Sobrado (sobrado) on

          > > [*] KAME has some patches for Apache 1.x, but these changes will modify the Apache API. I think that Apache is not IPv6-ready yet, I would be glad to know if I am wrong.
          >
          > MirBSD has applied these *and* the OpenBSD patches,
          > so if you want a secure *and* IPv6 capable httpd,
          > get the sources from MirBSD src/usr.sbin/httpd and
          > try to compile them on OpenBSD
          [...]

          Hello.

          Thanks a lot for your advice, but I prefer either stay at the current IPv4 flavour of Apache or install Apache 2.x. An IPv6-ready Apache 1.x would be great, but I certainly prefer to stay at the recommended management techniques.

          Comments
          1. By Anonymous Coward (87.79.237.121) on

            > Thanks a lot for your advice, but I prefer either stay at the current
            > IPv4 flavour of Apache or install Apache 2.x.

            Apache 2? *laugs himself senseless*

            Ask henning@ if you really want to know why.

      2. By patthoyts (194.200.145.5) on

        If hexago was too slow you should look around. I've succesfully run a ipv6 site using an OpenBSD box in the UK by making use of the SixXS tunnel broker. (http://www.sixxs.net/) This broke provides points of presence throughout Europe and some in the US as well. The aiccu software works on OpenBSD too.

      3. By Kurt Miller (69.122.119.232) on

        > > Does anybody in the states have ipv6 connectivity?
        > >
        > > I wish this vulnerability applied to me :(
        >
        > I wish to have native IPv6 connectivity too! A simple protocol, with few fields than IPv4 in the default header, 32-bit aligned fields (so can be quickly processed on current routers), and that does not require NAT.
        >
        > Until last summer (when the 6bone phased out), I was using the service provided by Hexago... but tunneling all my traffic to Canada was certainly annoying, as it was setting the IPv6 address on our end of the tunnel for each change on the public IPv4 address (alternatively the scripts provided by Hexago could be used, but it was not a very clean set up).

        I would recommend using SixXS for IPv6 tunneling:

        http://www.sixxs.net

        If you have a fixed IP address for your endpoint of the tunnel then no extra software is needed:

        /etc/hostname.gif0:
        up giftunnel yourIPv4 theirIPv4
        up inet6 yourIPv6 theirIPv6 prefixlen 128

        /etc/rc.local:
        route -n add -inet6 default theirIPv6

        /etc/pf.conf:

        # partial pf.conf that allows external hosts to ping
        # internal ipv6 hosts (icmp6 echoreq) and unrestricted
        # outgoing ipv6 with implied keep-state (4.1).
        # revise as need by local policy

        # allow ipv6 tunnel from endpoint
        pass in on $ext_if inet proto ipv6 from $ipv6_endpoint \
        to $ext_if

        pass out on $ext_if inet proto ipv6 from $ext_if \
        to $ipv6_endpoint

        # block unsolicited incoming packets
        block in log on gif0 all

        # except allow ping packets in
        pass in on gif0 inet6 proto icmp6 all \
        icmp6-type echoreq

        pass out on gif0 inet6 all

        Without a fixed IP address use the aiccu_20070115 package in 4.1
        for the tunnel endpoint.

        Get a subnet from SixXS and provide native IPv6 to all your hosts on your LAN by adding this to your tunnel endpoint:

        /etc/sysctl.conf:
        net.inet6.ip6.forwarding=1

        /etc/rc.conf.local
        rtadvd_flags="fxp1"

        /etc/hostname.fxp1
        inet6 alias SubnetPrefix:1::1

        Comments
        1. By 2001:470:1f00:ffff::2b (216.62.11.163) on http://tunnelbroker.net/

          > > > Does anybody in the states have ipv6 connectivity?

          I've been using HurricaneElectric's service for years without a problem http://tunnelbroker.net/

        2. By Igor Sobrado (sobrado) on

          Hi patthoyts and Kurt.

          Indeed, SixXS seems a solid project. The RIPE-like handles required by SixXS show that they want to provide a correct and well organized service. Availability of points of presence on key cities, like Amsterdam and Lisboa in Europe, makes this service an excellent choice when good network connection (latency, bandwidth, number of hops...) is required. I will certainly use that service to replace the old Hexago tunnel.

          By the way, thanks a lot for providing a detailed configuration of an OpenBSD machine for this service. I certainly do not want to add software to request a tunnel. As the ADSL service I am using provides mostly static addressed (public addresses linked to our phone numbers, should not change too frequently but I have not verified it as the main server -a net4801- and the ADSL modem/router are up 24/7) static tunnels seem a logical option. It is probably the most lightweight for the SixXS servers too.

          Thanks for this superb advice!!!
          Igor.

  7. By Chris Rohlf (66.192.62.90) chris@calyptix.com on http://blog.calyptix.com/2007/03/second-openbsd-remote-hole-in-more-than.html

    > what happend to W^E? Shoudn't that feature provide some protection against this type of attacks (code execution)?

    Its called W^X and it is implemented on pages (virtual memory) in userland programs. This overflow however occurs in the kernel and allows for a function pointer overwrite and another technique involving the linked list pointers that the mbuf subsystem uses to gain control of execution.

    We wrote up a quick summary on our blog

    http://blog.calyptix.com/2007/03/second-openbsd-remote-hole-in-more-than.html

    chris

  8. By Bernd (129.132.105.166) on

    Release Mode: FORCED RELEASE

    Can anybody elaborate why there is not "Release Mode: COORDINATED RELEASE" written here? Also, why is there no reference to the security advisory, nor CoreSecurity (who we should thank for the discovery).

    Comments
    1. By Bernd (129.132.105.166) on

      > Release Mode: FORCED RELEASE
      >
      > Can anybody elaborate why there is not "Release Mode: COORDINATED RELEASE" written here? Also, why is there no reference to the security advisory, nor CoreSecurity (who we should thank for the discovery).

      ... in the CVS commit. :-)

    2. By Travers Buda (12.216.179.205) traversbuda@gmail.com on

      > Release Mode: FORCED RELEASE
      >
      > Can anybody elaborate why there is not "Release Mode: COORDINATED RELEASE" written here? Also, why is there no reference to the security advisory, nor CoreSecurity (who we should thank for the discovery).

      Check misc@, specifically a reply to Theo's post.

  9. By Anonymous Coward (85.178.96.32) on

    The real shame is not that there`s a Hole but that the developers didn`t want to accapt the fact that this IS a hole.

    It`s a shame that Core-Security had to explain it serval times and release even an Exploit.

    At first it was NO hole
    Then it was a relieable fix
    And now it`s a Patch for a Hole...

    Core Security thinks that this Patch does not Patch the whole hole at all
    but makes the Exploit not working anymore.
    Well Core Security was right once again....

    Comments
    1. By Anonymous Coward (216.220.225.229) on

      > The real shame is not that there`s a Hole but that the developers didn`t want to accapt the fact that this IS a hole.
      >

      The issue was fixed immediately, even when it was thought to only be a denial of service problem by the people who discovered the problem. Over the next few days, the vulnerability was explored and the attack was refined. It takes a while to evaluate a possible exploit, and then develop and test a fix. I'm sure the OpenBSD team worked as quickly as they could, and once they knew that remote code execution was possible, they updated the advisory and their web site.

      Comments
      1. By Travers Buda (12.216.179.205) traversbuda@gmail.com on

        Yeah, this hole does a bit of damage to everyone's pride. But, there was no cover-up.

        It looks as though there was a difference in opinion whether or not this bug would allow code execution. Well, as always, reality was the arbitrator. Everybody profits.

        I think I remember Theo saying something along the lines that OpenBSD does not have the resources to determine whether every bug they fix is exploitable. They can only use their best judgment whether or not it is important, and move on. (And Theo knows his stuff.) Core, on the other hand, had 2-3 people working on just the code execution for (it looks like) a week before they succeeded. And those Core guys are getting paid money to do it.

    2. By Cobalt (70.162.93.223) on

      > Core Security thinks that this Patch does not Patch the whole hole at all

      Their problem was not with the fix (which works just fine, thanks very much), but with the scrub inet6 workaround. The only support workaround now (short of recompiling) is to completely block inet6 traffic completely.

    3. By Jussi Heino (MunOBSD) on

      > Then it was a relieable fix
      > And now it`s a Patch for a Hole...

      Microsoft's wording in their security bulletins is great, IMHO: they say in critical vulnerabilities that that the bug may allow execution of malicious code. When the issue is dissected and appears that it is just a "reliability" issue the Microsoft is safe, no harm done being too cautious. And when the exploit appears "we told you so".

      OpenBSD gave a reason to false security by at first being not too cautious. And feeling secure when not secure...

      Comments
      1. By Travers Buda (12.216.179.205) traversbuda@gmail.com on

        > OpenBSD gave a reason to false security by at first being not too cautious. And feeling secure when not secure...

        I disagree; for most people this is all moot. Anyone who's running a production system certainly does not want people dropping their kernels into ddb>. They patched. And if you were not concerned about such a case (due to the fact that it would probably not happen to you, AKA a home network,) then you should likewise not be concerned about the code execution since you're not a juicy target.

        As to the Team's upgrading this to a vulnerability, see my above post on resources they don't have.

        P.S. I'm surprised this has not spilled over to misc@.

        Comments
        1. By Travers Buda (12.216.179.205) traversbuda@gmail.com on

          > > OpenBSD gave a reason to false security by at first being not too cautious. And feeling secure when not secure...

          Additionally, the nomenclature chosen was not for deception, rather it was for clarification. When there was just the kernel panic, it was a reliability fix. Any patch that finds it's way to errata.html is important. Otherwise, the Team would not bother. It's status was elevated to a vulnerability (code execution) once that was discovered. See? http://www.openbsd.org/cgi-bin/cvsweb/www/errata40.html

          Nobody is deceiving you. By the way, I believe that OpenBSD's focus is more on a good, reliable, documented operating system that does what root tells it to rather than a tin-foil-hat paranoia operating system. The security is just a byproduct of the good code.

          Comments
          1. By Corey (208.191.177.19) on

            It could be the way the advisory was worded, but reading it in isolation, one is led to believe that the issue was initially given somewhat less consideration that maybe it should have been:
            2007-02-26: ...Core requests details about
              the bug and if possible an analysis of why the OpenBSD team may or
              may not consider the bug exploitable for remote code execution.
            
            2007-02-28: OpenBSD team indicates that the bug results in corruption
              of mbuf chains and that only IPv6 code uses that mbuf code, there is
              no user data in the mbuf header fields that become corrupted and it
              would be surprising to be able to run arbitrary code using a bug so
              deep in the mbuf code. The bug simply leads to corruption of the mbuf
              chain.
            
            2007-03-05: Core develops proof of concept code that demonstrates
              remote code execution in the kernel context by exploiting the mbuf
              overflow. [snip]
            Later on, they describe the "m_ext" structure, a part of the mbuf, as containing an element that contains an (exploitable) function pointer:
            This second structure contains the variable ext_free, a pointer to a
            function called when the mbuf is freed. Overwriting a mbuf with a
            crafted ICMP v6 packet (or any type of IPv6 packet), an attacker can
            control the flow of execution of the OpenBSD Kernel when the m_freem()
            function is called on the overflowed packet from any place on the
            network stack.
            Now, knowing nothing about how the kernel code handles mbufs, one might suppose that the packet data part of that structure, if it were (intentionally) malformed, might be used to overwrite that function pointer. There is the implication at least that that possibility was ruled out too hastily. I don't believe that happened. The OpenBSD team knows their stuff and their code, and probably had good reason to doubt that this was a remote execution exploit. But the advisory doesn't provide any information about why the OpenBSD team made that determination, so one naturally thinks the worst.

        2. By Anonymous Coward (122.49.157.192) on

          > And if you were not concerned about such a case (due to the fact that it would probably not happen to you, AKA a home network,) then you should likewise not be concerned about the code execution since you're not a juicy target.

          I'm not concerced with being dropped to DDB> on my home network. But just because I'm not a juicy target doesn't mean I'm not concerned with being hit by any potential worms using this as an attack vector. I ALWAYS assume there'll be a worm.

  10. By Anonymous Coward (62.75.220.75) on

    It`s again ICMP....
    Further Checking in the IPv6-Stack should be done....

    Comments
    1. By Anonymous Coward (143.127.131.4) on

      > It`s again ICMP....
      > Further Checking in the IPv6-Stack should be done....

      get started then.

  11. By Anonymous Coward (69.70.178.208) on

    Before any other rules in /etc/pf.conf:
      set block-policy drop
      block log
    
    Unless you explicitly permit inet6 thereafter by specifying your pass rules as follows, there should be no problem as it will not expand to permit inet6.
    pass in on fxp0 inet proto tcp to (fxp0:0) port 80 flags S/SA keep state
    
    Otherwise, block in inet6 may be ineffective depending on how you constructed your ruleset and the corresponding rule expansion. Perhaps
    block in quick inet6
    is a better recommendation if you do not utilize IPv6 services whatsoever.

  12. By blocker (86.91.41.86) on

    My first rule is (on most pf setup's) : block in all
    Does that not include ip6 traffic as well then ?

    Comments
    1. By Anonymous Coward (24.37.242.64) on

      > My first rule is (on most pf setup's) : block in all
      > Does that not include ip6 traffic as well then ?
      >

      Same with mine (redundant CARP'd firewalls, with dynamic IP) block in all, then what I allow in/out, I always make it a rule of thumb to specify 'inet' because I only use IPv4 myself.

      Personally, I would think that should block inet6 and everything else too, unless you have another rule that doesn't specifically specify inet, which may allow inet6 too?

      I'd like to hear feedback on this too.

    2. By Mike Erdely (71.241.230.202) mike@erdelynet.com on http://erdelynet.com/

      > My first rule is (on most pf setup's) : block in all
      > Does that not include ip6 traffic as well then ?

      As long as you don't have any "pass inet6" rules after that.

      Comments
      1. By Mike Erdely (65.222.245.131) mike@erdelynet.com on http://erdelynet.com/

        > As long as you don't have any "pass inet6" rules after that.

        I guess I should say: as long as all of your pass rules say "pass inet".

    3. By Anonymous Coward (143.127.131.4) on

      > My first rule is (on most pf setup's) : block in all
      > Does that not include ip6 traffic as well then ?
      >

      all means all.

  13. By Anonymous Coward (74.115.21.120) on

    Time to start working on a BSD licensed bitc compiler?

  14. By Jussi Heino (MunOBSD) on

    Was it just a month ago I read at news:comp.unix.bsd.openbsd.misc replies by old OpenBSD farts explaining that if the poor dude wants to disable the few IPv6 packets that are sent during boot then 1) the poor dude (=OP) is a wuss and 2) disable the IP-stack alltogether to be safe and 3) that there is no point to be able to disable all IPv6 and enable only IPv4, becouse it's a safe thing.

    Well, the poor dude had the point after all when it comes to disabling IPv6 as not needed service.

    Disabling SSH by default was the ultimate solution to remote bug #1.
    Disabling IPv6 by default is the same thing for #2?

    Enabling pf and then blocking IPv6 is not properly disabled IPv6.

    What else is there to disable or add before #3...

    Comments
    1. By Anonymous Coward (143.127.131.4) on

      > Was it just a month ago I read at news:comp.unix.bsd.openbsd.misc replies by old OpenBSD farts explaining that if the poor dude wants to disable the few IPv6 packets that are sent during boot then 1) the poor dude (=OP) is a wuss and 2) disable the IP-stack alltogether to be safe and 3) that there is no point to be able to disable all IPv6 and enable only IPv4, becouse it's a safe thing.
      >
      > Well, the poor dude had the point after all when it comes to disabling IPv6 as not needed service.
      >
      > Disabling SSH by default was the ultimate solution to remote bug #1.
      > Disabling IPv6 by default is the same thing for #2?
      >
      > Enabling pf and then blocking IPv6 is not properly disabled IPv6.
      >
      > What else is there to disable or add before #3...
      >

      So what's your point? Yes you could disable everything by default and have a more secure system but but also a useless system.

      Turning off sshd by default and thinking your safer is just an excuse to avoid fixing the problems that might exist. If more than 50% of openbsd users will turn on sshd after a default install then it should be on by default.

      OpenBSD is not about security through turning the OS into box with no software running. It's about fixing the problems the right way, in the code, not in turning things off.

      Comments
      1. By RC (71.105.36.236) on

        > If more than 50% of openbsd users will turn on sshd after a default install then it should be on by default.

        I agree about sshd, and would say that number should be far, far lower. However, I wouldn't agree with that sentiment about any other daemon... SSHD is what you need to be able to remotely access a freshly installed system, and enable/disable any other services. Even inetd should be disabled, IMHO.

        Comments
        1. By Denis (213.41.245.173) on

          > Even inetd should be disabled, IMHO.
          >
          I agree, inetd and sendmail are the first things I disable when installing my OpenBSD. And what the point of having udp:514 listening when you have to use -u command-line option to accept input ?



          Comments
          1. By Anonymous Coward (149.135.121.184) on

            > > Even inetd should be disabled, IMHO.
            > >
            > I agree, inetd and sendmail are the first things I disable when installing my OpenBSD. And what the point of having udp:514 listening when you have to use -u command-line option to accept input ?
            >
            >
            >
            >


            Yes! Close this off

  15. By Anonymous Coward (72.193.216.83) on

    Impressive, only two remote holes in more than 10 years.

    Does anyone know the total remote hole count for the
    entire OpenBSD history?

    Comments
    1. By Anonymous Coward (86.81.223.219) on

      > Impressive, only two remote holes in more than 10 years.
      >
      > Does anyone know the total remote hole count for the
      > entire OpenBSD history?
      >
      Since the initial release (OpenBSD 1.2) was in July 1996 (more then 10 years ago) I sounds highly acceptable to me that the count would be 2.

  16. By Anonymous Coward (216.68.198.57) on

    All serious servers tend to disable everything not needed, and use many layers of defence.
    Given this, OpenBSD fits very well, and OpenBSD and CORE provide a great FREE service.
    Any reader of man ip6 and 2000 Freenix article, would be act accordingly, IPv6 code is not as perfected as IPv4, sort of.

    Its easy to get lulled into a false "secure product" mindset, with all the changes today, it is a process.

    Keep up the good work all, and thanks for a good product and free support.

    Comments
    1. By Anonymous Coward (143.127.131.4) on

      > All serious servers tend to disable everything not needed, and use many layers of defence.
      > Given this, OpenBSD fits very well, and OpenBSD and CORE provide a great FREE service.
      > Any reader of man ip6 and 2000 Freenix article, would be act accordingly, IPv6 code is not as perfected as IPv4, sort of.
      >
      > Its easy to get lulled into a false "secure product" mindset, with all the changes today, it is a process.
      >
      > Keep up the good work all, and thanks for a good product and free support.

      You should search the misc@ archives for "security is a process".

      Theo HATES that.

      Comments
      1. By Anonymous Coward (216.68.198.57) on

        > You should search the misc@ archives for "security is a process".
        > Theo HATES that.

        I posted the ~ "security is a process" reply. re:above > Theo HATES that.

        Thanks for the cultural speak and where to look to "fit in," persona is important.
        Haven't looked at really any of the misc@ or ~marc@aims group mailings.
        I'll search misc@ soon, and note it to myself. I don't want to rub IT developers the wrong way, especially over words.
        However, :), security is a word, and my post aims to keep non-IT people/managers here awake, not to just say, "Its OpenBSD, no need to learn security or get deep into it. It is a major endeavor using OpenBSD "perfectly," so to speak.

        Proper classification of security, I'll leave to linguists, and others for the "words wars."

        Personally I feel it really is a "black art" and just a belief, reasoned hopefully.
        I do "trot" out the old mantra, "security is a process." However, perhaps I should change it to something else.

        A good article to read and figure out a mantra is found at: www.schneier.com/essay-155.html.
        Or another mantra from the article, "Security is both a feeling and a reality. And they're not the same."

        An appeal to an authority, hopefully which is accepted here. Guess I'll have to do my misc reading.

        Peace all, and thanks for you hard work and great product.

    2. By Dj SyNko (80.104.72.198) on

      .o/

  17. By Renaud Allard (renaud) renaud@llorien.org on

    Why not put a sysctl net.inet6.allow=0 by default? It is easier to enable than to compile a new kernel and would prevent ipv6 from being enabled by default.

    Comments
    1. By Anonymous Coward (149.135.121.184) on

      > Why not put a sysctl net.inet6.allow=0 by default? It is easier to enable than to compile a new kernel and would prevent ipv6 from being enabled by default.

      I suggested this years ago

    2. By Bob Bostwick (64.140.63.110) on

      > Why not put a sysctl net.inet6.allow=0 by default? It is easier to enable than to compile a new kernel and would prevent ipv6 from being enabled by default.

      I really wish this would happen, and would be the most logical approach. Most people, IMHO do not use inet6 anyway. By contrast many people use net.inet.ip.forwarding=1, thank God that's not a kernel rebuild. I don't believe in security by obscurity, but I don't think it's wise to run things just because it's there. If you don't need it turn it off.

  18. By Anonymous Coward (208.53.138.41) on

    Oh how embarrassing for the OpenBSD project.

    Maybe we can stop saying OpenBSD is
    the most secure OS in the world. For
    an OS that has little if anything running
    on the default install this remote
    hole should show the world that
    OpenBSD should not be trusted when
    it comes to security.

    I also like how the time line clearly
    shows Theo trying to hide this remote
    hole from the public.

    Sad.

    Comments
    1. By Renaud Allard (renaud) on

      > Oh how embarrassing for the OpenBSD project.
      >
      > Maybe we can stop saying OpenBSD is
      > the most secure OS in the world. For
      > an OS that has little if anything running
      > on the default install this remote
      > hole should show the world that
      > OpenBSD should not be trusted when
      > it comes to security.
      >
      > I also like how the time line clearly
      > shows Theo trying to hide this remote
      > hole from the public.
      >
      > Sad.

      Should we mod you +1 funny like in slashdot?

    2. By Matthias Kilian (91.3.56.222) on

      > Maybe we can stop saying OpenBSD is
      > the most secure OS in the world.

      OpenBSD was never the most secure OS in the world, it was always the second most secure OS in the world, because the most secure OS will be the next release of OpenBSD, and so on. (Just interpolating D. Adams, with the exception that OpenBSD isn't controlled by mice and won't be demolished by the vogons).

      > I also like how the time line clearly
      > shows Theo trying to hide this remote
      > hole from the public.

      Read misc@, be happy.

      http://marc.theaimsgroup.com/?l=openbsd-misc&m=117404837006368&w=2

      No conspiracy, just some very very vague report from Core Security and some IT journalists that like to bitch on OpenBSD after they proved themselves to be complete BSD resistant. Are you disappointed now?

      For the latter, just search the recent misc@ postings and *especially* search heise.de for "Berkeleys Erben" (german only). Perfectly normal uninformed beasts.

      Comments
      1. By Anonymous Coward (122.49.157.192) on

        > For the latter, just search the recent misc@ postings and *especially* search heise.de for "Berkeleys Erben" (german only). Perfectly normal uninformed beasts.

        I'd prefer ham sandwiches myself.

    3. By Anonymous Coward (124.106.218.42) on

      > Oh how embarrassing for the OpenBSD project.
      >
      > Maybe we can stop saying OpenBSD is
      > the most secure OS in the world.

      Seriously, do you morons just watch sites for stuff you dont like for opportunities to whine about stuff you dont even use?
      Get a life.

    4. By Anonymous Coward (216.93.163.234) on

      > Oh how embarrassing for the OpenBSD project.
      >
      > Maybe we can stop saying OpenBSD is
      > the most secure OS in the world. For
      > an OS that has little if anything running
      > on the default install this remote
      > hole should show the world that
      > OpenBSD should not be trusted when
      > it comes to security.
      >
      > I also like how the time line clearly
      > shows Theo trying to hide this remote
      > hole from the public.
      >
      > Sad.

      Look. A Gobbles.

    5. By Anonymous Coward (151.188.247.104) on

      Ah, a MCSE troll. Here, I'll correct your post for you.


      Oh how embarrassing for Microsoft Corporation.

      Maybe we can stop saying Windows Vista is
      the most secure OS in the world. For
      an OS that gets hyped so much about how secure
      it's supposed to be, the fact that it's already
      been cracked should show the world that
      anything from Microsoft should not be trusted when
      it comes to security.

      I also like how the time line clearly shows
      Steve Ballmer trying to dance his way out
      of his company doing actual, good software
      development with more FUD attempts. Maybe
      next time, he'll actually wear a monkey suit.

      Sad.


      spitz@cmosnetworks.com

  19. By Anonymous Coward (149.135.121.184) on

    harharr guys! For years I've been blocking all inet6 traffic since I don't use IPv6 at all.

    With the exact thoughts (and even explained to a client of mine), IPv6 is not being used at all, so we should switch it off. Their might be a bug in it.

  20. By Anonymous Coward (216.68.198.57) on

    Endless chatter, yak, yak, yak, ok, ok, What is this, a Lethel Weapon movie?
    Jeez....
    Seriously folks, here is PART of the scoop.
    Any moderate config and compile of kernel and even pf config, for most people interested in security and somewhat competent, even while drunk, mind you.
    Would have been ok and or reasonable here. Pay a bit for computing, get a lot of returns.
    But anyway, what other CIVILIAN OS are you going to run?
    XP, Vista, Laugh, Linux, well if you are a serious coder, well you'd be somewhat ok, but still, for "monkeys" no other OS even comes close.
    FreeBSD will get you there, it more of a rough ride.
    Irix B? Come on.
    So what else, DOS? shit.....
    Thank God for OpenBSD and Team for bringing SANITY in this world to computing.
    Many lives have been saved with this OS. Don't ask.
    Peace all, and let bygones be bygones....

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