OpenBSD Journal

TCP retransmit timeout reliability patch available

Contributed by jcs on from the get-your-patches dept.

Quoting errata.html:

010: RELIABILITY FIX: January 10, 2005
A bug in the tcp(4) stack allows an invalid argument to be used in in calculating the TCP retransmit timeout. By sending packets with specific values in the TCP timestamp option, an attacker can cause a system panic.

The patches for 3.5 and 3.6 are available (or will be shortly) from your local FTP mirror. Ryan McBride notes:

"On OpenBSD 3.6 and newer, pf's 'scrub reassemble tcp' TCP timestamp sanity checks provide some (but not complete) protection against this problem."

Although your best bet is to just apply the patch and recompile your kernel.

(Comments are closed)

Comments

  1. By Anonymous Coward (131.130.1.143) on

    Sorry, I don't understand why a bug, which can cause a system panic, is a reliability fix. Wouldn't that be a security issue? I'd be glad if someone you explain this to me or provide a link. Thanks!

    Comments

    1. By Anonymous Coward (193.62.218.79) on

      Causing a panic is a DoS problem not security. Can't hack into a panicked system....

    2. By Anonymous Coward (193.167.7.18) on

      It depends on how you understand security. I think security is everything that protects against any disruption. Therefore, a reliability fix is also a security fix.

      Comments

      1. By Sean Brown (204.209.209.129) on

        To me a security issue is one that allows an attacker to comprimise the system and/or applications running on it, whereas a reliability issue is one of providing reliable services. This does not allow an attacker, or a mistake I suppose, to gain control of the system just interupt it, so its a reliability issue.

        Comments

        1. By Anonymous Coward (131.130.1.143) on

          That sounds like a sensible explanation to me. Thank you!
          Regards,
          j.

      2. By Anonymous Coward (62.65.145.30) on

        What's the difference between a reliability fix and a security fix, then, by your definition? If it's the very same thing, why do all those people act as if it wasn't?

        Comments

        1. By tedu (64.173.147.27) on

          option 1: i can run my code on your computer.
          option 2: i can prevent you from running your code on your computer.

        2. By Rob Sessink (24.132.54.18) rob@animoid-row.org on

          I think the point in all this lies not in the case that a fix is labelled as a reliability fix or a security fix, in my opinion it is not that clear. I think it depends on the use/deployment of the system in your environment. If you use the system as key component in your network on which various systems or infrastructure depend, this bug can be or become an security issue. If the system acting as firewall or VPN gateway goes down and people use other (less secure) ways to make use of your infrastructure it becomes a security issue. Don't look for a specific label to take action on, think for yourself and how it reflects to your own environment, wage and take the appropriate actions.

          Comments

          1. By djm (218.214.226.34) on

            Who cares? If you read pass "reliability fix" to the very next sentence on errata.html, then you get a complete description of the impact of the bug.

        3. By Anonymous Coward (216.238.113.174) on

          I appreciate that others can understand and convey the difference between a reliabilty fix and a security fix, even if you cannot or would not.

  2. By Anonymous Coward (80.90.29.23) on

    holy crap. we are fcked.
    supasecure openbsd tcp stack is vuln, what about nbsd/fbsd?

    Comments

    1. By Valery (195.98.50.58) on

      OpenBSD never claimed to be totally, 100% secure. No system is. The fact is that the development team reacts very quickly to the issues and this helps to avoid lots of security and other kinds of problems. Of course the bug in the TCP stack is a serious thing. Let's be happy that the problem was identified in time and fixed already, this making OpenBSD one more step closer to perfection.

    2. By Frank Denis (213.41.131.17) j@pureftpd.org on http://www.00f.net

      You forgot DragonFlyBSD.

  3. By Nicram (62.87.244.34) nicram@bsdzine.org on http://nicram.sytes.net/

    010: RELIABILITY FIX: January 10, 2005..... Ok it's number 10, where is 9?!?

    Comments

    1. By Eduardo Alvarenga (66.110.114.5) eduardo.alvarenga()gmail.com on

      ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.6/common/009_httpd.patch

      People forgot to list it on errata.html.

      Comments

      1. By x (81.56.211.110) on

        what the problem with httpd ?

        Comments

        1. By Hunger (213.163.11.138) www-undeadly-org@hunger.hu on http://hunger.hu./

          Buffer overflow in the get_tag function in mod_include for Apache 1.3.x to 1.3.32 allows local users who can create SSI documents to execute arbitrary code as the apache user via SSI (XSSI) documents that trigger a length calculation error.

          http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0940

      2. By Brad (65.110.162.62) brad at comstyle dot com on

        You ASSUME that someone forgot.

        Comments

        1. By Anonymous Coward (67.34.129.203) on

          FYI, the apache user has less privs than the local account needed to exploit this bug.
          If you want to have something to be paranoid about, go look at Linux kernel....

        2. By Anonymous Coward (195.217.242.33) on

          Looks that way to me .....

          <http://www.openbsd.org/cgi-bin/cvsweb/www/errata.html>

          Comments

          1. By Brad (204.101.180.70) brad at comstyle dot com on

            Well I can't help it that you're an idiot.

  4. By OpenBSDFan (207.171.180.101) on

    Hmmm, this is a remotely exploitable kernel memory screw. Does this count as a remote-root-exploit? Has it been shown that it can't be, or does someone have to write a proof-of-concept exploit to qualify?

    Comments

    1. By Jim (68.250.26.213) on

      Where is your exploit code proving it?

    2. By mcbride (216.187.75.132) on

      Hmmm, this is a remotely exploitable kernel memory screw.

      No. Why are you making statements like this when you clearly don't understand what's going on?

      It's just a bit of bad math that results in the TCP stack attempting to schedule a packet retransmit in the past. A sanity check in timeout(9) notices this, and panic()'s the system rather than continue in a state which doesn't make sense.

      Does this count as a remote-root-exploit?

      No.

      Has it been shown that it can't be, or does someone have to write a proof-of-concept exploit to qualify?

      The fact that you're even asking these questions about this particular bug makes it clear to me that you're neither qualified to write such an exploit if it actually was exploitable, nor qualified to understand a proof of non-exploitability if one were presented to you.

      In a more general sense, yes. If there is a bug which is obviously not exploitable, I will demand to see a working exploit before I change my mind.

      Comments

      1. By Anonymous Coward (207.171.180.101) on

        Ouch, man. Yes. I missed the fact that it was an explicit call to panic(), but damn! I assure you that with 20 years of C and UNIX and some small amount of that in the kernel, and having written kernel code as far back as AT&T System III and MINIX, I am in fact qualified to read and write proof-of-concepts.

        The fact that I asked a question before understanding the problem fully does NOT entitle you to step up to the dealer-of-bitch-slaps plate.

        Further, I'm a huge fan of OpenBSD, having contributed a fair amount of money (if not much code) to it over the years.

        Back down off your soapbox, doofus. We're all on the same team here.

  5. By Anonymous Coward (195.217.242.33) on

    Some fella called Linus Tor.. something-or-other talks security

    <http://www.internetnews.com/dev-news/article.php/3458961>

  6. By Anonymous Coward (64.62.253.241) on

    Is OpenBSD going to do the ethical thing and update that slogan from "one" to "two"? Or are we just going to bullshit together some excuses about how this isn't _technically_ a hole (a la Linus?)

    pf is not on by default so a 3.6 machine is remotely DoS'able. Cheers!

    Comments

    1. By Brad (216.220.57.68) brad at comstyle dot com on

      What the hell are you talking about crackpot? This does not allow remote privilege escalation.

  7. By Anonymous Coward (81.165.99.242) on

    Just be glad things get fixed when there are found. To bad i takes ages to recompile the kernel on this old sparkie :-)

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