stopped processes using cpu?

[Nathan Dautenhahn]

On Wed, Aug 20, 2014 at 01:52:41PM -0700, Dieter BSD wrote:
> >  whether or not the existing code is good or bad
> 
> It has been awhile since I've looked at the code for firefox, but
> that code was OBSCENELY bad.  :-(  I fixed hundreds and hundreds and
> hundreds of bugs (yes, that many!) and it still didn't work (at all).
> The firefox idiots didn't believe my bug report.
> 
> Code quality of top/ps/kernel?  Look at the code and/or see how many
> open PRs there are.
> 
> Firefox runs in a chroot, executables in a read-only partition.
> /etc/profile has
>   ulimit -S -m 400000
>   ulimit -S -v 600000
> after an incident where an "idle" firefox grew without bound kicking
> everything else out of memory including a small program running at rtprio
> logging true real-time data resulting in the loss of data. (the data buffer
> was mlocked, but the code wasn't.  Silly me thinking that the kernel
> wouldn't page out a small loop that is constantly running.)
> Firefox is usually stopped when not being actively used.  No plugins.
> 
> Other web browsers (smaller, faster, more secure, less buggy, ...)
> are used whenever possible.
> 
> Rootkit?  Perhaps possible in theory, but very highly unlikely.

I concur. I have been doing a lot of rootkit research lately, which bends the
mind that direction: if I wanted to hide a process that is doing nefarious
things it seems like Firefox, given the evidence you just mentioned, would be
ideal.

I won't lie though, I am not expertized enough to know how to really bite into
this and figure it out. 

> 
> CPU% decays as expected when processes are stopped (except for firefox).
> Firefox CPU% does not decay as expected, either running or stopped.  I tried
> running a cpu-bound process in the same chroot as firefox, it decayed as
> expected when stopped.
> 
> So firefox seems to be the only thing that this shows up on.  And also seems
> to be the only thing with THR > 1.  So try the -H option:
> 
>   PID    UID   PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND 92986
>   941    54    0   167M 63524K STOP     0:00  5.03% {firefox-bin} 92986
>   941     4    0   167M 63524K STOP     0:25  0.00% {initial thread} 92986
>   941    44    0   167M 63524K STOP     0:01  0.00% {firefox-bin} 92986
>   941    44    0   167M 63524K STOP     0:00  0.00% {firefox-bin} 92986
>   941    44    0   167M 63524K STOP     0:00  0.00% {firefox-bin} 92986
>   941    44    0   167M 63524K STOP     0:00  0.00% {firefox-bin} 92986
>   941    44    0   167M 63524K STOP     0:00  0.00% {firefox-bin} 33796
>   941    44    0  5248K  1200K ttyin    0:00  0.00% bash 92986    941    44
>   0   167M 63524K STOP     0:00  0.00% {firefox-bin} 92986    941    44    0
>   167M 63524K STOP     0:00  0.00% {firefox-bin} 92979    941    48    0
>   6184K   632K STOP     0:00  0.00% sh 92983    941    62    0  6208K   660K
>   STOP     0:00  0.00% sh 92978    941    44    0  8296K  1372K STOP     0:00
>   0.00% sh
> 
>   PID    UID   PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND 44188
>   937     4    0   303M   187M STOP   104:11 12.65% {initial thread} 44188
>   937    44    0   303M   187M STOP     0:45  0.49% {firefox-bin} 44188
>   937    44    0   303M   187M STOP     8:19  0.29% {firefox-bin} 44188
>   937    44    0   303M   187M STOP     0:02  0.00% {firefox-bin} 44188
>   937    44    0   303M   187M STOP     0:01  0.00% {firefox-bin} 44188
>   937    44    0   303M   187M STOP     0:01  0.00% {firefox-bin} 44188
>   937    44    0   303M   187M STOP     0:00  0.00% {firefox-bin} 44188
>   937    44    0   303M   187M STOP     0:00  0.00% {firefox-bin} 44167
>   937    44    0  5248K   804K ttyin    0:00  0.00% bash 44181    937    76
>   0  6184K   632K STOP     0:00  0.00% sh 44185    937    76    0  6208K
>   664K STOP     0:00  0.00% sh 44188    937    60    0   303M   187M STOP
>   0:00  0.00% {firefox-bin}
> 
> Any clues there?  

Not that I can see. From what I know, if you are entertaining the possibility
it's a rootkit, the only direction would be to write a different utility that
printed out data on the various process lists in the kernel. You could use this
to see if any of the state isn't matching. 

Sorry for not having more detailed ideas/evidence to go upon.

Best,
::nathan::

>_______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe,
> send any mail to "freebsd-hackers-unsubscribe at freebsd.org"