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
Comments
|
The bundled libcap in ProFTPD is quite old. The best way to address this issue would be to update that bundled However, the need to even have a bundled Thus for the 1.3.7 releases (and going forward), I will remove the bundled |
Issue #902: Remove the bundled `libcap` library, and rely only on the
Issue #902: Update the bundled `libcap` library to the latest from
|
Fixed in master, and in the 1.3.6 branch. Thanks! |
|
Looks like this has been given a CVE: https://nvd.nist.gov/vuln/detail/CVE-2020-9272 |
|
Hi TJ, |
|
@pghmcfc Excellent question. I looked back through |
|
Well if I find the same commit on kernel.org, it's here: Looking at the tree at that time, we have this: 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. |
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
The text was updated successfully, but these errors were encountered: