Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Out-of-bounds read in mod_cap getstateflags() function #902

Closed
antonio-morales opened this issue Feb 18, 2020 · 6 comments
Closed

Out-of-bounds read in mod_cap getstateflags() function #902

antonio-morales opened this issue Feb 18, 2020 · 6 comments
Assignees

Comments

@antonio-morales
Copy link

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

@Castaglia Castaglia changed the title Out-of-bound read in getstateflags function Out-of-bounds read in mod_cap getstateflags() function Feb 18, 2020
@Castaglia Castaglia self-assigned this Feb 18, 2020
@Castaglia
Copy link
Member

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 libcap is also questionable. This code was added almost 20 years ago, when Linux capabilities were not very common. Now, most Linux distros provide the necessary libcap library -- or have a package for it. Thus going forward, it would be better if ProFTPD (and mod_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 libcap from the ProFTPD sources, and rely just on the system libcap. For 1.3.6, I will update the bundled libcap version.

Castaglia added a commit that referenced this issue Feb 18, 2020
Castaglia added a commit that referenced this issue Feb 18, 2020
Issue #902: Remove the bundled `libcap` library, and rely only on the
Castaglia added a commit that referenced this issue Feb 18, 2020
Issue #902: Update the bundled `libcap` library to the latest from
@Castaglia
Copy link
Member

Fixed in master, and in the 1.3.6 branch. Thanks!

@Castaglia
Copy link
Member

Looks like this has been given a CVE: https://nvd.nist.gov/vuln/detail/CVE-2020-9272

@pghmcfc
Copy link
Contributor

pghmcfc commented 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
Copy link
Member

@pghmcfc Excellent question. I looked back through libcap commits; it appears that this commit fixed the out-of-bounds read detected by ASAN. I'm not sure which Redhat libcap package version first contained that particular commit, though.

@pghmcfc
Copy link
Contributor

pghmcfc commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants