Bugzilla – Bug 620781
VUL-0: CVE-2010-2496: STONITH passwords visible in ps output
Last modified: 2021-06-21 08:10:29 UTC
The new stonith-ng code passes the stonith parameters via the commandline - fence_legacy execs the "stonith" binary. This leaks passwords and is considered a security breach, since the power switch passwords can be used to wreak some havoc, and normal users can get access to this. The interface between fence_legacy/stonith needs to be reworked - preferably by the stonith binary also accepting them via environment variables (passing via a temporary file seems error-prone). Or, possibly, calling the library routines directly ...? I would have filed this upstream, but since it is a security issue, prefer that we have a confidential bugzilla report to track it. Dejan, can you please work with Andrew on this?
The SWAMPID for this issue is 34404. This issue was rated as moderate. Please submit fixed packages as soon as possible. Also create a patchinfo file using this link: https://swamp.suse.de/webswamp/wf/34404
I'm not very familiar with stonith-ng and don't know how difficult it would be to switch to library calls, i.e. the way it used to be with the previous stonithd. Of course, we can also modify stonith(8) to get the parameters from the environment. I guess that that'd be the easiest way. Andrew, how would you like to handle this?
(In reply to comment #7) > I'm not very familiar with stonith-ng and don't know how difficult it would be > to switch to library calls, i.e. the way it used to be with the previous > stonithd. > > Of course, we can also modify stonith(8) to get the parameters from the > environment. I guess that that'd be the easiest way. According to lmb it already does. If not, implementing such a feature is probably the best way forward. > Andrew, how would you like to handle this?
(In reply to comment #8) > > Of course, we can also modify stonith(8) to get the parameters from the > > environment. I guess that that'd be the easiest way. > According to lmb it already does. No, I meant to say that it can read them from a file - that is also secure, but creating/deleting a temporary file is not necessarily the easiest way. > If not, implementing such a feature is probably the best way forward. Yes, that'd at least be my suggestion: - Modify stonith binary to accept environment variables (Well, it does so to a limited degree; if they are set, they'll get passed on to the fencing agent, but it'll complain that none were set on the commandline; maybe disabling this is all that is needed for the stonith binary?) - Modify fence_legacy to push them into the environment instead
I requested a CVE number from Josh Bressers at Redhat (who maintains the oss sec CVE pool). If we have final patches I would like to share them with the private security vendor list (or if they are public then already) with the public list.
(In reply to comment #9) > - Modify stonith binary to accept environment variables > (Well, it does so to a limited degree; if they are set, they'll get passed on > to the fencing agent, but it'll complain that none were set on the commandline; > maybe disabling this is all that is needed for the stonith binary?) No, they're not taken from the environment, but I already implemented that part. > - Modify fence_legacy to push them into the environment instead This is easy, apart from the fact that it'd fail miserably if used with the older cluster-glue. I'll add the -V option to stonith to print the version. That can be used then in fence_legacy to find out whether the program can take the configuration from the environment.
(In reply to comment #11) > This is easy, apart from the fact that it'd fail miserably if used with the > older cluster-glue. I'll add the -V option to stonith to print the version. > That can be used then in fence_legacy to find out whether the program can take > the configuration from the environment. Unnecessary, IMHO; can be handled trivially in the package version dependencies.
CVE-2010-2496
The cluster-glue part is ready: changeset: 2417:596a5c4c0df4 user: Dejan Muhamedagic <dejan@hello-penguin.com> date: Thu Jul 08 17:43:13 2010 +0200 summary: Low: stonith: add -V (version) to stonith changeset: 2416:9c6ea6b6bf56 user: Dejan Muhamedagic <dejan@hello-penguin.com> date: Thu Jul 08 16:36:36 2010 +0200 summary: Dev: stonith: update error messages changeset: 2415:b28b89af0aba user: Dejan Muhamedagic <dejan@hello-penguin.com> date: Thu Jul 08 16:25:17 2010 +0200 summary: Medium: stonith: add -E option to get the configuration from the environment The cluster-glue is also released as 1.0.6 upstream. The pacemaker (fence_legacy) fix will be attached. The fix doesn't include version testing. Either add that or do package dependency as Lars suggested.
Created attachment 374969 [details] pacemaker patch
Dejan, thanks. I think both patches look good, the pacemaker patch should be accompanied by a versioned dependency on cluster-glue >= 1.0.6 (or a conflict with < 1.0.6) though to the pacemaker.spec file.
(In reply to comment #16) > Dejan, thanks. I think both patches look good, the pacemaker patch should be > accompanied by a versioned dependency on cluster-glue >= 1.0.6 (or a conflict > with < 1.0.6) though to the pacemaker.spec file. Right, though in that case the user has to take all of the cluster-glue changes up to 1.0.6, not just the changesets quoted above. Perhaps a more appropriate mechanism would be to add something like Provides: stonith-configuration-environment in cluster-glue.spec and then Require that in pacemaker.spec.
(In reply to comment #17) > Provides: stonith-configuration-environment > > in cluster-glue.spec and then Require that in pacemaker.spec. Too complex. If distro packagers want to backport just that one fix, they can do it themselves. Please don't introduce this upstream. Please.
Submitted upstream and fixed internally, queued for maintenance update.
Update released for: cluster-glue, cluster-glue-debuginfo, cluster-glue-debugsource, cmirrord, cmirrord-debuginfo, cmirrord-debugsource, corosync, corosync-debuginfo, corosync-debugsource, drbd, drbd-bash-completion, drbd-debuginfo, drbd-debugsource, drbd-heartbeat, drbd-kmp, drbd-kmp-debug, drbd-kmp-debuginfo, drbd-kmp-debugsource, drbd-kmp-default, drbd-kmp-ec2, drbd-kmp-pae, drbd-kmp-ppc64, drbd-kmp-s390, drbd-kmp-trace, drbd-kmp-vmi, drbd-kmp-xen, drbd-pacemaker, drbd-udev, drbd-utils, drbd-xen, hawk, ldirectord, libcorosync-devel, libcorosync4, libdlm, libdlm-debuginfo, libdlm-debugsource, libdlm-devel, libdlm2, libdlm3, libglue-devel, libglue2, libopenais-devel, libopenais2, libopenais3, libpacemaker-devel, libpacemaker3, ocfs2, ocfs2-debuginfo, ocfs2-debugsource, ocfs2-kmp-debug, ocfs2-kmp-default, ocfs2-kmp-ec2, ocfs2-kmp-kdump, ocfs2-kmp-pae, ocfs2-kmp-ppc64, ocfs2-kmp-s390, ocfs2-kmp-trace, ocfs2-kmp-vmi, ocfs2-kmp-xen, ocfs2-tools, ocfs2-tools-debuginfo, ocfs2-tools-debugsource, ocfs2-tools-devel, ocfs2-tools-o2cb, ocfs2console, openais, openais-debuginfo, openais-debugsource, pacemaker, pacemaker-debuginfo, pacemaker-debugsource, pacemaker-mgmt, pacemaker-mgmt-client, pacemaker-mgmt-debuginfo, pacemaker-mgmt-debugsource, pacemaker-mgmt-devel, release-notes-hae, resource-agents, resource-agents-debuginfo, resource-agents-debugsource, yast2-cluster Products: SLE-DEBUGINFO 11-SP1 (i386, ia64, ppc64, s390x, x86_64) SLE-HAE 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
https://github.com/ClusterLabs/pacemaker/commit/7901f43c5800374d41ae2287fe122692fe045664 main fix: https://github.com/ClusterLabs/cluster-glue/commit/3d7b464439ee0271da76e0ee9480f3dc14005879 mitre desc stonith-ng in pacemaker and cluster-glue passed passwords as commandline parameters, making it possible for local attackers to gain access to passwords of the HA stack and potentially influence its operations. This is fixed in cluster-glue 1.0.6 and newer, and pacemaker 1.1.3 and newer.