ktorrent vulnerable?
Michael Schwendt
mschwendt at gmail.com
Mon Jul 23 11:11:18 UTC 2012
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?
More information about the test
mailing list