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

linux1394.txt

linux1394.txt
Posted Jun 22, 2004
Authored by infamous41md

The Linux kernel IEEE 1394 aka Firewire driver suffers from integer overflows that can result in a local denial of service and possible code execution. Both the 2.4 and 2.6 series are affected.

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

linux1394.txt

Change Mirror Download
Linux kernel IEEE 1394(Firewire) driver - integer overflows
-----------------------------------------------------------

Link:
http://www.linux1394.org/index.php

Driver Description:
IEEE 1394 is a standard defining a high speed serial bus. This bus is also named
FireWire by Apple or i.Link by Sony. All these names refer to the same thing,
but the neutral term IEEE 1394 (or just 1394) is used on these web pages and in
the sources.

This driver is included in standard linux distros. It is located in
/usr/src/linux/drivers/ieee1394/.

Impact:
Local DOS, possible code execution

Vuln:

there exist multiple integer overflows in the memory allocation scheme of the
driver. in the write method of the driver a user buffer is copied into kernel
space. in this buffer is a request structure that contains an unsigned length
field. this field is used to allocate memory, after it is added to another
number. there are no checks to see if this overflows during integer addition.
this problem occurs in the alloc_hpsb_packet function.
the problem exists in both the 2.4 and 2.6 version of driver, 2.2 was not
checked. the functions leading up to this are spread out through a couple
files:

2.4:

-> raw1394_write() -- raw1394.c:852
-> state_connected() -- raw1394.c:806
-> handle_remote_request() -- raw1394.c:658
-> hpsb_make_writebpacket() -- ieee1394_transactions.c:357
-> alloc_hpsb_packet() -- ieee1394_core.c:114

2.6:

-> raw1394_write() -- raw1394.c:2149
-> state_connected() -- raw1394.c:2061
-> handle_async_request() -- raw1394.c:620
-> hpsb_make_writepacket() -- ieee1394_transactions.c:291
-> alloc_hpsb_packet() -- ieee1394_core.c:123

Detail:

Starting from the write() method of the driver, a user structure is copied
into kernel buffer. Depending on the state of the connection, and type of
request, eventually we get to the offending code, in 2.4 from alloc_hpsb_packet():

+variable data_size is a size_t passed from user supplied structure+

data = kmalloc(data_size + 8, kmflags);
if (data == NULL) {
kmem_cache_free(hpsb_packet_cache, packet);
return NULL;
}
packet->data = data;
packet->data_size = data_size;

and then back in handle_remote_request():

+req->req.length was the same value used above to size the buffer

if (copy_from_user(packet->data, int2ptr(req->req.sendb), req->req.length)) {
req->req.error = RAW1394_ERROR_MEMFAULT;
}


this results in possibly gigabytes of memory being copied into a small buffer, which will crash system. depending on the layout of the slab this buffer lives on, some sort of exploitation may be possible. if u look around you'll find similar issues with the read() request as well, involving packets being allocated with incorrect lengths. the contact on sourceforge was emailed last week and given until monday to reply. i never heard back from them, so im submitting this here.

-- --
-sean
Login or Register to add favorites

File Archive:

July 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jul 1st
    27 Files
  • 2
    Jul 2nd
    10 Files
  • 3
    Jul 3rd
    35 Files
  • 4
    Jul 4th
    27 Files
  • 5
    Jul 5th
    18 Files
  • 6
    Jul 6th
    0 Files
  • 7
    Jul 7th
    0 Files
  • 8
    Jul 8th
    28 Files
  • 9
    Jul 9th
    44 Files
  • 10
    Jul 10th
    24 Files
  • 11
    Jul 11th
    25 Files
  • 12
    Jul 12th
    11 Files
  • 13
    Jul 13th
    0 Files
  • 14
    Jul 14th
    0 Files
  • 15
    Jul 15th
    0 Files
  • 16
    Jul 16th
    0 Files
  • 17
    Jul 17th
    0 Files
  • 18
    Jul 18th
    0 Files
  • 19
    Jul 19th
    0 Files
  • 20
    Jul 20th
    0 Files
  • 21
    Jul 21st
    0 Files
  • 22
    Jul 22nd
    0 Files
  • 23
    Jul 23rd
    0 Files
  • 24
    Jul 24th
    0 Files
  • 25
    Jul 25th
    0 Files
  • 26
    Jul 26th
    0 Files
  • 27
    Jul 27th
    0 Files
  • 28
    Jul 28th
    0 Files
  • 29
    Jul 29th
    0 Files
  • 30
    Jul 30th
    0 Files
  • 31
    Jul 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