# Might have been "rooted", need help

## SweepingOar

I run a one user server and only use the root account once in a week. The only ports that are open afaik are 80, 443, 25, and a high alternate ssh port so I can login. I haven't done any system updates in a looong time (I think I'm running Gentoo 2009 or so). The newest kernel listed in /boot is "kernel-2.6.26-gentoo-r4".

I look at /tmp every few weeks to see if there's anything weird in there and today I noticed the following file:

```
-rw-r--r-- 1 root   root        32 Aug 29 03:45 tmpZgzVbZ
```

which just seems to have the date in it:

```
$ more /tmp/tmpZgzVbZ 

Thu, 29 Aug 2010 10:45:01 +0000
```

I don't remember creating that by accident and I wouldn't have done it intentionally. I occasionally run the date command to reset the system clock so I'm hoping this was somehow related to that, but I've got no idea. This is a live server with users and I'm going to have to take it down to reinstall if it's even possible that someone else is connecting to the machine. Any advice would be appreciated. Thanks.

----------

## krinn

try, more ~/.bash_history  or emerge chkrootkit

your kernel have the fstack-protector bug, so anyone with a user access can get root privilege, time to update

----------

## tomk

 *SweepingOar wrote:*   

> I look at /tmp every few weeks to see if there's anything weird in there and today I noticed the following file:
> 
> ```
> -rw-r--r-- 1 root   root        32 Aug 29 03:45 tmpZgzVbZ
> ```
> ...

 

That filename looks like it came from a call to mkstemp() or TemporaryFile() from Python's tempfile module which leads me to think that it came from Portage. Digging though the code there is some code that's called from 'emerge -sync' that will add the contents of the remote server's /metadata/timestamp.chk to a temprary file that would be called /tmp/tmpXXXXXX, where XXXXXX are some random letters and would contain a timestamp in that format.

I'd say that the most likely explanation is that this was a temporary file from an 'emerge --sync' command that was killed, but if I were you I'd run chkrootkit as krinn suggested to be on the safe side.

----------

## SweepingOar

Thanks for the replies. I do have Python installed. Do you have any advice on where to look to see if an emerge sync was killed? I looked in emerge log for that day and only found this:

```
1282212604: Started emerge on: Aug 29, 2010 03:10:04

1282212604:  *** emerge --quiet sync

1282212604:  === sync

1282212605: >>> Starting rsync with rsync://128.10.252.13/gentoo-portage

1282212631: >>> Starting retry 1 of 3 with rsync://141.219.155.230/gentoo-portage

1282212815: === Sync completed with rsync://141.219.155.230/gentoo-portage

1282212818:  *** terminating.
```

While emerging chkrootkit there was the following warning:

```
!!! Your current profile is deprecated and not supported anymore.

!!! Please upgrade to the following profile if possible:

        default/linux/x86/10.0
```

But I ran it anyway and it came up with nothing. It gave me "not tested" for syslog-ng or whatever that's called and the suspicious file check came up with these:

```
/usr/lib/locale/.keep_sys-libs_glibc-2.2

/usr/lib/.keep

/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/Sys/Syslog/.packlist

/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/Locale/gettext/.packlist

/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/RPC/PlServer/.packlist

/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/DBD/mysql/.packlist

/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/Storable/.packlist

/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/Net/Daemon/.packlist

/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/Test/Harness/.packlist

/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/Pod/Parser/.packlist

/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/DBI/.packlist

/usr/lib/perl5/site_perl/5.8.8/i686-linux/auto/TimeDate/.packlist

/usr/lib/perl5/site_perl/5.8.8/i686-linux/auto/MIME/Lite/.packlist

/usr/lib/perl5/site_perl/5.8.8/i686-linux/auto/MIME/Types/.packlist

/usr/lib/perl5/site_perl/5.8.8/i686-linux/auto/Test/Pod/.packlist

/usr/lib/perl5/site_perl/5.8.8/i686-linux/auto/Email/Date/Format/.packlist

/usr/lib/perl5/site_perl/5.8.8/i686-linux/auto/Pod/Escapes/.packlist

/usr/lib/perl5/site_perl/5.8.8/i686-linux/auto/Pod/Simple/.packlist

/usr/lib/perl5/site_perl/5.8.8/i686-linux/auto/Image/Magick/.packlist

/usr/lib/perl5/site_perl/5.8.8/i686-linux/auto/Mail/.packlist

/usr/lib/perl5/5.8.8/i686-linux/.packlist

/usr/lib/perl5/5.8.8/i686-linux/auto/Net/.packlist

/lib/udev/state/.keep_sys-fs_udev-0

/lib/udev/devices/.keep_sys-fs_udev-0

/lib/rcscripts/sh/.keep

/lib/rcscripts/awk/.keep

/lib/rcscripts/net/.keep

/lib/rcscripts/.keep
```

----------

## krinn

 *SweepingOar wrote:*   

> 
> 
> ```
> 1250676603: Started emerge on: Aug 29, 2009 03:10:03
> 
> ...

 

nearly good for the hour, just 1 year too old  :Smile: 

i forgot kernel link: https://forums.gentoo.org/viewtopic-t-840757-highlight-.html

----------

## SweepingOar

Whoops. Thanks! I edited the message above, but it's pretty much the same, but with one retry:

```
1282212631: >>> Starting retry 1 of 3 with rsync://141.219.155.230/gentoo-portage
```

The retries don't seem to cause the file in /tmp though because it seems that there are retries in most of the emerge.log entries. I looked at that link earlier, but my kernel is quite a bit older than what is being talked about there. I will upgrade asap, but I'd like to wait until the stable kernel is patched and then just rebuild the system from scratch, since I'm a bit of a novice when it comes to upgrading the kernel. Since I'm the only user, someone would probably have to become apache to escalate. I know that can happen if there are weaknesses in web code, but hopefully there aren't such holes in any of the sites I'm hosting.

----------

