oss-sec mailing list archives
Re: CVE-2018-1000204: Linux kernel 3.18 to 4.16 infoleak due to incorrect handling of SG_IO ioctl
From: Alexander Potapenko <glider () google com>
Date: Tue, 26 Jun 2018 15:45:57 +0200
On Fri, Jun 22, 2018 at 3:32 PM Vladis Dronov <vdronov () redhat com> wrote:
Hello, Alexander,
Hi Vladis,
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;
Yes, you're right. It appears unlikely that a user has both CAP_SYS_ADMIN and CAP_SYS_RAWIO.
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.
How do I proceed with this?
Best regards, Vladis Dronov | Red Hat, Inc. | Product Security Engineer
Thank you, -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
Current thread:
- CVE-2018-1000204: Linux kernel 3.18 to 4.16 infoleak due to incorrect handling of SG_IO ioctl Alexander Potapenko (Jun 08)
- Re: CVE-2018-1000204: Linux kernel 3.18 to 4.16 infoleak due to incorrect handling of SG_IO ioctl Vladis Dronov (Jun 22)
- Re: CVE-2018-1000204: Linux kernel 3.18 to 4.16 infoleak due to incorrect handling of SG_IO ioctl Alexander Potapenko (Jun 26)
- Re: CVE-2018-1000204: Linux kernel 3.18 to 4.16 infoleak due to incorrect handling of SG_IO ioctl Vladis Dronov (Jun 22)