Repository navigation
Out-of-bounds read in mod_cap getstateflags() function #902
Description
This vulnerability was previously reported via email to security@proftpd.org and has been made public after the fix has been developed.
Credit
This issue was discovered and reported by GitHub Security Lab team member @antonio-morales (Antonio Morales).
Summary:
An out-of-bounds (OOB) read vulnerability has been detected in mod_cap.
Description:
The "cap_to_text()" function on "cap_text.c" does a call to getstateflags(caps, n) [line 255].
When getstateflags(cap_t caps, int capno) is called, "capno" is equal to 37 so "isset_cap((__cap_s *)(&caps->set.inheritable),capno)" will be expanded to "&((__cap_s *)(&caps->set.inheritable))->_blk[(37)>>5]", accesing caps->set.ineritable[1] that is outside of "caps" struct bounds (0x603000001ae4 to 0x603000001af7 in our example) [Image1.png]
As a result, OOB reads occurs resulting in accessing a memory location that is outside of the boundaries of the caps struct variable.
This bug doesn't affect neither "set.effective" nor "set.permited". This is because in these cases "permited" and "inheritable" members are located just after them [Image2.png]
Please let me know when you have fixed the bugs so that I can coordinate my disclosure with yours. For reference, here is a link to GitHub's vulnerability disclosure policy: https://securitylab.github.com/disclosures#policy
Thank you,
Antonio Morales
GitHub Security Lab Team
Activity
[-]Out-of-bound read in getstateflags function[/-][+]Out-of-bounds read in mod_cap getstateflags() function[/+]Castaglia commentedon Feb 18, 2020
The bundled libcap in ProFTPD is quite old. The best way to address this issue would be to update that bundled
libcap.However, the need to even have a bundled
libcapis also questionable. This code was added almost 20 years ago, when Linux capabilities were not very common. Now, most Linux distros provide the necessarylibcaplibrary -- or have a package for it. Thus going forward, it would be better if ProFTPD (andmod_cap) simply used the distribution-provided libraries, rather than providing our own.Thus for the 1.3.7 releases (and going forward), I will remove the bundled
libcapfrom the ProFTPD sources, and rely just on the systemlibcap. For 1.3.6, I will update the bundledlibcapversion.Issue #902: Remove the bundled `libcap` library, and rely only on the
Issue #902: Update the bundled `libcap` library to the latest from
Merge pull request #905 from proftpd/cap-system-libs-only-issue902
Update NEWS, release notes for fixes for Issue #902.
Merge pull request #906 from proftpd/cap-updated-libcap-issue902
Updating NEWS, release notes for fix for Issue #902.
Castaglia commentedon Feb 18, 2020
Fixed in master, and in the 1.3.6 branch. Thanks!
Castaglia commentedon Feb 20, 2020
Looks like this has been given a CVE: https://nvd.nist.gov/vuln/detail/CVE-2020-9272
pghmcfc commentedon Feb 21, 2020
Hi TJ,
the packages I build for Fedora/EPEL etc. have always used the system version of libcap rather than the bundled version. Is there a minimum version of libcap that is needed to not be vulnerable to this issue, or is it more complicated than that?
Castaglia commentedon Feb 21, 2020
@pghmcfc Excellent question. I looked back through
libcapcommits; it appears that this commit fixed the out-of-bounds read detected by ASAN. I'm not sure which Redhatlibcappackage version first contained that particular commit, though.pghmcfc commentedon Feb 21, 2020
Well if I find the same commit on kernel.org, it's here:
https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=ea4e5f8e08bf8af459378dac24d42fdbbcdb2e73
Looking at the tree at that time, we have this:
https://git.kernel.org/pub/scm/libs/libcap/libcap.git/tree/?id=ea4e5f8e08bf8af459378dac24d42fdbbcdb2e73
Looking at the CHANGELOG file there, we see that the commit landed some time after libcap 1.10.
Since all of the distributions I'm interested in (RHEL/CentOS 6 onwards) have libcap 2.x, it would appear that they're not vulnerable to this issue.