Contributed by jose on from the stack-bugs dept.
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 FriedlOpenBSD's TCP/IP stack did not impose limits on how many out-of-order TCP segments are queued in the system.To: security-announce@openbsd.org Subject: TCP reassembly DoS
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)
By Brad () brad at comstyle dot com on mailto:brad at comstyle dot com
http://marc.theaimsgroup.com/?l=openbsd-cvs&m=107828144907640&w=2
Errata is up now.
By gwyllion () on
ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.4/common/013_tcp.patch
By Noryungi () on
Comments
By Noryungi () on
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 http://unixfu.net
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
By Chris Humphries () chris@unixfu.net on http://unixfu.net
sounds like a hole to me :)
Comments
By Anonymous Coward () on
denial of service != remote hole
theo != openbsd
cvs commit != patch
Comments
By Anonymous Coward () on
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
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 mailto:chris@unixfu.net
i posted the previous post. forgot to put my name in, but it was me, thought was obvious :)
By JM () on
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 mailto:chris@unixfu.net
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
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 mailto:chris@unixfu.net
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
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 mailto:chris@unixfu.net
Comments
By Anonymous Coward () on
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
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
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 mailto:marklar_@hotmail.com
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 mailto:chris@unixfu.net
> 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
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 mailto:chris@unixfu.net
By djm () on
I'm not sure whether you are trolling, or just very ignorant.
By Anonymous Coward () on
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
This sentence alone screams "I don't know what I'm talking about". Sorry.
By djm () on
By emcis () on
Comments
By gwyllion () on
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.
By djm () on
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
By Chris Humphries () chris@unixfu.net on mailto:chris@unixfu.net
you are missing the point here.
Comments
By tedu () on
By djm () on
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 sonzofacworth.net
>Update headers.
> make includes
thanks
Comments
By MK () on
By Ian McWiliam () ian at dodo dot com do au on mailto:ian at dodo dot com do au
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
By asdfg () on
cp /usr/src/sys/netinet/tcp_var.h /usr/include/netinet/tcp_var.h
By Mike () on
Comments
By Ian McWilliam () ian at dodo dot com dot au on mailto:ian at dodo dot com dot au
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. 013_tcp.patch
Comments
By Mike () on
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
By Anonymous Coward () on
make inludes != make includes
Read what you have posted carefully.
Comments
By Mike () on
Comments
By Ian McWilliam () ian at dodo dot com dot au on mailto:ian at dodo dot com dot au
Sounds like your source tree has problems.
Comments
By Mike () on
By old3n () on
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
By djm () on
Comments
By old3n () on
I guess I'll need to check what actually is implemented then.
Comments
By tedu () on
Comments
By old3n () on