Re: GNU InetUtils Security Advisory: KRB5 authentication logic inversion in rshd

Collin Funk <[email protected]> writes:

> lucas torres <[email protected]> writes:
>
>> =C2=A0## Timeline=C2=A0 2013-03-28
>> Bug introduced in commit 1054aa73 "Partial adaptions to Kerberos5"
>> 2026-XX-XX Vulnerability discovered and reported 2026-XX-XX Advisory
>> sent to [email protected] 2026-XX-XX Public disclosure
>> (coordinated with maintainers)=C2=A0=C2=A0## Credits=C2=A0Rooting =E2=80=
=94 discovery and
>> advisoryReported to: [email protected]=C2=A0
>
> Please fix your mail client to send mail in a readable format.
>
> What is with the LLM hallucinated "private report" and "public
> disclosure" dates?

More importantly, Inetutils 'rshd' does not and has never supported
Kerberos 5. Using './configure --with-krb5' will cause rshd to be
excluded from the build. Here are the relevant lines from configure.ac:

  krb5)
      [...]
      CPPFLAGS=3D$save_CPPFLAGS
      # We have limited support for krcmd() with Kerberos5.
      # Encryption must be sorted out as a first step.
      IU_DISABLE_TARGET(rcp)
      IU_DISABLE_TARGET(rlogin)
      IU_DISABLE_TARGET(rsh)
      # Likewise, we need to migrate away from KRB4 and des_*()
      IU_DISABLE_TARGET(rlogind)
      IU_DISABLE_TARGET(rshd)

If you were to enable the 'rshd' target, along with the other programs
listed above, you would receive compilation errors.

I am thankful that Inetutils code has had more eyes on it after recent
vulnerabilities. Most of it is 4.4BSD code from decades ago, so there is
certainly more to be found.

However, it feels a bit insulting to receive untested LLM output sent on
mailing lists in hopes of receiving credits on a CVE. It does take
myself and maintainers in general some time to read and check even
simple things.

Collin