Re: Remote Pre-Auth Buffer Overflow in GNU Inetutils telnetd (LINEMODE SLC)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Adiel Sol <[email protected]> writes:

> Hi Collin,
> Thank you for confirming the findings and for the pull request and the
> credit in the NEWS file; we really appreciate it.
> A couple of questions about disclosure:
>
>   1.  Are you planning to request a CVE for this issue (e.g. through
> the GNU project or another CNA), or would you prefer that we request
> it from our side?

GNU is not a CNA, so please assign a CVE if you can do this.  We can
include it in the NEWS entry.

>   2.
> Do you have a rough timeline for when the fix will be released
> (e.g. next release or patch branch), and when you expect to publish
> the CVE or security advisory?

Adiel or Colin, do you want to write a security advisory?  Maybe use the
following for inspiration:

https://lists.gnu.org/archive/html/bug-inetutils/2026-01/msg00004.html

I think we have worked up to a new release, so let's plan that for no
later than April 1st.

>   3.
> What is your preferred process from here until public disclosure
> (e.g. embargo period, coordinated advisory, or anything we should
> avoid doing until a certain date)?

The bug-inetutils is a public list, so this is already public.  I'm not
aware of any need to do anything further except make the release, and if
someone has time, also write an advisory about this.

/Simon

> We are happy to align with your process and timeline.
> Best regards,
> Adiel Sol
> DREAM Security Research Team
>
>
>
>
> ________________________________
> From: Collin Funk <[email protected]>
> Sent: Thursday, March 12, 2026 9:49 AM
> To: Adiel Sol <[email protected]>
> Cc: [email protected] <[email protected]>
> Subject: Re: Remote Pre-Auth Buffer Overflow in GNU Inetutils telnetd
> (LINEMODE SLC)
>
> [You don't often get email from [email protected]. Learn why this
> is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Adiel Sol <[email protected]> writes:
>
>> Proof of Concept
>>
>> 1. Start GNU Inetutils telnetd (e.g. with inetd or run telnetd
>> manually) so it listens on port 23.
>> 2. From another machine, connect to the telnet port and complete the
>> initial handshake. When the server sends DO LINEMODE, reply with
>> WILL LINEMODE so the server enters LINEMODE negotiation.
>> 3. Send a single LINEMODE SLC suboption containing at least 40 to 50
>> triplets, each with a function code greater than 18 (e.g. 19, 20, 21,
>> ... 68). Each triplet is 3 bytes (func, flag, value). Use 0x00 for
>> flag and value. The suboption must be properly framed with IAC SB
>> LINEMODE LM_SLC at the start and IAC SE at the end.
>> 4. The server will call add_slc() for each triplet. After about 35
>> triplets it will write past the end of slcbuf. You should observe a
>> crash, or (if you craft the overflow) memory corruption and possibly
>> code execution.
>
> Thank you for the detailed analysis and reproduction steps. I confirm
> your findings.
>
>> Credit Request
>>
>> We kindly request that the following researchers be credited for
>> this discovery:
>> Adiel Sol, Arad Inbar, Erez Cohen, Nir Somech, Ben Grinberg, Daniel
>> Lubel - DREAM Security Research Team
>> Best regards,
>> =E2=80=82=E2=80=82=E2=80=82=E2=80=82DREAM Security Research Team
>
> I submitted a pull request just now [1], and mentioned you all in the
> NEWS file.
>
> Collin
>
> [1] https://codeberg.org/inetutils/inetutils/pulls/17/files
>

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmmytzwUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA
/iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx
+3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6
qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF
PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh
is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFooLEAP9nCjIVZyqC
Ao/r9I/TVyKI9xapGjyCyg4LjW3IR9OwnAEAhAeWVqNGEqPba+YBzksw+n1ewJOs
WObLgWL89qLU4w4=
=npS1
-----END PGP SIGNATURE-----
--=-=-=--