Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891768 Michael Scherer <misc@xxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |misc@xxxxxxxx --- Comment #2 from Michael Scherer <misc@xxxxxxxx> --- I have some concerns : * There is 3 scripts, and 1 is just a exec "$@" without anything, and the 2nd one is just ruby "$@". I guess that's a system to integrate scl into origin without using some configuration ? Wouldn't it be better to directly link those to bash and ruby instead of starting a process and a fork ? At least, a comment in the script would help. ( but that's not blocking ). * Also, there is some missing deps for the 3rd script ( oo-diagnotics ). I see it use : - bind-utils ( command host ) - rubygems ( command gem, but maybe that's now part of ruby, not sure about this ) Technically, i think there is also missing requires for ruby module for json ( ie rubygems-json ) and rest_client ( rubygems-rest-client ). However, as the script first check if this is a broker, then I guess no error can happen in practice, so I think this can be safely skipped. That's blocking. * the changelog is empty for : * Wed Nov 21 2012 Dan McPherson <dmcphers@xxxxxxxxxx> 1.0.3-1 - while I guess that not a issue, it would be nice to just fill it :) * test_broker_httpd_error_log and test_node_mco_log are insecure, as they use file in /tmp/. While this is not a easy predictable name ( as upstream used $$ ), that's still predictable during a very short period of time ( ie, between the moment the script is run and after the script start to use sed and grep redirected to the file ). And there is no check to see if the file already exist or anything like that. So it could be quite easily created in advance with a simple for loop, or if the script was run in some automatic fashion ( like nagios ), someone could create a file /tmp/oodiag-mco-1234 by getting the process id at the right moment. Usually, attackers tend to brute force by running the script often enough to catch it at the right moment, I do not see how this would be done in practice in this case. Then, once you have the file name, you can do multiple fun things ( for some value of fun ) : - 1) create a link to another file ( the script run as root, so it can overwrite almost anything, I am sure the system would not work as well with sorted error log in pam config file ) - 2) create a file with cooked error message to trigger a error for the script without them being real ( and using chattr +i on the file so the file redirection would silently fail ). I guess in a very specific totally invented scenario, this could be used to inject error message ( and that could be bad if that's show in a web page or anything ). Definitely nothing serious or dangerous that would happen on a properly managed system ( due to kernel protection, etc ) but IMHO, something that could and should be corrected one day. I didn't fill a more formal bug as the package is not yet in Fedora, so no need for a CVE. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=OFPxKFKzE8&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review