VirtualBox

Ticket #15167 (closed task: wontfix)

Opened 4 years ago

Last modified 2 years ago

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 frank) (diff)

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

comment:1 Changed 4 years ago by frank

  • Description modified (diff)

comment:2 Changed 4 years ago by frank

  • Status changed from new to closed
  • Resolution set to wontfix

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.

comment:4 follow-up: ↓ 5 Changed 2 years ago by 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.

comment:5 in reply to: ↑ 4 Changed 2 years ago by frank

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 Changed 2 years ago by socratis

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
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use