I admit this is speculative and I could not find anything elsewhere. Two days ago, I checked somebody's torrent box running updated F17 with ktorrent and nothing else. Firewall settings were OK /usr was writable by user.
Please check.
Best
A. Mani
On Sun, 22 Jul 2012 21:02:46 +0530, A. Mani wrote:
I admit this is speculative and I could not find anything elsewhere. Two days ago, I checked somebody's torrent box running updated F17 with ktorrent and nothing else. Firewall settings were OK /usr was writable by user.
Please check.
Did the user run ktorrent as "root"? Also, did you keep a copy of the full "stat /usr" output? If not, why not?
On 7/22/12, Michael Schwendt mschwendt@gmail.com wrote:
Did the user run ktorrent as "root"?
No
encryption, scripts were enabled in ktorrent.
Also, did you keep a copy of the full "stat /usr" output? If not, why not?
(I did not have enough time to check much)
modify to /usr was on 19th July 3:00 hrs ( +5:30) change was same Access was 2 hours later.
ls -idZ output looked like
drwxrwxrwx. root root system_u:object_r:bin_t:s0 /usr/bin drwxrwxrwx. root root system_u:object_r:usr_t:s0 /usr/ drwxrwxrwx. root root system_u:object_r:usr_t:s0 /usr/share dr-xr-xr-x. root root system_u:object_r:bin_t:s0 /usr/sbin lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /sbin -> usr/sbin
But /var was not writable by user.
Best
A. Mani
On Mon, 23 Jul 2012 03:50:59 +0530, A. Mani wrote:
Did the user run ktorrent as "root"?
No
As a quick thought, then it would need another vulnerability outside ktorrent to elevate user privileges. Plus the corresponding exploit.
encryption, scripts were enabled in ktorrent.
Also, did you keep a copy of the full "stat /usr" output? If not, why not?
(I did not have enough time to check much)
Uh, come on. You would use "stat" instead of "ls". ls -idZ output is not helpful.
modify to /usr was on 19th July 3:00 hrs ( +5:30) change was same Access was 2 hours later.
ls -idZ output looked like
drwxrwxrwx. root root system_u:object_r:bin_t:s0 /usr/bin drwxrwxrwx. root root system_u:object_r:usr_t:s0 /usr/ drwxrwxrwx. root root system_u:object_r:usr_t:s0 /usr/share dr-xr-xr-x. root root system_u:object_r:bin_t:s0 /usr/sbin lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /sbin -> usr/sbin
That's more strange than suspicious.
It's kind of stupid to touch multiple dirs, when it's entirely sufficient to modify a single one. You can make /usr/bin world-writable and store files in it without making /usr world-writable. And if /usr is made world-writable, you could create subdirs in it with no need to consider /usr/share.
I've seen file permissions like that as a result of accidents when playing with chmod or bad "make install" scripts.
But /var was not writable by user.
And /usr/sbin (and likely others) not either.
Have you searched for any modified or hidden files yet?
On Mon, Jul 23, 2012 at 4:41 PM, Michael Schwendt mschwendt@gmail.com wrote:
drwxrwxrwx. root root system_u:object_r:bin_t:s0 /usr/bin drwxrwxrwx. root root system_u:object_r:usr_t:s0 /usr/ drwxrwxrwx. root root system_u:object_r:usr_t:s0 /usr/share dr-xr-xr-x. root root system_u:object_r:bin_t:s0 /usr/sbin lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /sbin -> usr/sbin
That's more strange than suspicious.
+1
I've seen file permissions like that as a result of accidents when playing with chmod or bad "make install" scripts.
Very possible.
Have you searched for any modified or hidden files yet?
I forgot to mention that rkhunter has been run on the system periodically. Found nothing hidden or suspicious. Only ifup and ifdown showed a warning, but that is due to rkhunter.
The ktorrent logs etc in .kde have nothing interesting too.
It does seem that all of it is due to the user's actions.
Best
A. Mani