|Summary:||possible denial of service attack through cron, slocate and rpm|
|Product:||[Retired] Red Hat Linux||Reporter:||Todd Littlefield <tsl>|
|Component:||rpm||Assignee:||Jeff Johnson <jbj>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Mike McLean <mikem>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-06-02 19:59:29 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Todd Littlefield 2003-06-01 00:33:23 UTC
Description of problem: Recently, I was trying to use rpm to find an installed package. The command was never returning... rpm cannot be ctrl-c'ed so I did a ps to get the pid. What I found through the ps was a large number of processes running that should not have been. Basically what appears to have happened is: - a query to the rpm database somehow locked the database and never cleaned up the lock - cron kicked off updates to the rpm /var/log/rpmpkgs file and the slocate database Since these processes are kicked off by cron via /etc/cron.daily there were about 15-20 of them running, as well as their child processes. It is unknown whether the original application that queried the rpm database has exited, crashed, etc. After killing all the processes I could find that I knew dealt with the rpm database, I still cannot do a query. A reboot will need to be performed. This could eventually generate a denial of service attack against the system. If a malicious user knows the default time that rpm/slocate do their updates, locking the rpm database and causing them to hang will stack up the number of processes running. The system could then run out of unique process IDs and swap/memory space. Possible workarounds could be to remove the ability for any but trusted users to run rpm commands. If one of these user accounts is compromised, the problem will still exist. Version-Release number of selected component (if applicable): This was discovered on a RedHat 8.0 systembut will probably exist on RedHat 9 as well as older releases. Most likely this will affect any system that uses rpm to manage packages and has cron scripts to do periodic updates. I cannot give specific versions of rpm/slocate/cron/etc. at this time. I need to perform a reboot in the hopes of fixing the rpm deadlock. How reproducible: Unknown. There is a bit of timing involved. If you can craft a simple application to query the rpm database and exit without releasing the lock it should be easy. Then it is just a matter of time until Steps to Reproduce: These are approximate steps for reproducing the problem... 1. Cause the rpm database to remain in a locked state 2. Run the daily rpm and slocate cron jobs several times and observe them stacking up in the process queue Actual results: System tends to slow down as memory and virtual memory are filled. Subsequent queries against rpm database from command line do not work. up2date will not run as it cannot get a lock on the database. This could present a problem if a critical patch needs to be installed. This in turn will lead to possible root exploits being left open. (cascading effect) Expected results: This should never occur. Additional info: Until solved, it may be necessary to disable the daily rpm and slocate scripts from running.
Comment 1 Bill Nottingham 2003-06-02 03:41:11 UTC
I don't think this is something fixable in slocate itself.