Hi Richard,
On Donnerstag, 13. März 2025 20:36:21 Mitteleuropäische Normalzeit Richard
Lewis wrote:
> On Sun, 9 Mar 2025, 07:51 Peter Marschall, <pe...@adpm.de> wrote:
> > when running chkrootkit using `chkrootkit-daily` in diff mode, ifpromisc
> > sometimes raised an alert because of its output appears in a different
> > order.
>
> this is why we have the diff mode and the filtering mechanism, to avoid
> this kind of thing.
But diff mode works sensibly if the output is reproducible....
> To avoid those false alerts, it would be good if the output of `ifpromisc`
>
> > would be sorted - at least for the non-EXPERT case.
> >
> > If I saw it correctly in Debian's git repo, this should be a simple change
> > in
> > 'debian/patches/chkrootkit-sniffer.patch':
> >
> > --- a/debian/patches/chkrootkit-sniffer.patch
> > +++ b/debian/patches/chkrootkit-sniffer.patch
> > @@ -48,10 +48,10 @@ index d1d84e4..9f2d0b4 100755
> >
> > - [ "${QUIET}" != "t" ] && ./ifpromisc -v || ./ifpromisc -q
> > + status=0
> > + if [ "${QUIET}" != "t" ]; then
> >
> > -+ outmsg=$(./ifpromisc -v 2>&1)
> > ++ outmsg=$(./ifpromisc 2>&1 | sort)
> >
> > + status=$?
> > + else
> >
> > -+ outmsg=$(./ifpromisc -q 2>&1)
> > ++ outmsg=$(./ifpromisc -q 2>&1 | sort)
> >
> > + status=$?
> > + fi
> > + if [ "$status" = 0 ]; then
>
> i am not sure if this is a good idea.
>
> it's adding "hardcoded" logic that cant be controlled by the user: and if
> there is anything on stderr from ifpromisc then it will be likely be moved
> to the wrong place by sorting which is not helpful (i think this does
> happen if running as non-root, or in an unprivileged container that "sees"
> host interfaces, and potentially if some dubious process is doing bad
> things).
>
> And by default the output *should* be stable anyway: can you give an
> example of the output you are getting?
Unfortunately it doesn't. And ´the reason is that ifpromisc does not reliably
output the network
interfaces it finds in a reproducible ordering.
the "hardcoded" patch as you call it, does exactly that and notrhing else:
It keeps the interfaces that ifpromisc outputs in an alphabetical order.
I.e. if the interfaces stay the same, the sort makes sure their ordering
remains the same and diff
mode then only generates output if contents
of any of the lines differ.
And it avoids false alarms where ifpromisc needlessly changes the ordering.
I tried doing it without having to patch in the 'sort' into chkrootkit's source
using the FILTER
config option.
But as FILTER applies to the whole output of chkrootkit, this is not possible
without hardcoding almost the whole output into the filter script.
And this is neither feasible nor maintainable nor secure.
I also tried to underastand ifpriomisc's source code to perhaps find a simple
patch in ifpromisc's
C code. Unfortunately that's too level (=hard core ;-) for me.
Ans an example here's the relevant part of yesterday's chkroot diff email:
--- [ BEGIN: diff -u /var/log/chkrootkit/log.expected
/var/log/chkrootkit/log.today ] ---
--- /var/log/chkrootkit/log.expected 2025-02-16 07:56:57.219215812 +0100
+++ /var/log/chkrootkit/log.today 2025-03-10 12:37:31.287903279 +0100
@@ -169,8 +165,8 @@
WARNING: Output from ifpromisc:
lo: not promisc and no packet sniffer sockets
lan0: PACKET SNIFFER(/usr/sbin/NetworkManager)
-virbr0: not promisc and no packet sniffer sockets
virbr1: not promisc and no packet sniffer sockets
+virbr0: not promisc and no packet sniffer sockets
Checking `w55808'... not found
Checking `wted'... not found
--- [ END: diff -u /var/log/chkrootkit/log.expected
/var/log/chkrootkit/log.today ] ---
there has not been any hardware chane to this machine, only some reboots.
> i think you are right about the -v. but i assume this is present upstream
> and seems harmless (i not sure -x is ever useful tbh)
Considering the # of Debian-specific patches that chkrootkit carries, I am not
buying this
argument. Sorry.
And working in security myself, I learned [the hard wayn and a long time ago]
that having
confusing statemens in tools (like e.g. parameters that are ignored today, but
may be
interpreted in unforeseen ways tomorrow] will lead to problems.
Best
PEter
--
Peter Marschall
pe...@adpm.de
