New Known ipmitool Security Vulnerabilities

[mattvw]

Hello,

Upstream ipmitool recently released a security advisory for "Multiple potential remote code execution vulnerabilities" that were recently found and fixed in ipmitool: GHSA-g659-9qxw-p7cp

It's been found that multiple functions in ipmitool 1.8.18 neglect proper checking of the data received from a remote LAN party, which may lead to buffer overflows and potentially to remote code execution on the ipmitool side. This is especially dangerous if ipmitool is run as a privileged user.

It seems like these are supposed to be fixed in version 1.8.19 but that hasn't been released yet and there doesn't appear to be any ETA on when that might come out. The fixes are available in their master branch though. Red Hat has the list of commits that fix the vulnerabilities listed here: https://bugzilla.redhat.com/show_bug.cgi?id=1798721#c2. The latest ipmitool-xcat appears to be based on ipmitool 1.8.18.

Given the extensive use of ipmitool by xCAT (through ipmitool-xcat) and the fact that it is likely always run as the privileged root user, I think it would be preferred for xCAT to get this fixed in ipmitool-xcat sooner rather than later (potentially even before an official upstream release of ipmitool). Yes, I understand you would need to connect to untrusted IPMI-enabled devices, but it wouldn't be out-of-the-question to have a compromised IPMI-enabled device being used. Still would be good to get fixed ASAP regardless.

Can ipmitool-xcat please be updated to fix these vulnerabilities in ipmitool?

Thank you.

[mattvw]

Hello,

Any updates on this or ETA for when ipmitool-xcat might get updated to fix the security vulnerabilities?

There doesn't seem to be any ETA or plans for a new upstream 1.8.19 release any time soon, so it might be a good idea if these vulnerabilities could be fixed in ipmitool-xcat (backporting the commit fixes from upstream) even before the official upstream release comes out (rather than waiting on an upstream release that may never actually come).

Thank you.

[cxhong]

working on two possible way to update:

1. found the security patch 0012-CVE-2020-5208.patch from https://src.fedoraproject.org/rpms/ipmitool/tree/master, the file lib/ipmi_channel.c failed to patch, looks like the files has more changes then patch.
2. clone the ipmitool repo, git checkout 7ccea28 to create a new tag. then use the build process https://github.com/ipmitool/ipmitool/wiki/Howto-Create-Release-Tar-Bundle to create ipmitool-1.8.18.tar.gz . while try to build new xcat ipmitool, it failed to build first patch 0001-CVE-2011-4339-OpenIPMI.patch

 Patch #1 (0001-CVE-2011-4339-OpenIPMI.patch):
 patching file lib/helper.c
 Hunk #1 FAILED at 829.
 1 out of 1 hunk FAILED -- saving rejects to file lib/helper.c.rej


 RPM build errors:

[whowutwut]

IMHO, I think the 2nd method is the way to go and if you choose that path, the tar file should reflect the git commit ID at the checkout point, so that we know it's not the 1.8.18 release version. For example: ipmitool-1.8.18.7ccea28.tar.gz and not ipmitool-1.8.18.tar.gz

[cxhong]

yes, for the 2nd method, ipmitool-1.8.18.177.g7ccea28.tar.gz is created. the current path files in our xcat-dep/ipmitool may needs to change too

$ ls -ltr *patch
-rw-rw-r-- 1 cxhong cxhong   583 Dec 17 11:35 0001-CVE-2011-4339-OpenIPMI.patch
-rw-rw-r-- 1 cxhong cxhong  3005 Dec 17 11:35 0002-openssl.patch
-rw-rw-r-- 1 cxhong cxhong  7641 Dec 17 11:35 0003-ipmitool-1.8.11-set-kg-key.patch
-rw-rw-r-- 1 cxhong cxhong   452 Dec 17 11:35 0004-slowswid.patch
-rw-rw-r-- 1 cxhong cxhong   564 Dec 17 11:35 0005-sensor-id-length.patch
-rw-rw-r-- 1 cxhong cxhong   781 Dec 17 11:35 0006-enable-usb.patch
-rw-rw-r-- 1 cxhong cxhong  1965 Dec 17 11:35 0007-check-input.patch
-rw-rw-r-- 1 cxhong cxhong   959 Dec 17 11:35 ipmitool-1.8.15-rflash.patch
-rw-rw-r-- 1 cxhong cxhong  1858 Dec 17 11:35 ipmitool-1.8.15-saneretry.patch
-rw-rw-r-- 1 cxhong cxhong  2093 Dec 17 11:35 ipmitool-1.8.15-signal.patch
-rw-rw-r-- 1 cxhong cxhong   592 Dec 17 11:35 ipmitool-1.8.15-solactivate.patch
-rw-rw-r-- 1 cxhong cxhong   884 Dec 17 11:35 ipmitool-1.8.17-rflash.patch
-rw-rw-r-- 1 cxhong cxhong  1547 Dec 17 11:35 ipmitool-1.8.17-saneretry.patch
-rw-rw-r-- 1 cxhong cxhong  5225 Dec 17 11:35 ipmitool-1.8.17-signal.patch
-rw-rw-r-- 1 cxhong cxhong   884 Dec 17 11:35 ipmitool-1.8.18-rflash.patch
-rw-rw-r-- 1 cxhong cxhong  1547 Dec 17 11:35 ipmitool-1.8.18-saneretry.patch
-rw-rw-r-- 1 cxhong cxhong  3725 Dec 17 11:35 ipmitool-1.8.18-signal.patch
-rw-rw-r-- 1 cxhong cxhong   279 Dec 17 11:35 ipmitool-config.h.in.patch
-rw-rw-r-- 1 cxhong cxhong   411 Dec 17 11:35 ipmitool-eventfix.patch
-rw-rw-r-- 1 cxhong cxhong   369 Dec 17 11:35 ipmitool-imbapi.patch
-rw-rw-r-- 1 cxhong cxhong   324 Dec 17 11:35 ipmitool-ipmievd.patch
-rw-rw-r-- 1 cxhong cxhong  2840 Dec 17 11:35 ipmitool-saneretry.patch
-rw-rw-r-- 1 cxhong cxhong  5744 Dec 17 11:35 ipmitool-spdfix.patch

will have to check each patch and re-build if necessary.

[whowutwut]

I think you should focus on the patches that were done for 1.8.18... (rflash/saneretry/signal)

one way to check if anything changed in that path... just extract the 1.8.18 tar to a working area, extract the new tar... then diff the original files that we are making patches to, if they match, then most likely we can just apply the patch.. or make one with similar changes.

I'm not sure how we would go about testing this, i think we would just need to deploy the new package, install it and run flash/console and other things that exercise that path.

[cxhong]

they are three and half years apart between release tar and the new tar, most files are changed. The older patches are no longer works for new tar

[cxhong]

created few new patches based on the new tar since commit 7ccea28, all the patches files are successfully patched, but hit many rpmbuild issues. These may relate to ipmitool source code build on redhat 8. Need to spend more times investigate these.

Because above issue, I used first approach, modified diff results for lib/ipmi_channel.c in the 0012-CVE-2020-5208.patch file and ran bldipmi.pl on redhat 7.7 system.

# ls -ltr /root/rpmbuild/RPMS/ppc64le/
total 1356
-rw-r--r-- 1 root root  335588 Apr 29 15:17 ipmitool-xcat-1.8.18-3.ppc64le.rpm
-rw-r--r-- 1 root root 1048972 Apr 29 15:17 ipmitool-xcat-debuginfo-1.8.18-3.ppc64le.rpm

[cxhong]

Note: make sure yum remove kernel-devel, otherwise, it will failed to run the bldipmi.pl with error likes these:

 In file included from /usr/include/asm/ptrace.h:27:0,
                 from /usr/include/asm/sigcontext.h:11,
                 from /usr/include/bits/sigcontext.h:27,
                 from /usr/include/signal.h:340,
                 from helper.c:47:
/lib/modules/3.10.0-1062.el7.ppc64le/build/include/linux/types.h:15:25: error: conflicting types for 'dev_t'
 typedef __kernel_dev_t  dev_t;
                         ^
In file included from helper.c:39:0:
/usr/include/sys/types.h:60:17: note: previous declaration of 'dev_t' was here
 typedef __dev_t dev_t;
                 ^
In file included from /usr/include/asm/ptrace.h:27:0,
                 from /usr/include/asm/sigcontext.h:11,
                 from /usr/include/bits/sigcontext.h:27,
                 from /usr/include/signal.h:340,
                 from helper.c:47:
/lib/modules/3.10.0-1062.el7.ppc64le/build/include/linux/types.h:19:17: error: conflicting types for 'nlink_t'
 typedef __u32   nlink_t;
                 ^
In file included from helper.c:39:0:
/usr/include/sys/types.h:75:19: note: previous declaration of 'nlink_t' was here
 typedef __nlink_t nlink_t;
                   ^

[cxhong]

it's in the current dev build and will be in the 2.16 xCAT release.