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
Many XMLRPC API endpoints are not correctly validating security tokens [CVE-2018-1000226] #1916
Comments
|
Perhaps releasing a version with the XMLRPC API disabled by default would be a good stop-gap solution. |
|
Hi! |
|
CVE-2018-10931 was assigned to this issue. |
|
@cedricbu, I tried to use https://iwantacve.org (The OSS CNA), but it seems they were too slow and @pedrohc managed to get one through Red Hat faster. |
|
@movermeyer Please let OSS CNA know that a CVE has been assigned so we can avoid any duplicates. Thanks. |
|
Actually, it seems that the above CVE is not for the same problem. It is for the inadvertently exposed Further, it only mentions Cobbler 2.6, but the problem affect many more versions than that. The CVE's assignment submissions I made were not for the |
|
The CVE's have now been issued. I've updated the issue titles with the numbers. |
|
Just a heads-up, as this issue is public anyway. Prior to CVE-2018-10931 patch (commit b47081b) it was trivial to completely bypass auth via using the __make_token call. It was possible to use |
Thanks a lot! This heads up is very much appreciated! |
|
Pls note that this should already be fixed by the commit I mentioned that forbids calling all methods with names starting with underscore. |
|
yes, flaw CVE-2018-10931 let unauthenticated attackers get a token, or upload files anywhere (in the context of cobbler daemon, possibly constrained by protections such as SELinux or sandboxes). |
|
As per @ngo 's comment I will close this since it appears to be fixed as far as I understand. Please reopen if I am wrong. |
Looking at Cobbler's XMLRPC API, there are many places where the user supplied security token is not being correctly validated, effectively resulting in authentication being bypassed.
Using some quick-and-dirty AST parse magic, I discovered that there are no fewer than 70 other endpoints that require an security token but don't actually use it!
This means that unauthenticated users are able to perform all sorts of actions that they should not be able to.
Example
For example, the
upload_log_dataendpoint allows users to upload files to the server. As this is a dangerous action, there is a flag in/etc/cobbler/settingsthat must be explicitly enabled before this functionality becomes available:From
/etc/cobbler/settings:However, authenticated users can also change this setting in a running server using the
modify_settingendpoint in the XMLRPC API.modify_setting(self, setting_name, value, token)But the actual implementation of the endpoint never validates the value of the
tokenparameter, so any value works:So it doesn't matter whether the server operator is "ok with this limitation", since unauthenticated users can change the value at any time.
Conclusion
There are many other potentially harmful endpoints in the API, and many more creative ways to exploit them.
The Cobbler XMLRPC API needs to be carefully examined with security in mind to make sure that all of the API endpoints are validating their security tokens correctly.
In the meantime, consider using a firewall to restrict/disable access to the
/cobbler_apiendpoint.See this post for more discussion.
The text was updated successfully, but these errors were encountered: