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)
By Anonymous Coward (68.165.27.172) on
Comments
By tedu (71.139.164.105) on
yes
By Anonymous Coward (70.162.93.223) on
Comments
By Chazza (69.109.104.15) on
patch -p0 < 010_m_dup1.patch
Comments
By Chazza (69.109.104.15) on
duh, forget it. sorry, need sleep.
By Anonymous Coward (213.119.198.47) on
By Anonymous Coward (195.159.118.253) on
Comments
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
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
By Igor Sobrado (sobrado) on
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
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
By Igor Sobrado (sobrado) on
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.
By Anonymous Coward (87.79.237.121) on
> 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.
By Igor Sobrado (sobrado) on
By Cabal (Cabal) Cabal on http://www.enginuity.org/
Comments
By Jeff Quast (dingo) on
'block inet6' is so easy its not even funny
Comments
By sthen (85.158.44.148) on
don't forget about any 'set skip on...'
By Jeff Quast (dingo) af.dingo@gmail.com on
I wish this vulnerability applied to me :(
Comments
By Brandin (63.228.83.239) on
>
> 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
By sthen (85.158.44.148) on
No need for the attacking host to support IPv6, it just needs to be able to put packets on the wire.
By Igor Sobrado (sobrado) on
>
> 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
By Anonymous Coward (87.79.237.121) on
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
By Igor Sobrado (sobrado) on
>
> 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
By Anonymous Coward (87.79.237.121) on
> IPv4 flavour of Apache or install Apache 2.x.
Apache 2? *laugs himself senseless*
Ask henning@ if you really want to know why.
By patthoyts (194.200.145.5) on
By Kurt Miller (69.122.119.232) on
> >
> > 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
By 2001:470:1f00:ffff::2b (216.62.11.163) on http://tunnelbroker.net/
I've been using HurricaneElectric's service for years without a problem http://tunnelbroker.net/
By Igor Sobrado (sobrado) on
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.
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
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
By Bernd (129.132.105.166) on
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
By Bernd (129.132.105.166) on
>
> 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. :-)
By Travers Buda (12.216.179.205) traversbuda@gmail.com on
>
> 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.
By Anonymous Coward (85.178.96.32) on
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
By Anonymous Coward (216.220.225.229) on
>
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
By Travers Buda (12.216.179.205) traversbuda@gmail.com on
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.
By Cobalt (70.162.93.223) on
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.
By Jussi Heino (MunOBSD) on
> 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
By Travers Buda (12.216.179.205) traversbuda@gmail.com on
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
By Travers Buda (12.216.179.205) traversbuda@gmail.com on
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
By Corey (208.191.177.19) on
By Anonymous Coward (122.49.157.192) on
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.
By Anonymous Coward (62.75.220.75) on
Further Checking in the IPv6-Stack should be done....
Comments
By Anonymous Coward (143.127.131.4) on
> Further Checking in the IPv6-Stack should be done....
get started then.
By Anonymous Coward (69.70.178.208) on
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.
Otherwise, block in inet6 may be ineffective depending on how you constructed your ruleset and the corresponding rule expansion. Perhaps is a better recommendation if you do not utilize IPv6 services whatsoever.
By blocker (86.91.41.86) on
Does that not include ip6 traffic as well then ?
Comments
By Anonymous Coward (24.37.242.64) on
> 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.
By Mike Erdely (71.241.230.202) mike@erdelynet.com on http://erdelynet.com/
> Does that not include ip6 traffic as well then ?
As long as you don't have any "pass inet6" rules after that.
Comments
By Mike Erdely (65.222.245.131) mike@erdelynet.com on http://erdelynet.com/
I guess I should say: as long as all of your pass rules say "pass inet".
By Anonymous Coward (143.127.131.4) on
> Does that not include ip6 traffic as well then ?
>
all means all.
By Anonymous Coward (74.115.21.120) on
By Jussi Heino (MunOBSD) on
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
By Anonymous Coward (143.127.131.4) on
>
> 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
By RC (71.105.36.236) on
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
By Denis (213.41.245.173) on
>
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
By Anonymous Coward (149.135.121.184) on
> >
> 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
By Anonymous Coward (72.193.216.83) on
Does anyone know the total remote hole count for the
entire OpenBSD history?
Comments
By Anonymous Coward (86.81.223.219) on
>
> 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.
By Anonymous Coward (216.68.198.57) on
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
By Anonymous Coward (143.127.131.4) on
> 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
By Anonymous Coward (216.68.198.57) on
> 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.
By Dj SyNko (80.104.72.198) on
By Renaud Allard (renaud) renaud@llorien.org on
Comments
By Anonymous Coward (149.135.121.184) on
I suggested this years ago
By Bob Bostwick (64.140.63.110) on
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.
By Anonymous Coward (208.53.138.41) on
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
By Renaud Allard (renaud) on
>
> 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?
By Matthias Kilian (91.3.56.222) on
> 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
By Anonymous Coward (122.49.157.192) on
I'd prefer ham sandwiches myself.
By Anonymous Coward (124.106.218.42) on
>
> 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.
By Anonymous Coward (216.93.163.234) on
>
> 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.
By Anonymous Coward (151.188.247.104) on
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
By Anonymous Coward (149.135.121.184) on
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.
By Anonymous Coward (216.68.198.57) on
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....