#15167 closed task (wontfix)
Kernel Address Info Leak
| Reported by: | wcrobert | Owned by: | |
|---|---|---|---|
| Component: | other | Version: | VirtualBox 5.0.14 |
| Keywords: | info leak | Cc: | |
| Guest type: | other | Host type: | Linux |
Description (last modified by )
I reported this via secalert_us@… and was told to resubmit here:
vbox kernel module seems to printk kernel addresses that get picked up by syslog. This information could be used by someone who has gained uid/gid syslog adm (On Ubuntu) to successfully chain an attack to kernel data structures (thus defeating ASLR). Information from /proc/modules is sanitized for non-root users.
The requested fix is to stop printing out kernel addresses.
Host $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.4 LTS Release: 14.04 Codename: trusty
$uname -a Linux wcrobert-MOBL1 3.19.0-18-generic #18~14.04.1-Ubuntu SMP Wed May 20 09:38:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
VBox Version: Version 5.0.14 r105127
What I found in syslog:
Feb 11 11:27:57 wcrobert-MOBL1 kernel: [ 5.881847] vboxdrv: Found 4 processor cores Feb 11 11:27:57 wcrobert-MOBL1 kernel: [ 5.901307] vboxdrv: TSC mode is Invariant, tentative frequency 2593993759 Hz Feb 11 11:27:57 wcrobert-MOBL1 kernel: [ 5.901310] vboxdrv: Successfully loaded version 5.0.14 (interface 0x00240000) Feb 11 11:27:57 wcrobert-MOBL1 kernel: [ 6.112417] vboxpci: IOMMU not found (not registered) Feb 11 12:16:23 wcrobert-MOBL1 kernel: [ 2913.482380] vboxdrv: ffffffffc0000020 VMMR0.r0 Feb 11 12:16:23 wcrobert-MOBL1 kernel: [ 2913.571393] vboxdrv: ffffffffc00fa020 VBoxDDR0.r0 Feb 11 12:16:23 wcrobert-MOBL1 kernel: [ 2913.572892] vboxdrv: ffffffffc0119020 VBoxDD2R0.r0 Feb 11 12:16:23 wcrobert-MOBL1 kernel: [ 2913.606759] vboxdrv: ffffffffc011d020 VBoxEhciR0.r0
Change History (6)
comment:1 by , 9 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 9 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
comment:3 by , 8 years ago
For completeness of this bug report, it was found to be a vulnerability.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3513
http://www.oracle.com/technetwork/security-advisory/cpuapr2017-3236618.html
follow-up: 5 comment:4 by , 8 years ago
FYI: Special permissions are not always required, normal user access is all that is needed on distros (Ubuntu) that don't restrict dmesg access. Additionally, kptr restrict settings had no affect on this.
comment:5 by , 8 years ago
Replying to wcrobert:
FYI: Special permissions are not always required, normal user access is all that is needed on distros (Ubuntu) that don't restrict dmesg access. Additionally, kptr restrict settings had no affect on this.
That's a bug of the default setup of such older Linux distributions.
comment:6 by , 8 years ago
But you've already fixed that, didn't you? Isn't that part of the 5.1.20 and 5.0.38 security fixes of 2017-04-18? And isn't the XXXXX... masked addresses from the sample below an indication/confirmation of the "fix" of this?
00:00:02.708683 SUP: Loaded VMMR0.r0 (C:\Program Files\Oracle\VirtualBox\VMMR0.r0) at 0xXXXXXXXXXXXXXXXX - ModuleInit at XXXXXXXXXXXXXXXX and ModuleTerm at XXXXXXXXXXXXXXXX using the native ring-0 loader 00:00:02.708708 SUP: VMMR0EntryEx located at XXXXXXXXXXXXXXXX and VMMR0EntryFast at XXXXXXXXXXXXXXXX 00:00:02.708712 SUP: windbg> .reload /f C:\Program Files\Oracle\VirtualBox\VMMR0.r0=0xXXXXXXXXXXXXXXXX
Sorry, this is NOT a security problem and not a problem at all. Having these addresses is not a problem because special permissions are required to make use of them.