1 |
On Wednesday, 27 February 2019 14:29:40 GMT Rich Freeman wrote: |
2 |
> On Wed, Feb 27, 2019 at 8:47 AM Peter Humphrey <peter@××××××××××××.uk> |
3 |
wrote: |
4 |
> > On Wednesday, 27 February 2019 12:27:59 GMT Mick wrote: |
5 |
> > > Could it be these versions are now launching /run/udev.pid? Is a file |
6 |
> > > /run/ udev.pid present in your system? |
7 |
> > |
8 |
> > Yes, I have such a text file, containing just a PID. |
9 |
> > |
10 |
> > > In any case, the file merely contains the PID number of |
11 |
> > > /lib/systemd/systemd- udevd, rather than an ELF binary and /etc/init.d/ |
12 |
> > > does not contain anything suspicious. However, with armies generating |
13 |
> > > variants of every conceivable malware I don't know if it pays to be a |
14 |
> > > bit |
15 |
> > > paranoid about this. |
16 |
> > |
17 |
> > They really are out to get us... |
18 |
> |
19 |
> If it really looks like a PID file I'd assume that this is a false |
20 |
> positive. |
21 |
|
22 |
Yes. |
23 |
|
24 |
|
25 |
> It would likely be generated by openrc and the init.d script. |
26 |
|
27 |
Yes. |
28 |
|
29 |
|
30 |
> Since almost no other distros use OpenRC it isn't entirely |
31 |
> surprising that a tool like rkhunter wasn't tested using it to catch |
32 |
> the false positive. I'd report the issue to them. |
33 |
|
34 |
Well, if the offending file were a binary the warning would still be valid - |
35 |
so worth investigating anyway. |
36 |
|
37 |
|
38 |
> If by "they" you meant systemd I don't really see how they're actually |
39 |
> involved. Well, other than indirectly by virtue of not creating this |
40 |
> file and being the only config the rkhunter maintainers are probably |
41 |
> using. |
42 |
|
43 |
I think Peter was reinforcing my statement. 'They' know who they are, so |
44 |
better left at that. LOL! |
45 |
|
46 |
|
47 |
> Keep in mind that by its nature rkhunter is going to be a bit limited, |
48 |
> at least when used in this way. If it supports offline scanning (ie |
49 |
> from a rescue disk) then that would be pretty secure, but if it is |
50 |
> running on a potentially-compromised kernel then a clever rootkit |
51 |
> could evade it. Just the usual cat-and-mouse game with these sorts of |
52 |
> things, but rkhunter can only see the filesystem and process tree that |
53 |
> the potentially-compromised kernel lets it see. Offline scanning |
54 |
> tools are always going to be superior in this regard, if you have |
55 |
> known-clean (ideally read-only) boot media, and a clean firmware to |
56 |
> boot it from. Really the cleanest solution would be to remove the |
57 |
> hard drives and scan them on a separate machine. |
58 |
|
59 |
I ran it offline too and investigated the fs and its contents at the same |
60 |
time, but still didn't find anything suspicious. rkhunter often comes up with |
61 |
false positives or issues warnings about innocuous files. It is not some |
62 |
superior diagnostic tool, but nevertheless made me pay attention. Better be |
63 |
safe than sorry with these matters. |
64 |
|
65 |
-- |
66 |
Regards, |
67 |
Mick |