what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

linux.SbusPROM.txt

linux.SbusPROM.txt
Posted Jun 29, 2004
Authored by infamous41md

There exists multiple integer overflows in routines that handle copying in user supplied data for the Linux Sbus PROM driver. They allow for a local denial of service attack and possible code execution.

tags | advisory, denial of service, overflow, local, code execution
systems | linux
SHA-256 | d82e6c596490895e4fdf7268fb5bd8cee56764769900a142ebd3a32e518925b8

linux.SbusPROM.txt

Change Mirror Download
Sbus PROM driver multiple integer overflows
-------------------------------------------

Description:

This character device driver allows user programs to access the PROM
device tree. It is compatible with the SunOS /dev/openprom driver and the
NetBSD /dev/openprom driver. The SunOS eeprom utility works without any
modifications.

Source:

This driver is distributed by default in all of the distros that I have.
It's source can be found:
/usr/src/linux/drivers/sbus/char/openprom.c

Impact:

Local DOS, possible code execution depending on location of the overflowed
buffer in the slab.

Bug:

There exist multiple integer overflows in routines that handle copying in
user supplied data. In both routines, user supplied parameters are used
to allocate buffers after being added to another number. Passing certain
values will result in integer overflows and small buffers being allocated.
Then large amounts of user data are copied into these buffers. Both of
the functions in which the overflows occur are 'utility' functions called
from multiple other functions. An ioctl() call is the simplest way to
access them.


Detail:

The copyin() and the copyin_string() function are both vulnerable:


/* Copy in a whole string from userspace into kernelspace. */
static int copyin_string(char *user, size_t len, char **ptr)
{
char *tmp;

/* ME: it's not signed; if( len + 1 < len ) .. */
1] if (len < 0 || len + 1 < 0)
return -EINVAL;

2] tmp = kmalloc(len + 1, GFP_KERNEL);
if (!tmp)
return -ENOMEM;

3] if(copy_from_user(tmp, user, len)) {
kfree(tmp);
return -EFAULT;
}
..... snip .....

In this function it appears they forgot that size_t is not signed. The
checks made at 1] will never be true, and by passing in ~0 for the len
variable an integer overflow occurs at 2]. Then at 3] user supplied data
is copied int this buffer. In various ioctl() calls for both the bsd and
sun versions the user has full control over the user and len variables.


static int copyin(struct openpromio *info, struct openpromio **opp_p)
{
int bufsize;

if (!info || !opp_p)
return -EFAULT;

1] if (get_user(bufsize, &info->oprom_size))
return -EFAULT;

if (bufsize == 0)
return -EINVAL;

/* If the bufsize is too large, just limit it.
* Fix from Jason Rappleye.
* ME: apparently not fixed enough
*/
2] if (bufsize > OPROMMAXPARAM)
bufsize = OPROMMAXPARAM;

3] if (!(*opp_p = kmalloc(sizeof(int) + bufsize + 1, GFP_KERNEL)))
return -ENOMEM;
memset(*opp_p, 0, sizeof(int) + bufsize + 1);

4] if (copy_from_user(&(*opp_p)->oprom_array,
&info->oprom_array, bufsize)) {
kfree(*opp_p);
return -EFAULT;
}
return bufsize;
}

The bufsize integer variable obtained from the user at 1] is checked for
being to large at 2], but it is not checked for being negative. we then
have an overflow occuring at 3] when the buffer is allocated. Then at 4]
this buffer is used to hold user data, resulting in memory being overwritten.

Vendor Status:

The driver authors from the source listing were contacted and didn't reply.

--
-sean
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close