Kernel Vulnerabilities in the Samsung S4

Multiple kernel vulnerabilities in the Samsung S4 (GT-I9500)

1 - Bugs Description

One year ago, we found some security issues in the Samsung S4 (GT-I9500) version I9500XXUEMK8. After several emails with the Samsung security team, these issues are still unpatched on the JB and KK family. This blog post details these issues and provides a potential patch. The affected driver is the samsung_extdisp and CVEs assigned are:

• 1 Kernel memory disclosure (CVE-2015-1800)
• 4 Kernel memory corruption (CVE-2015-1801)

1.1 - Kernel Memory Disclosure

1.1.1 - CVE-2015-1800: Video driver samsung_extdisp (1 bug)

The s3cfb_extdsp_ioctl() function, located in the drivers/video/samsung_extdisp/s3cfb_extdsp_ops.c file, contains a stack kernel memory disclosure. The structure s3cfb_extdsp_time_stamp is allocated on the stack frame. This structure contains these following attributes:

struct s3cfb_extdsp_time_stamp {
    int                 y_fd;
    int                 uv_fd;
    struct timeval      time_marker;
};

In the same function, inside the ioctl's switch case, we can find the S3CFB_EXTDSP_GET_FB_PHY_ADDR request.

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;
    }

This action initializes the y_fd and uv_fd attributes but not the timeval structure. When the copy_to_user function occurs, we have a kernel stack memory disclosure of sizeof(struct timeval) bytes. This kind of vulnerability is mainly used to leak some sensitive information or break kernel ASLR if it's enabled on the device.

1.2 - Kernel Memory Corruption

1.2.1 - CVE-2015-1801: Video driver samsung_extdisp (4 bugs)

The s3cfb_extdsp_ioctl() function, located in the drivers/video/samsung_extdisp/s3cfb_extdsp_ops.c file, contains several kernel memory corruptions. An attacker can control the destination pointer (argp of the memcpy function). Here below the four ioctl's vulnerable actions cases:

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 memcpy() doesn't check if the destination pointer is located in the user or kernel space. If an attacker sets the argp pointer to a kernel address, he could overwrite some function pointers or values and elevate its privileges or cause a denial of service. In this scenario he would have to use theaccess_ok() function or simply use the copy_to_user() function.

2 - Patch

If your device is under the LL family, you're safe. Otherwise, if you are under the JB or KK family, we recommend to apply this following patch which should fix these issues.

diff --git a/drivers/video/samsung_extdisp/s3cfb_extdsp_ops.c b/drivers/video/samsung_extdisp/s3cfb_extdsp_ops.c
index ee0a7dd..a1848fc 100644
--- a/drivers/video/samsung_extdisp/s3cfb_extdsp_ops.c
+++ b/drivers/video/samsung_extdisp/s3cfb_extdsp_ops.c
@@ -619,8 +619,8 @@ int s3cfb_extdsp_ioctl(struct fb_info *fb, unsigned int cmd, unsigned long arg)
        struct fb_fix_screeninfo *fix = &fb->fix;
        struct s3cfb_extdsp_window *win = fb->par;
        struct s3c_fb_pd_win *lcd = fbdev->lcd;
-       struct s3cfb_extdsp_time_stamp time_stamp;
-       struct s3cfb_extdsp_time_stamp time_stamp2;
+       struct s3cfb_extdsp_time_stamp time_stamp = {0};
+       struct s3cfb_extdsp_time_stamp time_stamp2 = {0};
        void *argp = (void *)arg;
        int ret = 0;
        dma_addr_t start_addr = 0;
@@ -761,11 +761,11 @@ int s3cfb_extdsp_ioctl(struct fb_info *fb, unsigned int cmd, unsigned long arg)
                        break;

                case FBIOGET_FSCREENINFO:
-                       ret = memcpy(argp, &fb->fix, sizeof(fb->fix)) ? 0 : -EFAULT;
+                       ret = copy_to_user(argp, &fb->fix, sizeof(fb->fix)) ? -EFAULT : 0;
                        break;

                case FBIOGET_VSCREENINFO:
-                       ret = memcpy(argp, &fb->var, sizeof(fb->var)) ? 0 : -EFAULT;
+                       ret = copy_to_user(argp, &fb->var, sizeof(fb->var)) ? -EFAULT : 0;
                        break;

                case FBIOPUT_VSCREENINFO:
@@ -787,7 +787,7 @@ int s3cfb_extdsp_ioctl(struct fb_info *fb, unsigned int cmd, unsigned long arg)
                        break;

                case S3CFB_EXTDSP_GET_LCD_WIDTH:
-                       ret = memcpy(argp, &lcd->width, sizeof(int)) ? 0 : -EFAULT;
+                       ret = copy_to_user(argp, &lcd->width, sizeof(int)) ? -EFAULT : 0;
                        if (ret) {
                                dev_err(fbdev->dev, "failed to S3CFB_EXTDSP_GET_LCD_WIDTH\n");
                                break;
@@ -796,7 +796,7 @@ int s3cfb_extdsp_ioctl(struct fb_info *fb, unsigned int cmd, unsigned long arg)
                        break;

                case S3CFB_EXTDSP_GET_LCD_HEIGHT:
-                       ret = memcpy(argp, &lcd->height, sizeof(int)) ? 0 : -EFAULT;
+                       ret = copy_to_user(argp, &lcd->height, sizeof(int)) ? -EFAULT : 0;
                        if (ret) {
                                dev_err(fbdev->dev, "failed to S3CFB_EXTDSP_GET_LCD_HEIGHT\n");
                                break;

3 - Timeline

A brief note about that work and the timeline. When we discovered these bugs (actually manually auditing some code), we were working on a totally different job. We did not look deeper at that time because we were focused on our main job and we were really not sure these were not "simple" bugs. Once our job was over, we had a quick look at these bugs. It seemed to us it was actually a bit more than "simple" bugs and wrote a report to Samsung. We did not try to exploit them as it was hardware dependent and did not had the proper device to play with. We felt such bugs were quite common in the code so we tried to get in touch with Samsung. They just acknowledged the issues, then went silent until this blog post popped. Samsung just confirmed us that the JB and KK families will not be patched and that the vulnerabilities are only patched on the LL family.

• 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 sent to the Mitre team but no response
• Feb 18 2015 - Second private CVE request sent to the Mitre team but no response
• Mar 16 2015 - CVE request sent to Kurt Seifried
• Mar 17 2015 - CVE assigned: CVE-2015-1800 (1 bug) and CVE-2015-1801 (4 bugs)
• Sep 11 2015 - Last attempt to obtain a patch from the Samsung Security Team
• Sep 21 2015 - Still not patched by Samsung on the JB and KK families: going full disclosure

• Sep 22 2015 - Samsung confirmed us these vulnerabilities are patched only on the LL family

原文地址： http://blog.quarkslab.com/kernel-vulnerabilities-in-the-samsung-s4.html