Bug 1178760 (CVE-2020-12912) - VUL-0: CVE-2020-12912: kernel-source: AMD: unprivileged access to RAPL allows for side channel attacks
Summary: VUL-0: CVE-2020-12912: kernel-source: AMD: unprivileged access to RAPL allows...
Status: RESOLVED FIXED
Alias: CVE-2020-12912
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Security Team bot
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/271597/
Whiteboard: CVSSv3.1:SUSE:CVE-2020-12912:5.5:(AV:...
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-13 07:59 UTC by Marcus Meissner
Modified: 2024-06-25 15:26 UTC (History)
6 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2020-11-13 07:59:20 UTC
A flaw in the Linux kernels implementation of RAPL for AMD CPUS allowed a user with a local account to use the RAPL interface to infer CPU execution state.  This could allow information leak of sensitive information across security boundaries.

References:
https://bugzilla.redhat.com/show_bug.cgi?id=1897402
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-12912
https://access.redhat.com/security/cve/CVE-2020-12912
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912
https://www.amd.com/en/corporate/product-security
Comment 1 Marcus Meissner 2020-11-13 07:59:36 UTC
(this is for AMD; not for Intel)
Comment 2 Michal Hocko 2020-11-13 08:06:06 UTC
(In reply to Marcus Meissner from comment #1)
> (this is for AMD; not for Intel)

But they are both exporting data via the same powercap driver, right? So we should be only adding the CVE reference into the existing patch.
Comment 3 Marcus Meissner 2020-11-13 10:32:22 UTC
i do not know.

the fix is in the common sysfs code, yes.
Comment 4 Marcus Meissner 2020-11-13 13:00:24 UTC
driver seems to be in drivers/hwmon/amd_energy.c

using the hwmon framework

hwmon seems to generally pass out world readable permisssions

-> so different place, needing different fix?
Comment 5 Marcus Meissner 2020-11-13 13:00:40 UTC
seems to be however only Linux Kernel 5.8 or newer
Comment 6 Takashi Iwai 2020-11-13 21:55:28 UTC
(In reply to Marcus Meissner from comment #4)
> driver seems to be in drivers/hwmon/amd_energy.c
> 
> using the hwmon framework
> 
> hwmon seems to generally pass out world readable permisssions
> 
> -> so different place, needing different fix?

If it's about hwmon, the sysfs creation is done in the core, but its permission is controlled via is_visible callback.  I guess just adjusting the value in amd_energy_is_visible() to 0400 should work.

Adding Jean to Cc, as he must have better clue for hwmon.

(In reply to Marcus Meissner from comment #5)
> seems to be however only Linux Kernel 5.8 or newer

Yes, it looks so.  SLE15-SP3 already has the backport, but SLE15-SP2 doesn't.
So only TW is the released product.
Comment 7 Jean Delvare 2020-11-16 09:51:29 UTC
As usual, all the references are incredibly vague as to what the actual attack vector is. Without a clear description of the problem, I can't possibly suggest a smart workaround. Oh well.

Upstream went for mode 0440 for the sysfs attribute file:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=60268b0e8258fdea9a3c9f4b51e161c123571db3

I suppose we want to backport this commit. Unfortunately this will make the driver essentially useless, as "sensors" and graphical front-ends to hwmon drivers are meant to run as non-root users.

Note that sysfs attribute permissions can be changed by root at any time, the driver only decides the initial permissions. So people willing to take the risk can always undo the change above in user-space.
Comment 8 Marcus Meissner 2020-11-16 16:23:35 UTC
the attack is described in https://platypusattack.com/

(basically different power consumption depnding on cryptographic key material input allowed extracting it.)

I was not aware that AMD also provded this kind of very finegrained power metering.
Comment 9 Takashi Iwai 2020-11-23 10:09:21 UTC
(In reply to Jean Delvare from comment #7)
> As usual, all the references are incredibly vague as to what the actual
> attack vector is. Without a clear description of the problem, I can't
> possibly suggest a smart workaround. Oh well.
> 
> Upstream went for mode 0440 for the sysfs attribute file:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=60268b0e8258fdea9a3c9f4b51e161c123571db3
> 
> I suppose we want to backport this commit. Unfortunately this will make the
> driver essentially useless, as "sensors" and graphical front-ends to hwmon
> drivers are meant to run as non-root users.
> 
> Note that sysfs attribute permissions can be changed by root at any time,
> the driver only decides the initial permissions. So people willing to take
> the risk can always undo the change above in user-space.

For the device file permissions, usually logind tweaks via ACL for desktop users.  We might provide a similar trick if it's really needed.

In anyway, if there's any other better way, I'm going to backport the fix to SLE15-SP2 and cve/* branches.
Comment 10 Jean Delvare 2020-11-23 13:31:41 UTC
We have to follow upstream anyway.

The amd_energy driver is not in SLE15 SP2 though, so you don't have to backport the patch there. It's only needed in SLE15 SP3 because there was a feature request to add the amd_energy driver thereto.

I'm going to deal with SLE15 SP3 if that's OK with you, that way I get the opportunity to also backport all other upstream changes to the driver since my initial backport. That way our version of the driver in SP3 will be as close to the upstream one as possible.
Comment 11 Takashi Iwai 2020-11-23 13:39:04 UTC
(In reply to Jean Delvare from comment #10)
> I'm going to deal with SLE15 SP3 if that's OK with you, that way I get the
> opportunity to also backport all other upstream changes to the driver since
> my initial backport. That way our version of the driver in SP3 will be as
> close to the upstream one as possible.

Sure, please go ahead.  I reassign this to you now.
Please reassign back to security team once after you backport finished.  Thanks.
Comment 22 Gianluca Gabrielli 2022-04-28 07:32:19 UTC
done
Comment 33 Maintenance Automation 2023-12-01 12:30:08 UTC
SUSE-SU-2023:4625-1: An update that solves three vulnerabilities and has one security fix can now be installed.

Category: security (important)
Bug References: 1170415, 1170446, 1178760, 1217513
CVE References: CVE-2020-12912, CVE-2020-8694, CVE-2020-8695
Sources used:
Containers Module 12 (src): runc-1.1.10-16.40.1, docker-24.0.7_ce-98.103.1, containerd-1.7.8-16.88.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 34 Maintenance Automation 2023-12-20 20:30:13 UTC
SUSE-SU-2023:4936-1: An update that solves three vulnerabilities, contains one feature and has five security fixes can now be installed.

Category: security (important)
Bug References: 1170415, 1170446, 1178760, 1210141, 1213229, 1213500, 1215323, 1217513
CVE References: CVE-2020-12912, CVE-2020-8694, CVE-2020-8695
Jira References: PED-6180
Sources used:
openSUSE Leap Micro 5.3 (src): docker-24.0.7_ce-150000.190.4
openSUSE Leap Micro 5.4 (src): docker-24.0.7_ce-150000.190.4
openSUSE Leap 15.4 (src): rootlesskit-1.1.1-150000.1.3.3, docker-24.0.7_ce-150000.190.4
openSUSE Leap 15.5 (src): rootlesskit-1.1.1-150000.1.3.3, docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise Micro for Rancher 5.3 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise Micro 5.3 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise Micro for Rancher 5.4 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise Micro 5.4 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise Micro 5.5 (src): docker-24.0.7_ce-150000.190.4
Containers Module 15-SP4 (src): rootlesskit-1.1.1-150000.1.3.3, docker-24.0.7_ce-150000.190.4
Containers Module 15-SP5 (src): rootlesskit-1.1.1-150000.1.3.3, docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise High Performance Computing 15 SP1 LTSS 15-SP1 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise High Performance Computing ESPOS 15 SP3 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise Server 15 SP1 LTSS 15-SP1 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise Server for SAP Applications 15 SP1 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise Server for SAP Applications 15 SP2 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise Server for SAP Applications 15 SP3 (src): docker-24.0.7_ce-150000.190.4
SUSE Enterprise Storage 7.1 (src): docker-24.0.7_ce-150000.190.4
SUSE CaaS Platform 4.0 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise Micro 5.1 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise Micro 5.2 (src): docker-24.0.7_ce-150000.190.4
SUSE Linux Enterprise Micro for Rancher 5.2 (src): docker-24.0.7_ce-150000.190.4

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.