inetutils @1.9.4: telnet exits with abort trap: 6

[Isles487]

Mac OS version: 10.13.1 Xcode 9.1

When either installing the pre-compiled binary or forcing compile with the -s switch, telnet does not work and exits, when given an address, e.g. telnet raspberrypi:

Trying <ip of raspberrypi>...
Connected to raspberrypi
Escape character is '^]'
Abort trap: 6

[kencu (Ken)]

could you please

cd ~/Library/Logs/DiagnosticReports

then copy the relevant crashlog to your Desktop, and then attach it to this ticket?

Thanks!

[Isles487]

Crash Log

[Isles487]

Sure - I added the crash log.

[mf2k (Frank Schima)]

In the future, please Cc the port maintainers (port info --maintainers inetutils).

[kencu (Ken)]

so it aborted due to a detected buffer overflow in the telnet receive function. that sounds like it will be an upstream bug to fix, but we'll see what Marius says.

[Schamschula (Marius Schamschula)]

I have reported this issue upstream.

[ptiLuc (Sebastian Becker)]

Is there any progress in fixing that in the upstream?

[Schamschula (Marius Schamschula)]

No. I haven't heard back from the upstream developers .

[ptiLuc (Sebastian Becker)]

Still no news? Telnet is still broken.

[Schamschula (Marius Schamschula)]

Unfortunately, the bug reporting system is an email address, not a bug tracker. So there is no way of knowing the current status.

[Schamschula (Marius Schamschula)]

I've resent the bug report upstream.

I can reproduce the issue with both El Capitan and High Sierra. lldb gives me the following:

Current executable set to 'telnet' (x86_64).
(lldb) settings set -- target.run-args  "10.0.1.100"
(lldb) run
Process 60267 launched: '/opt/local/bin/telnet' (x86_64)
Trying 10.0.1.100...
Connected to 10.0.1.100.
Escape character is '^]'.
2018-02-01 14:55:40.682975-0600 telnet[60267:10465279] detected buffer overflow
Process 60267 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff5bd8be3e libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff5bd8be3e <+10>: jae    0x7fff5bd8be48            ; <+20>
    0x7fff5bd8be40 <+12>: movq   %rax, %rdi
    0x7fff5bd8be43 <+15>: jmp    0x7fff5bd830b8            ; cerror_nocancel
    0x7fff5bd8be48 <+20>: retq   
Target 0: (telnet) stopped.

[ptiLuc (Sebastian Becker)]

Thank you!

[kencu (Ken)]

I wonder if this could be related to FORTIFY_SOURCE, like this ticket 55204 ...

[ptiLuc (Sebastian Becker)]

I'm not that good in patching within MacPorts. Can somebody try that and give feedback?

[othermark (othermark)]

_FORTIFY_SOURCE=0 still gives the abort trap 6.

What does fix this problem is changing -Os in cflags to -O0. Tested -O2 and -O1 as well, and only -O0 avoids the trap. It's probably a specific optimization that needs disabled, for both this and mawk in ticket 55204. Note it takes both _FORTIFY_SOURCE=0 and -O0 to avoid the trap. Just the telnet bin needs -O0, but the rest of the source also needs _FORTIFY_SOURCE=0.

[Schamschula (Marius Schamschula)]

In 79f402489ffe65c7bd1191bd45af7e3d356a2cfd/macports-ports (master):

inetutils 1.9.4: fix "telnet exits with abort trap"

Closes: #55493

[jmroot (Joshua Root)]

It's a virtual certainty that the buffer overflow is still there, this just moves memory around such that it doesn't trigger an immediate crash. Definitely would not call this fixed in any case.

[Schamschula (Marius Schamschula)]

Reopening, per Joshua's comment.

[jmroot (Joshua Root)]

In the suboption function in telnet.c, a fixed-size buffer is being passed to sprintf. Seems likely it's getting into trouble when the name being printed is too long.

[jmroot (Joshua Root)]

Yeah, the DISPLAY environment variable is typically longer than the 50 characters it allocates. It's possible TERM could be sometimes as well; it's certainly not safe to assume it's set to a sane value anyway.

[jmroot (Joshua Root)]

Try this instead.

[Schamschula (Marius Schamschula)]

In ae04502c4c7cb1c914df19627764ae78c0b8b4f0/macports-ports (master):

inetutils 1.9.4: use jmroot's telnet patch

Closes: #55493

[kencu (Ken)]

Josh -- I'd really love to know how you saw this so quickly as a buffer overflow.

[jmroot (Joshua Root)]

Replying to kencu:

Josh -- I'd really love to know how you saw this so quickly as a buffer overflow.

_FORTIFY_SOURCE=0 turns off bounds checking, and the crash log confirmed that the crash was in __sprintf_chk, i.e. the bounds checking was doing its job.