Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 22 Jun 2018 09:32:43 -0400 (EDT)
From: Vladis Dronov <vdronov@...hat.com>
To: Alexander Potapenko <glider@...gle.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE-2018-1000204: Linux kernel 3.18 to 4.16
 infoleak due to incorrect handling of SG_IO ioctl

Hello, Alexander,

Could you please, explain, why do you think CVE-2018-1000204 is a security
flaw?

> The problem has limited scope, as users don't usually have permissions
> to access SCSI devices. On the other hand, e.g. the Nero user manual
> suggests doing `chmod o+r+w /dev/sg*` to make the devices accessible.

There is a check in the kernel in sg_build_indirect() exactly for this
situation:

        [drivers/scsi/sg.c]
        if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO))
                gfp_mask |= __GFP_ZERO;

This means non-root user will get zero-ed pages even if it has o+rw access
to /dev/sg*. Tests of your reproducer on systems available to me confirm
this, i.e. non-root user gets a zero-ed out buffer even if it is able to
access /dev/sg*.

I may not got smth correctly, but for now I do not see CVE-2018-1000204
as a security flaw and I believe a reject request to MITRE should be
issued.

Best regards,
Vladis Dronov | Red Hat, Inc. | Product Security Engineer

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.