Bugzilla – Bug 1196556
VUL-0: CVE-2022-29527: amazon-ssm-agent: creates world-writable sudoers file during runtime (race condition)
Last modified: 2022-10-20 13:56:25 UTC
+++ This bug was initially created as a clone of Bug #1196135 Found this via traces in the changes file of amazon-ssm-agent. The agent implement in Golang creates sudoers.d rules during runtime in: agent/session/utility/utility_unix.go: ``` // createSudoersFileIfNotPresent will create the sudoers file if not present. func (u *SessionUtil) createSudoersFileIfNotPresent(log log.T) error { // Return if the file exists if _, err := os.Stat(sudoersFile); err == nil { log.Infof("File %s already exists", sudoersFile) _ = u.changeModeOfSudoersFile(log) return err } // Create a sudoers file for ssm-user file, err := os.Create(sudoersFile) if err != nil { log.Errorf("Failed to add %s to sudoers file: %v", appconfig.DefaultRunAsUserName, err) return err } defer file.Close() if _, err := file.WriteString(fmt.Sprintf("# User rules for %s\n", appconfig.DefaultRunAsUserName)); err != nil { return err } if _, err := file.WriteString(fmt.Sprintf("%s ALL=(ALL) NOPASSWD:ALL\n", appconfig.DefaultRunAsUserName)); err != nil { return err } ``` So basically a root replacement user is created here which doesn't sound too good an idea. Interesting in the same source file is the following piece of code: ``` // changeModeOfSudoersFile will change the sudoersFile mode to 0440 (read only). // This file is created with mode 0666 using os.Create() so needs to be updated to read only with chmod. func (u *SessionUtil) changeModeOfSudoersFile(log log.T) error { fileMode := os.FileMode(sudoersFileMode) if err := os.Chmod(sudoersFile, fileMode); err != nil { log.Errorf("Failed to change mode of %s to %d: %v", sudoersFile, sudoersFileMode, err) return err } log.Infof("Successfully changed mode of %s to %d", sudoersFile, sudoersFileMode) return nil } ``` So this file is created with mode 0666? Hopefuly the author only thought of the mode not yet modified by the process's umask, otherwise this would be a great race condition involving a local root exploit. I looked at this package during runtime, but probably lacking the AWS environment it just pukes around and ends up in segmentation faults (yes!). So I can't really tell at the moment what the practical implications of this are.
Assigning to aosthof, since there is currently no dedicated maintainer for amazon-ssm-agent. Can you help sorting out this issue or find someone more suitable to to take care of it?
Hi Matthias, in fact we do have a maintainer set for amazon-ssm-agent which is the 'public-cloud-team' group in IBS. Is this what you were looking for?
(In reply to aosthof@suse.com from comment #2) > Hi Matthias, in fact we do have a maintainer set for amazon-ssm-agent which is the 'public-cloud-team' group in IBS. Is this what you were looking for? Ah I've only been looking in OBS since this is about Factory (at least for now). Does the public-cloud-team also have an associated email address in Bugzilla? IBS does not show one.
Yes, it's public-cloud-maintainers@suse.de
Okay, thanks for helping out, reassigning the bug accordingly.
Sean, can you please check on an EC2 instance if the amazon-ssm-agent creates a sudoers file with mode 0666? Thank you!
(In reply to aosthof@suse.com from comment #6) > Sean, can you please check on an EC2 instance if the amazon-ssm-agent creates a sudoers file with mode 0666? Thank you! Note that you will probably have to use a debugger or strace to notice this. An strace of the agent when the code mentioned in comment 0 runs would be most helpful to see what is really going on.
The file is created in the case that a user does not already exist and cannot be created and a sudoers file does not already exist. Currently the code creates a file with default permissions (0x666): ``` // Create a sudoers file for ssm-user file, err := os.Create(sudoersFile) ``` Then the file is written to and finally the permissions are change to (0x440) after writing. That means there's a window of time where the file exists and is writable by all. I assume this should probably be something like: ``` // Create a sudoers file for ssm-user file, err := os.OpenFile(sudoersFile, os.O_RDWR|os.O_CREATE, 0640) ``` That way the file is only writable by owner. Until the mode gets changed to readonly after writing.
I guess this could actually be: ``` file, err := os.OpenFile(sudoersFile, os.O_WRONLY|os.O_CREATE, 0640) ```
Thank you for confirming this. Can you report this (preferably privately) to upstream or should I do it?
Yeah, I can reach out.
Amazon security team is working on a fix which is expected to be released in mid-April.
(In reply to sean.marlow@suse.com from comment #12) > Amazon security team is working on a fix which is expected to be released in mid-April. Super, thanks for taking care of this.
The patch has been released: https://github.com/aws/amazon-ssm-agent/commit/0fe8ae99b2ff25649c7b86d3bc05fc037400aca7 Is in the latest version: https://github.com/aws/amazon-ssm-agent/releases/tag/3.1.1208.0
Can you ask upstream if they intend to assign a CVE to this? It's a possible local root escalation. We should also backport the fix to any maintained codestreams of amazon-ssm-agent. I'll ask colleagues from my team to look post information what backports to make.
We'll do a version update instead of a backport.
If they didn't already do this upstream they should also now remove the misleading comment: ``` // This file is created with mode 0666 using os.Create() so needs to be updated to read only with chmod. ``` This should no longer be true.
The comment still exists in code so I pinged AWS security about that and if there will be a CVE to reference.
Thinking some more about this it will not be a local root exploit on many distributions, because /etc/sudoers.d is often hardened to be not world-readable. A quick look around different distributions shows that only Debian Linux has 755 permissions for /etc/sudoers.d and would be affected. We should backport / update with the fix anyway, because creating a world-writable file in there is bad style and a security hazard in any case.
(In reply to Robert Schweikert from comment #16) > We'll do a version update instead of a backport. I have submitted the latest upstream version which includes the fix to Factory now: > https://build.opensuse.org/request/show/970747 Shall I also submit it to SLE? Do we need an ECO for that?
(In reply to adrian.glaubitz@suse.com from comment #20) > I have submitted the latest upstream version which includes the fix to Factory now: Great, thanks! > Shall I also submit it to SLE? Do we need an ECO for that? I consider this important enough to update SLE. An ECO would not be needed, the bug reference is enough. Is there a CVE available yet? Reference the CVE would be important for updating SLE. I'll involve colleagues from reactive security to help with the maintenance process.
I filed a CVE request with Mitre.
(In reply to Marcus Meissner from comment #22) > I filed a CVE request with Mitre. OK, thanks. Let me know once we have a CVE ID, then I'll add it to the changelog.
This is an autogenerated message for OBS integration: This bug (1196556) was mentioned in https://build.opensuse.org/request/show/971130 Factory / amazon-ssm-agent
SUSE-SU-2022:1510-1: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 1196556 CVE References: CVE-2022-29527 JIRA References: Sources used: openSUSE Leap 15.4 (src): amazon-ssm-agent-3.1.1260.0-150000.5.9.2 openSUSE Leap 15.3 (src): amazon-ssm-agent-3.1.1260.0-150000.5.9.2 SUSE Linux Enterprise Module for Public Cloud 15-SP4 (src): amazon-ssm-agent-3.1.1260.0-150000.5.9.2 SUSE Linux Enterprise Module for Public Cloud 15-SP3 (src): amazon-ssm-agent-3.1.1260.0-150000.5.9.2 SUSE Linux Enterprise Module for Public Cloud 15-SP2 (src): amazon-ssm-agent-3.1.1260.0-150000.5.9.2 SUSE Linux Enterprise Module for Public Cloud 15-SP1 (src): amazon-ssm-agent-3.1.1260.0-150000.5.9.2 SUSE Linux Enterprise Module for Public Cloud 15 (src): amazon-ssm-agent-3.1.1260.0-150000.5.9.2 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.
Sean, can you please also provide the fix for SLE-12 as pointed out in comment 29?
Not sure for SLE12. It requires golang >= 1.15.12. Adrian does SLE12 have a sufficient version of golang?
we have go 1.19 even.
Seems good to push the same version to SLE12 then.
SUSE-SU-2022:3654-1: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 1196556 CVE References: CVE-2022-29527 JIRA References: Sources used: SUSE Linux Enterprise Module for Public Cloud 12 (src): amazon-ssm-agent-3.1.1260.0-4.27.2 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.
Released.