# Unexpected cron output - could it be a system compromise?

## tonip

I'm running 2.6.12-gentoo-r10 behind an IPCop box which serves as a router/firewall (IPCop 1.4.13). Early this morning I found some very suspicious output emailed to the root account from cron - this has never happened before and I certainly didn't (knowingly) set up any such cron job. Also, I can't find anything in the /etc/cron* directories or /etc/crontab that would have set this off:

```
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

  0  113k    0  1134    0     0   1742      0  0:01:06 --:--:--  0:01:06  1742

 63  113k   63 73934    0     0  41560      0  0:00:02  0:00:01  0:00:01 64539

100  113k  100  113k    0     0  59096      0  0:00:01  0:00:01 --:--:-- 87364

Done.
```

I'm not familiar with whatever command would have produced this output so did some searching and it looks to me like it comes from a curl command (can anyone confirm if that's right?). This has freaked me out a bit - now I'm concerned my box has been compromised. I ran chkrootkit and it didn't seem to throw up anything obvious but I don't fully understand all the output. The only warning-type message it printed was the following:

```
Checking `chkutmp'...  The tty of the following user process(es) were not found

 in /var/run/utmp !

! RUID          PID TTY    CMD

! root         6648 tty7   /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-ISMxJA

! tprice       8384 pts/0  /bin/bash

! tprice       8386 pts/1  /bin/bash

! tprice       8392 pts/2  /bin/bash

! tprice       8399 pts/3  /bin/bash

! tprice       8411 pts/4  /bin/bash

! tprice       8434 pts/5  /bin/bash

! tprice       8444 pts/6  /bin/bash

! tprice       8453 pts/7  /bin/bash

! tprice       8458 pts/8  /bin/bash

! tprice       8460 pts/9  /bin/bash

! tprice       8479 pts/11 /bin/bash

! tprice      14648 pts/10 /bin/bash

! root          610 pts/7  /bin/sh /usr/sbin/chkrootkit

! root         1626 pts/7  /usr/sbin/chkutmp

! root         1627 pts/7  ps ax -o tty,pid,ruser,args

chkutmp: nothing deleted
```

Nothing there looks unexpected to me but I'm not totally sure. (I could post the whole output if it would be useful.)

I can't see anything obvious in the IPCop firewall logs and 'ps faux' doesn't show up anything that looks suspicious to me, though I don't really know enough to tell. Can anyone give me some advice on how to figure out what caused that cron job to run?

Thanks ...

Toni

----------

## dleverton

Yeah, this startled me too a while back, but it's almost certainly caused by the sys-apps/pciutils package updating the PCI IDs database.  It would have been nice if there was some explanatory output, but...  :Confused: 

Anyway, you can turn it off by commenting out the exec line in /etc/cron.monthly/update-pciids.  Don't delete the file, because if you do it'll come back next time you update pciutils, whereas if you comment it, config protection will stop it from surprising you again.

----------

## tonip

Yep, that seems to be it (datestamp on /usr/share/misc/pci.ids matches the time of the cron job and it would have used curl).

Thanks, at least now I don't need to worry!

Toni

----------

## orionbelt

It's been bugging me for months, as well. On the 1st of every month, to be more specific: It turns out it's caused by /usr/sbin/update-pciids which gets executed from inside your cron.monthly, as dleverton said above...

I just found out that i can disable the annoying message by modifying the line:

```
if ! $DL ; then
```

into:

```
if ! $DL >&/dev/null ; then
```

However, i would be much happier if Gentoo devs made the change --is the curl output of any use?

Edit: A better solution might be to leave the above line as-is and instead modify the line:

```
   DL="curl -o $DEST.new $SRC"
```

into:

```
   DL="curl -o $DEST.new $SRC --stderr /dev/null"
```

The advantage is that, if wget or lynx are used instead of curl, the stderr output *will* be emailed.

----------

## drak

A better solution is to not remove all errors and instead silence the verbosity of curl.

change the following in /usr/sbin/update-pciids, I have submitted a bug report for this 182439

```

   DL="curl -o $DEST.new $SRC"

```

to 

```

   DL="curl -s -o $DEST.new $SRC"

```

The advantage is that, the stderr output *will* be emailed, and the verbosity of curl is removed so you do not see what happened during the download of the file.

----------

