[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <55FFC9BD.6030503@quarkslab.com>
Date: Mon, 21 Sep 2015 11:11:25 +0200
From: Jonathan Salwan <jsalwan@...rkslab.com>
To: oss-security@...ts.openwall.com
Subject: Samsung S4 (GT-I9500) multiple kernel vulnerabilities
Samsung S4 (GT-I9500) version I9500XXUEMK8 vulnerabilities' report
==================================================================
1 - Bugs description
--------------------
This report describes 5 bugs in the Samsung S4 GT-I9500 JB (I9500XXUEMK8).
- 1 Kernel memory disclosure (CVE-2015-1800)
- 4 Kernel memory corruption (CVE-2015-1801)
Driver affected : samsung_extdisp (s3cfb_extdsp)
1.1 - Kernel memory disclosure
------------------------------
1.1.1 - CVE-2015-1800: Video driver samsung_extdisp (1 bug)
-----------------------------------------------------------
In the s3cfb_extdsp_ioctl() function, located in the drivers/video/samsung
_extdisp/s3cfb_extdsp_ops.c file, the structure s3cfb_extdsp_time_stamp is
allocated on the stack frame. Below, all attributes of this structure:
struct s3cfb_extdsp_time_stamp {
int y_fd;
int uv_fd;
struct timeval time_marker;
};
In the same function, in the switch case of the ioctl, we can find the
S3CFB_EXTDSP_GET_FB_PHY_ADDR request. Below, the part of the code
related about:
case S3CFB_EXTDSP_GET_FB_PHY_ADDR:
time_stamp2.y_fd = -1;
time_stamp2.uv_fd = -1;
/* ... */
if (copy_to_user((struct s3cfb_extdsp_time_stamp __user*)arg,
&time_stamp2,
sizeof(time_stamp2))) {
dev_err(fbdev->dev, "copy_to error\n");
return -EFAULT;
}
As you can see, the attribute y_fd and uv_fd are initialised but not the
timeval structure. So, when the copy_to_user occurs, we have a kernel
memory disclosure of sizeof(struct timeval).
1.2 - Kernel memory corrpution
------------------------------
1.2.1 - CVE-2015-1801: Video driver samsung_extdisp (4 bugs)
------------------------------------------------------------
In the s3cfb_extdsp_ioctl function, located in the drivers/video/
samsung_extdisp/s3cfb_extdsp_ops.c file, some ioctl requests are
vulnerable. The destination pointer can be controlled from the userspace.
Below, the vulnerable requests:
case FBIOGET_FSCREENINFO:
ret = memcpy(argp, &fb->fix, sizeof(fb->fix)) ? 0 : -EFAULT;
break;
case FBIOGET_VSCREENINFO:
ret = memcpy(argp, &fb->var, sizeof(fb->var)) ? 0 : -EFAULT;
break;
case S3CFB_EXTDSP_GET_LCD_WIDTH:
ret = memcpy(argp, &lcd->width, sizeof(int)) ? 0 : -EFAULT;
if (ret) {
dev_err(fbdev->dev, "failed to S3CFB_EXTDSP_GET_LCD_WIDTH\n");
break;
}
break;
case S3CFB_EXTDSP_GET_LCD_HEIGHT:
ret = memcpy(argp, &lcd->height, sizeof(int)) ? 0 : -EFAULT;
if (ret) {
dev_err(fbdev->dev, "failed to S3CFB_EXTDSP_GET_LCD_HEIGHT\n");
break;
}
break;
The argp pointer can be controlled by the user and it is not verified by the
driver. As you can see, the argp pointer is used as destination in all
memcpy
functions.
These memory corruptions may cause an elevation of privileges and/or a
denial
of service.
2 - Timeline
------------
Feb 03 2014 - Vulnerabilities found
Aug 08 2014 - Report sent to the Samsung Security Team
Nov 24 2014 - Samsung confirmed the security issues
Feb 11 2015 - Private CVE request to the Mitre team but no response
Feb 18 2015 - Second private CVE request to the Mitre team but no response
Mar 16 2015 - CVE request to Kurt Seifried
Mar 17 2015 - CVE assigned: CVE-2015-1800 (1 bug) and CVE-2015-1801 (4 bugs)
Sep 21 2015 - Still not patched by Samsung. Full disclosure.
--
jonathan
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
