Re: security/rkhunter without hashes after recent STABLE-13 update

On Wed, Jul 7, 2021 at 12:47 PM Michael Grimm <trashcan@ellael.org> wrote:

> Warner Losh <imp@bsdimp.com> wrote:
> > On Wed, Jul 7, 2021 at 9:26 AM Michael Grimm <trashcan@ellael.org>
> wrote:
> >> Warner Losh <imp@bsdimp.com> wrote:
>
> >>> What's the hash that you have at n246157? I think it should be
> fd5b08977630.
> >>
> >> No, it's stable/13-n246157-fd5b0897763
> >>
> >> I will give a n246188+ user land a try, and ...
> >
> > Great. Please do let me know... I started this for compatibility so I
> > didn't have
> > to keep hacking simple scripts for FreeBSD and if something is screwed up
> > that means it's falling short of the goal...
> >
> >>> So the change is expected, but if the change to all the *sum programs
> is
> >>> incompatible still, I know I'd like to know (as I'm sure se@ would as
> >>> well). All the *sum programs are very new and designed to be 100%
> >>> compatible with the linux versions and if they aren't that needs to be
> >>> fixed.
> >>
> >> … I will report back.
> >
> > Excellent!
>
> I am running stable/13-n246205-9e06b34bb5d, now.
>
> But I do have to report that rkhunter is still lacking to calculate hashes
> when using sha256sum instead of sha256.
>
> In a previous mail you wrote: "I recently added the 'sum' variations".
> Does that mean that sha256sum (et al.) didn't exist before? That could
> explain why rkhunter didn't fail before.
>

Yes. It was merged in commit c0d5665be0 on June 28th.


> Example output:
>
>         KBN> sha256 crontab.mike
>         SHA256 (test.dat) =
> 829f9293639f1a590757bf3eaa369c102b071ef450d3f196e29d5c810f23a2c9
>
>         KBN> sha256sum test.dat
>         829f9293639f1a590757bf3eaa369c102b071ef450d3f196e29d5c810f23a2c9
> test.dat
>
> If I am not mistaken does rkhunter cut that output string into relevant
> junks. In both cases the hash is at different positions, though ...
>

That output looks right to my eye. I see identical output between my ubuntu
VMs and my freebsd box.


>
> > Sorry for any hassle this work is causing.
>
> No big deal for rkhunter, a workaround exists ;-)
>

I think the reason is that it automatically switched to using sha256sum
because it was present, but it didn't automatically change #HASH_FLD_IDX=4
to be 1. The shell script is tricky enough that I've not looked through it
all. I'd argue this is a bug in the get_sha_hash_function which doesn't
adjust the HASH_FLD_IDX based on which version it finds. Instead, it sets
it unconditionally to 4 on *BSD or DragonFly.

Warner

P.S. I think it needs something like the following updated
patch-files_rkhunter and/or changes upstream. I don't know what this port
does, apart from what I've just read. Can you see if this fixes this?