Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#55493 closed defect (fixed)

inetutils @1.9.4: telnet exits with abort trap: 6

Reported by: Isles487 Owned by: Schamschula (Marius Schamschula)
Priority: Normal Milestone:
Component: ports Version: 2.4.2
Keywords: Cc:
Port: inetutils

Description

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

Attachments (3)

telnet_2017-12-09-154810.crash (9.8 KB) - added by Isles487 7 years ago.
Crash Log
inetutils-Portfile.patch (960 bytes) - added by jmroot (Joshua Root) 6 years ago.
telnet_telnet.c.patch (1.4 KB) - added by jmroot (Joshua Root) 6 years ago.

Download all attachments as: .zip

Change History (26)

comment:1 Changed 7 years ago by 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!

Changed 7 years ago by Isles487

Crash Log

comment:2 Changed 7 years ago by Isles487

Sure - I added the crash log.

comment:3 Changed 7 years ago by mf2k (Frank Schima)

Owner: set to Schamschula
Status: newassigned

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

comment:4 Changed 7 years ago by 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.

comment:5 Changed 7 years ago by Schamschula (Marius Schamschula)

I have reported this issue upstream.

comment:6 Changed 7 years ago by ptiLuc (Sebastian Becker)

Is there any progress in fixing that in the upstream?

comment:7 Changed 7 years ago by Schamschula (Marius Schamschula)

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

comment:8 Changed 7 years ago by ptiLuc (Sebastian Becker)

Still no news? Telnet is still broken.

comment:9 Changed 7 years ago by 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.

comment:10 Changed 7 years ago by 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.

comment:11 Changed 7 years ago by ptiLuc (Sebastian Becker)

Thank you!

comment:12 Changed 7 years ago by kencu (Ken)

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

comment:13 Changed 7 years ago by ptiLuc (Sebastian Becker)

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

comment:14 Changed 6 years ago by 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.

Version 1, edited 6 years ago by othermark (othermark) (previous) (next) (diff)

comment:15 Changed 6 years ago by Schamschula (Marius Schamschula)

Resolution: fixed
Status: assignedclosed

In 79f402489ffe65c7bd1191bd45af7e3d356a2cfd/macports-ports (master):

inetutils 1.9.4: fix "telnet exits with abort trap"

Closes: #55493

comment:16 Changed 6 years ago by 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.

comment:17 Changed 6 years ago by Schamschula (Marius Schamschula)

Resolution: fixed
Status: closedreopened

Reopening, per Joshua's comment.

comment:18 Changed 6 years ago by 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.

comment:19 Changed 6 years ago by 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.

Changed 6 years ago by jmroot (Joshua Root)

Attachment: inetutils-Portfile.patch added

Changed 6 years ago by jmroot (Joshua Root)

Attachment: telnet_telnet.c.patch added

comment:20 Changed 6 years ago by jmroot (Joshua Root)

Try this instead.

comment:21 Changed 6 years ago by Schamschula (Marius Schamschula)

Resolution: fixed
Status: reopenedclosed

In ae04502c4c7cb1c914df19627764ae78c0b8b4f0/macports-ports (master):

inetutils 1.9.4: use jmroot's telnet patch

Closes: #55493

comment:22 Changed 6 years ago by kencu (Ken)

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

comment:23 in reply to:  22 Changed 6 years ago by 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.

Note: See TracTickets for help on using tickets.