#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)
Change History (26)
comment:1 Changed 7 years ago by kencu (Ken)
comment:3 Changed 7 years ago by mf2k (Frank Schima)
Owner: | set to Schamschula |
---|---|
Status: | new → assigned |
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: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: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.
Added the following to Portfile and it works just fine.
configure.optflags -O0 configure.cflags-append -D_FORTIFY_SOURCE=0
comment:15 Changed 6 years ago by Schamschula (Marius Schamschula)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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: | closed → reopened |
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:21 Changed 6 years ago by Schamschula (Marius Schamschula)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:22 follow-up: 23 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 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.
could you please
then copy the relevant crashlog to your Desktop, and then attach it to this ticket?
Thanks!