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