[Patch 013] OpenBSD fixes CAN-2004-0171?

Contributed by jose on 2004-03-08 from the stack-bugs dept.

Anonymous writes: "Does this commit fix this vulnerability ? Thanks!"

It appears to fix it, but there is no official announcement yet saying if this really is the fix. However, a few bugs are fixed in the -stable trees, you may want to make sure you're up to date on them.

UPDATE: An official patch has been released:
Patch 013 for 3.4 and Patch 018 for 3.3. This is fixed in current, of course. From the errata , "OpenBSD's TCP/IP stack did not impose limits on how many out-of-order TCP segments are queued in the system. An attacker could send out-of-order TCP segments and trick the system into using all available memory buffers."

The security-announce mail that came out this morning about this.


Date: Tue, 9 Mar 2004 13:50:49 +0100                                           
From: Markus Friedl

To: security-announce@openbsd.org                                              
Subject: TCP reassembly DoS

OpenBSD's TCP/IP stack did not impose limits on how many out-of-order TCP segments are queued in the system.

If an attacker was allowed to connect to an open TCP port, he could send out-of-order TCP segments and trick the system into using all available memory buffers. Packet handling would be impaired, and new connections would fail until the the attacking TCP connection is closed.

The problem is fixed in -current, 3.4-stable and 3.3-stable.

Patches are available at:

ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.4/common/013_tcp.patch
ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.3/common/018_tcp.patch

(Comments are closed)

Comments

By Brad () brad at comstyle dot com on 2004-03-09 04:50 mailto:brad at comstyle dot com

The above mentioned commit and this one are part of the fix...

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

Errata is up now.
By gwyllion () on 2004-03-09 05:57

ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.3/common/018_tcp.patch
ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.4/common/013_tcp.patch
By Noryungi () on 2004-03-09 08:40
Comments
1. By Noryungi () on 2004-03-09 08:41
  
  Sorry, here is what I meant to say:
  
  http://www.openbsd.org/errata.html
  
  013: RELIABILITY FIX: March 8, 2004
  OpenBSD's TCP/IP stack did not impose limits on how many out-of-order TCP segments are queued in the system. An attacker could send out-of-order TCP segments and trick the system into using all available memory buffers.
By Chris Humphries () chris@unixfu.net on 2004-03-09 09:14 http://unixfu.net

Took almost a week since the changes were committed to the src trees, and only now did openbsd camp actually release something.

theo a slacker?

How about letting everyone know about it when the patches and commits go in? I just wonder how long it would have taken if jose had not had posted to here.
Comments
1. By Chris Humphries () chris@unixfu.net on 2004-03-09 09:16 http://unixfu.net
  
  sure openbsd camp will disagree that this is a "hole", yet you would be able to dos an openbsd box off the network.
  
  sounds like a hole to me :)
  Comments
  1. By Anonymous Coward () on 2004-03-09 09:44
    
    once again:
    
    denial of service != remote hole
    
    theo != openbsd
    
    cvs commit != patch
    
    Comments
    
    By Anonymous Coward () on 2004-03-09 10:35
    
    dos sounds like a remote hole to me. bringing servers and firewalls down due to a hole in the kernel networking code is good enough to be a remote hole to me as one could bring down important boxes on your network (vpn endpoint, firewall, http/mail servers). good as being owned in my opinion. the box isnt operational due to a bug/bad auditing in the kernel network code... openbsd can label what they want, but this is a remote hole that effects service.
    
    theo is openbsd, are you nuts?
    
    patches have existed before the cvs commit, but you didnt know that i guess.
    
    nice to see you couldnt put your name on your words... anonymous coward.
    
    Comments
    
    By krh () on 2004-03-09 10:44
    
    > nice to see you couldnt put your name on your words... anonymous coward.
    
    I'm glad to see that you're just as bold and courageous as the first poster.
    
    Comments
    
    By Chris Humphries () chris@unixfu.net on 2004-03-09 10:52 mailto:chris@unixfu.net
    
    i am the first poster :)
    i posted the previous post. forgot to put my name in, but it was me, thought was obvious :)
    
    By JM () on 2004-03-10 00:36
    
    Ok, I'll bite on this troll...
    
    Chris give your head a shake man.
    
    A remote hole implies that the attack gains _access_ to the system in some manner.ie. the attack results in an integrity compromise.
    
    Now a dos on the other hand, is just that denial of service.
    
    They are NOT equivalent.
    
    Given the choice I rather be dos'd than 0wned any day of the week ;-) What if you have confidential data on the target? The difference in the consequences is enormous. Rather than your box just going down would you rather it now be a potential platform for attacks against other systems?
    
    And before you start accusations of bad auditing, have you ever written a flawless TCP/IP stack? I'm sure you might have some valuable criticisms and insight (or even help) to render if you did. Rather than arrogant flippant remarks...
    
    Comments
    
    By Chris Humphries () chris@unixfu.net on 2004-03-09 15:15 mailto:chris@unixfu.net
    
    a dos certianly effects integrity. imagine your vpn or firewall endpoint going down over and over again and you cant figure out why and you cant stop it, all while your customers are complaining and losing trust in your company. a reinstall of a server is easy if comprimised. a fix for a kernel level network issue with no fix is not.
    
    the reality is that openbsd pretty much sucks for anything that isnt network [endpoint] boxes, though i am sure there are those that can argue that to no end with their sparc64 and higher end boxes used as firewalls.
    
    machines with valuable data shouldnt even be routable and should be in a dmz, where the os of the machine a minute issue. so that point of kinda mute if you design your network infostructure correctly. which sounds like you do not have experience doing.
    
    putting trust into an os is something that we all have to do when we choose which to use for our infostructure. now the key word is trust here, and this is the real issue. this hole (or not hole whatever) was fixed and known about for about a week before this deadly post (even before the commits) and not a word was told about it to the public. this seeds distrust in the people that write the os, which i think is very valid.
    
    when it comes to security, trust is a big thing when implementing a technology. this seems to not be a topic people talk about when they blindly follow openbsd like a sheep.
    
    i am not a troll, but i am not one to blindly follow openbsd with my eyes closed and forget about trust.
    
    this issue makes me question the ethics of the people writing the code and theo, which is the big cheese of openbsd. he know about this, yet didnt tell the public, as soon as the patches were tested and the commits made. why?
    
    it wasnt like it was just a day late, it was over 5 days post commit of the issue.
    
    am i the only one that cares about trust? is everyone sheep with no brains themselves? openbsd is more than just a nice little club that you like belonging to with all you have to do is run the os and back it even if you have no idea what you are talking about.
    
    it is just another os like any other one, and it still should demand fast security notifications once it is known and fixes exist. you should still value trust and ethics of the developers that write it.
    
    dont go into it blindly.
    
    Comments
    
    By Bruce () on 2004-03-09 16:22
    
    If you are unsatisfied by the response time from the OpenBSD developers to an issue like this, you are full welcome to either improve on it by helping out or avoid the problem entirely by choosing another OS. Nobody is stopping you.
    
    As for your repeated claim that a DoS is a hole, you are either trolling or ignorant of accepted computer security terms.
    
    Giving you the benefit of the doubt, here are a couple of links you may find useful:
    
    What is a DoS?
    
    http://en.wikipedia.org/wiki/Denial_of_service
    
    What is an exploit?
    
    http://en.wikipedia.org/wiki/Exploit_(computer_science)
    
    You can accept my assertion that a hole is the same as an exploit or you can look for supporting information on the net (e.g. search for "remote hole" including quotes on Google and have a look at the type of security issues that come up). Or you may continue to insist that a hole is equivalent to a DoS, but then you would clearly be a troll.
    
    Comments
    
    By Chris Humphries () chris@unixfu.net on 2004-03-09 17:27 mailto:chris@unixfu.net
    
    thanks for the laughs, i appreciate it. :)
    
    the issue is that they knew about it and didn't tell anyone till this deadly post came out.
    
    i am not the only one that disagrees with openbsd's definition of what a hole is. yet i will take all your replies :)
    
    yours is entertaining :)
    
    a hole and exploit are not the same thing, and your ignorance of that makes your whole post very funny to me :) thanks for the laughs :)
    
    By Bruce () on 2004-03-09 17:56
    
    Ok, typing slightly faster than thinking. A hole is the same thing as a vulnerability, whereas an exploit is a tool for taking advantage of the given vulnerability. I'm sure most readers here know that already, but the clarification might help someone. Not Chris, apparently.
    
    I would agree that a remote DoS can be a significant security problem, but as it doesn't lead to privilege escalation it isn't the same thing as a hole.
    
    Comments
    
    By Chris Humphries () chris@unixfu.net on 2004-03-09 18:59 mailto:chris@unixfu.net
    
    you still seem confused. try again.
    
    Comments
    
    By Anonymous Coward () on 2004-03-10 09:32
    
    Please explain to me how anyone, anywhere, can prevent a Denial of Service for any system.
    
    Since bandwidth is what it is, if too many requests are made to ANY system, you will have a DoS. Granted, there are flaws that can make this much _easier_ to produce on a system (for argument's sake, a broken box that ties up 100% CPU anytime it is sent the string "dos" on port 80). In such a case, the vulnerability allows for an attacker with very slight resources to generate a headache for those on the receiving end.
    
    However, no one, anywhere, ever, can guarantee that a system is not DoS-able. If OpenBSD were to say this, it would be more laughable than any naysayers seem to find the 1 remote hole slogan. If you are convinced that your systems ARE DoS proof, you are either sorely mistaken or about to be very rich--you should sell hosting to everyone, everywhere. Your servers can obviously handle the load for the entire Earth and everyone on it.
    
    Now, if we transition away from fantasy land, we'll see that there are other issues--vulnerabilities with greater severity than a DoS. These are the kind referred to as holes, which allow unauthenticated users to be authenticated to a system, or allow authenticated users to escalate privileges, or allow the unauthorized viewing of files on a remote system (which can lead to the disclosure of sensitive info, which in turn leads to further exploitation). These holes, against which OpenBSD remains vigilant, are the real threat.
    
    Remember: Anyone can DoS you. It should never be easy for you to be DoSed, but it cannot be prevented. However, it should _never_ be possible for someone to have a hole into your system. That CAN be prevented. For my money, OpenBSD does the best job of it!
    
    Comments
    
    By Anonymous Coward () on 2004-03-11 09:11
    
    Please explain to me how anyone, anywhere, can prevent a Denial of Service for any system.
    
    Since bandwidth is what it is, if too many requests are made to ANY system, you will have a DoS. Granted, there are flaws that can make this much _easier_ to produce on a system (for argument's sake, a broken box that ties up 100% CPU anytime it is sent the string "dos" on port 80). In such a case, the vulnerability allows for an attacker with very slight resources to generate a headache for those on the receiving end.
    
    You kind of answered your own question in one paragraph.
    
    It is not *always* bandwidth related! Sometimes it is malformed packet related or some such. Those types of DoS are avoidable.
    
    Can't gaurantee that is system is not DoS'able? I agree. ; )
    
    By Bruce () on 2004-03-10 14:40
    
    No, actually, I don't think I am confused.
    
    Let me try a couple of functionally equivalent versions of what I consider to be the meaning of 'hole'. Perhaps I can tighten the concept up a bit.
    
    A hole is a computer flaw which allows privilege escalation. (Just trying for a dictionary style definition here.)
    
    Metaphorically, a hole allows you to get from where you are to where you aren't supposed to be. Again, this is compatible with privilege escalation, but not with a denial of service.
    
    I still stand by my corrected definition of what a hole is, and that a DoS is not a hole. If you have a clear, supportable definition of 'hole' that would encompass a DoS, would you please share it with the group?
    
    By marklar () marklar_@hotmail.com on 2004-03-09 16:29 mailto:marklar_@hotmail.com
    
    >i am not a troll
    Yeah, good one.
    
    >the reality is that openbsd pretty much sucks for
    >anything that isnt network [endpoint] boxes
    Care to back this up with any substantive evidence?
    
    >machines with valuable data shouldnt even be
    >routable and should be in a dmz, where the os of
    >the machine a minute issue. so that point of
    >kinda mute if you design your network
    >infostructure correctly.
    Rubbish, plain and simple. Ever worked in an eCommerce gateway environment? This arguement doesn't hold any weight at all, 'cos the machines with valuable data NEED to be accessable from the Internet.
    
    >it is just another os like any other one, and it
    >still should demand fast security notifications
    You can demand all you like, how about fronting up some money to make it happen? OpenBSD is a volunteer effort, if people like you start demanding things without contributing in any way to the project, you might just piss off some of the volunteers enough to make them question why they should even bother volunteering at all.
    
    >when it comes to security, trust is a big thing
    >when implementing a technology. this seems to not
    >be a topic people talk about when they blindly
    >follow openbsd like a sheep.
    Dude, I'm no sheep. Security is my day job, I know a good thing when I see it and OpenBSD is it. I've put more trust in OpenBSD than any other OS and it's paid off big time, for which I am eternally grateful to the OpenBSD developers.
    
    >dont go into it blindly.
    I haven't and neither have many others.
    
    Comments
    
    By Chris Humphries () chris@unixfu.net on 2004-03-09 17:22 mailto:chris@unixfu.net
    
    > Rubbish, plain and simple. Ever worked in an
    > eCommerce gateway environment? This arguement
    > doesn't hold any weight at all, 'cos the
    > machines with valuable data NEED to be
    > accessable from the Internet.
    
    i have worked for devis consulting (devis.com) where we did government wide e-gov stuff that was very database intensive, and it was not possible to get to the database the way we had things setup, even if you comprimised one of the front end web servers, which were your only way of getting anywhere. had a pretty cool zope with zeo servers setup there too, but that isnt related to anything really, heh.
    
    now working at BurstNet (burst.net) as their senior developer and writing huge database applications that need to server up data to employees and customers and the database is not reachable. have a database that holds network and snmp data for 2 /17 and 1 /18 every minute, and it is not reachable/routable.
    
    working with database driven stuff is a big part of what i do and have experience in, as well as setting up the infostructure for it all. the database machine does not need to be reachable via the internet.
    
    i dont care if they don't decide to continue development, they have said they make openbsd for themselves and that is how they will continue to go. i do not think anyone's words will alter that.
    
    openbsd as a high performance database machine does not cut it relative to freebsd or linux in my experience. it rocks for packet filtering/routing/shuffling and snmp server though.
    
    Comments
    
    By Anonymous Coward () on 2004-03-10 12:55
    
    i have worked for devis consulting (devis.com) where we did government wide e-gov stuff that was very database intensive, and it was not possible to get to the database the way we had things setup, even if you comprimised one of the front end web servers, which were your only way of getting anywhere.
    
    What, the web servers had a route to the internet (possibly with maybe even a proxy and bridging firewall/load balancing in between), on the back side of the web servers you had only private IP's with static routes to the database servers (which possibly also had proxies and firewalls in-between)?
    
    So, you have internet exposed web servers, with private routes to back end databases which have no route to the net and you think this is unbreakable? Perhaps all you web servers use private IP's with a firewall doing redirection to them? Do you think that is unbreakable?
    
    Laughable.
    
    Comments
    
    By Chris Humphries () chris@unixfu.net on 2004-03-10 09:10 mailto:chris@unixfu.net
    
    hrm, i didnt say unbreakable. where did you read that i said that?
    
    By djm () on 2004-03-10 06:05
    
    The commits are made publically. Anyone can subscribe to source-changes@ and *see* the fixes as they are committed to the STABLE branch. E.g. http://archives.neohapsis.com/archives/openbsd/cvs/2004-03/0133.html
    
    I'm not sure whether you are trolling, or just very ignorant.
    
    By Anonymous Coward () on 2004-03-10 01:07
    
    DoS means someone can stop your machine from doing what you want it to do. eg, you can't serve web pages any more.
    
    A hole means someone can make your machine do anything they want it to do. eg, your machine is now serving child pornography and the attacker now has all your clients' cc numbers.
    
    You get hit by a DoS, you block the attacker and patch your machine.
    
    You get hit by a successful exploit, you have to take the machine down, examine the logs, verify file integrity, notify your customers about potentially leaked private information, and reinstall everything.
    
    Both are serious concerns, but hopefully it's obvious that a remote hole is FAR worse than DoS. Reliability issues still get fixed the same as security issues, but security is more critical.
    
    By TNT () on 2004-03-10 07:24
    
    "dos sounds like a remote hole to me."
    
    This sentence alone screams "I don't know what I'm talking about". Sorry.
  2. By djm () on 2004-03-10 05:52
    
    The term "hole" is generally reserved for bugs that can result in increased access to an attacker, not DoS attacks. That isn't an OpenBSDism, that is standard terminology.
2. By emcis () on 2004-03-09 23:37
  
  Oh my! Five whole days for a patch! If memory serves (someone will probably correct me if I'm wrong), I think Microsoft switched to a thirty (count 'em, 30) day cycle for the release of patches. Let's see, five days for patches vs thirty. I think I'll stick to OpenBSD for my front end systems.
  Comments
  1. By gwyllion () on 2004-03-10 02:08
    
    markus@ fixed the bug in -current on the same day it was released:
    http://marc.theaimsgroup.com/?l=openbsd-cvs&m=107823195516648&w=2
    
    This patch was immediately (the next day) added to 3.4-stable and 3.3-stable by brad@:
    http://marc.theaimsgroup.com/?l=openbsd-cvs&m=107830309718091&w=2
    http://marc.theaimsgroup.com/?l=openbsd-cvs&m=107830328824310&w=2
    
    So it only toke 1 day to patch 3.4 and 3.3. Yes it toke longer to release a security announcement.
3. By djm () on 2004-03-10 05:50
  
  Patches are supposed to be very stable, so significant changes to the TCP stack require good testing. Testing doesn't just magically happen instantly.
  
  In that time you had -STABLE. If you choose to run patches only, then some delay is the price you pay for a very stable tree.
  Comments
  1. By Chris Humphries () chris@unixfu.net on 2004-03-10 09:14 mailto:chris@unixfu.net
    
    dude, the patches were committed 6 days before the deadly post and openbsd security advisory was made.
    
    you are missing the point here.
    
    Comments
    
    By tedu () on 2004-03-10 14:17
    
    it's a major pita to change patches after release. it's quite a bit easier to tweak things in cvs. so the point is that the initial fix was committed to stable cvs, tested out, and then a patch was released.
    
    By djm () on 2004-03-10 16:16
    
    So? Why not wait until the fix is ready for everyone?
    
    Perhaps we should issue one advisory when things get fixed in -current, saying "this is fixed in CVS, but the rest of you are fucked until it is fully tested". That would help, I'm sure.
By habys () discoluke@hotmail.com on 2004-03-09 11:44 sonzofacworth.net

building the kernel is simple enough, but what do these two lines mean?

>Update headers.
> make includes

thanks
Comments
1. By MK () on 2004-03-09 13:35
  
  Yes I would like to know this too. :)
2. By Ian McWiliam () ian at dodo dot com do au on 2004-03-09 15:51 mailto:ian at dodo dot com do au
  
  sys/netinet/tcp_var.h
  
  needs to be installed as it is patched.
  Running "make includes" from the top level source tree will install all the ".h" header files.
  Comments
  1. By asdfg () on 2004-03-10 05:35
    
    Why spend so much time with "make includes" when the following one-liner would do the job quickly?
    
    cp /usr/src/sys/netinet/tcp_var.h /usr/include/netinet/tcp_var.h
By Mike () on 2004-03-09 17:35

Could somebody exactly explain me how to patch a box? I really don't understant what does the "Make Includes" mean. I've juat rebuild my kernel and that's all.
Comments
1. By Ian McWilliam () ian at dodo dot com dot au on 2004-03-09 17:49 mailto:ian at dodo dot com dot au
  
  From the Patch itself.
  
  Apply by doing:
  cd /usr/src
  patch -p0 <013_tcp.patch
  
  Rebuild your kernel.
  
  Update headers.
  make includes
  
  Then rebuild and install sysctl:
  cd sbin/sysctl
  make depend
  make
  make install
  
  Analysis follows :-
  
  first we change our working directory to /usr/src.
  next we ally the patch using the patch program and redirect a patch file to it.
  Assuming that succeeded, rebuild and install your kernel.
  
  Now the next line is implied not given.
  
  cd /usr/src; make inludes
  
  "includes" is a target in the /usr/src/Makefile. It will install those lovely ".h" files that are needed, just as "install" is a target. Remember doing things like "make install"?
  
  Next rebuild and install sysctl.
  
  Oh don't forget to reboot at some point to have the new kernel load too.
  Comments
  1. By Mike () on 2004-03-10 06:46
    
    Tnaks a lot but I have still have some troubles.
    I can't use Mace Includes, I only get this error message:
    # mv /bsd /bsd.old
    # cp bsd /
    ------------------------------
    # cd /usr/src; make inludes
    make: don't know how to make inludes. Stop in /usr/src.
    
    Comments
    
    By Anonymous Coward () on 2004-03-10 07:41
    
    Are you sure you typed it correctly?
    
    By Anonymous Coward () on 2004-03-10 07:42
    
    Careful how you type.
    
    make inludes != make includes
    
    Read what you have posted carefully.
    
    Comments
    
    By Mike () on 2004-03-10 08:00
    
    I'm sorry about this. But I tryed "make includes" with the same result. ( OpenBSD 3.3 )
    
    Comments
    
    By Ian McWilliam () ian at dodo dot com dot au on 2004-03-10 17:59 mailto:ian at dodo dot com dot au
    
    You need to have the entire source tree installed under /usr/src not just the kernel source. You need more than /usr/src/sys/. Did the patch apply cleanly or did you get rej messages?
    
    Sounds like your source tree has problems.
    
    Comments
    
    By Mike () on 2004-03-11 06:29
    
    Yes the problem was in my source tree. Now it's OK. Thanks a lot.
By old3n () on 2004-03-10 03:06

One tro^H^H^H person was mentioning stuff like "imagine your firewall going down" blahblahblah...
Yeah, right.
Sorry, although I cannot deny the relative importance of the problem, it's not likely to affect any security-conscious admin:
1) First and foremost, correct me if I'm wrong, the effect of the DoS only lasts as long as the attack != crashing a service or the machine.
2) A dedicated firewall box should IMHO not allow direct connections from the outside; it could as well be without IP address...
3) As far as I can tell, pf's scrub would stop this attack cold. Any sane admin not using it, at least on the outside-facing interface(s), seriously?
Comments
1. By djm () on 2004-03-10 06:11
  
  No, scrub won't fix this. It doesn't (yet) do much TCP stream normalisation.
  Comments
  1. By old3n () on 2004-03-10 14:31
    
    Huh?! I thought that's what the 'fragment reassemble' and 'reassemble tcp' options were for...
    I guess I'll need to check what actually is implemented then.
    
    Comments
    
    By tedu () on 2004-03-10 16:17
    
    the attack isn't too many fragments. it's whole packets that arrive out of order.
    
    Comments
    
    By old3n () on 2004-03-15 03:33
    
    Yeps, you're right, I only glanced at the advisory and misread 'segment' -> 'fragment'... At the time I wondered for a second how come this would be specific to TCP... :7

Latest Articles

Thu, Apr 18
- 05:05 Coming soon to a -current system near you: parallel raw IP input (0)
Wed, Apr 17
- 05:33 In -current, default write format for tar(1) changed to "pax" (9)
Wed, Apr 10
- 18:50 OpenSMTPD 7.5.0p0 Released (2)
Tue, Apr 09
- 04:49 20 years since "and we're just starting": undeadly.org turns 20 (2024-04-09) (13)
Fri, Apr 05
- 06:16 OpenBSD 7.5 released (2)
Thu, Mar 28
- 18:18 LibreSSL 3.8.4 and 3.9.1 released (0)
Tue, Mar 12
- 06:53 OpenSSH 9.7/9.7p1 released! (0)
Mon, Mar 11
- 11:28 Game of Trees 0.97 released (0)
Sun, Mar 10
- 09:06 LibreSSL versions 3.8.3 and 3.9.0 released (0)

Credits

Copyright © 2004-2008 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 April 2nd 2004 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.]