Bug 987483

Summary: [abrt] openssh-server-6.2p2-3.fc19: _IO_vfprintf_internal: Process /usr/sbin/sshd was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Craig A Martin <craig9384>
Component: opensshAssignee: Petr Lautrbach <plautrba>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: mattias.ellert, mdunphy, mgrepl, plautrba, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:c941273b61c307ca39cce796824d4c229d84dd61
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-16 08:10:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Craig A Martin 2013-07-23 13:22:00 UTC 
Version-Release number of selected component:
openssh-server-6.2p2-3.fc19

Additional info:
reporter:       libreport-2.1.5
backtrace_rating: 4
cmdline:        'sshd: [accepted]' '' '' '' ''
crash_function: _IO_vfprintf_internal
executable:     /usr/sbin/sshd
kernel:         3.9.9-302.fc19.x86_64
runlevel:       N 5
uid:            0

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 _IO_vfprintf_internal at vfprintf.c:1635
 #1 ___vfprintf_chk at vfprintf_chk.c:34
 #2 __vsyslog_chk at ../misc/syslog.c:222
 #3 vsyslog at /usr/include/bits/syslog.h:47
 #4 tcpd_diag at diag.c:45
 #5 tcpd_warn at diag.c:55
 #6 sock_hostname at socket.c:277
 #7 eval_hostname at eval.c:77
 #8 host_match at hosts_access.c:378
 #9 list_match at hosts_access.c:211
Comment 1 Craig A Martin 2013-07-23 13:22:15 UTC 
Created attachment 777318 [details]
File: backtrace
Comment 2 Craig A Martin 2013-07-23 13:22:19 UTC 
Created attachment 777319 [details]
File: cgroup
Comment 3 Craig A Martin 2013-07-23 13:22:23 UTC 
Created attachment 777320 [details]
File: core_backtrace
Comment 4 Craig A Martin 2013-07-23 13:22:27 UTC 
Created attachment 777321 [details]
File: dso_list
Comment 5 Craig A Martin 2013-07-23 13:22:32 UTC 
Created attachment 777322 [details]
File: environ
Comment 6 Craig A Martin 2013-07-23 13:22:36 UTC 
Created attachment 777323 [details]
File: limits
Comment 7 Craig A Martin 2013-07-23 13:22:40 UTC 
Created attachment 777324 [details]
File: maps
Comment 8 Craig A Martin 2013-07-23 13:22:45 UTC 
Created attachment 777325 [details]
File: open_fds
Comment 9 Craig A Martin 2013-07-23 13:22:52 UTC 
Created attachment 777326 [details]
File: proc_pid_status
Comment 10 Craig A Martin 2013-07-23 13:23:00 UTC 
Created attachment 777327 [details]
File: var_log_messages
Comment 11 Michael 2013-08-15 23:48:36 UTC 
Hi,
Just got this same crash today, except with openssh-server-6.2p2-5.fc19

I assume it was responding to a shady request. Has someone found a way to drop openssh remotely?!
Comment 12 Michael 2013-08-16 00:50:02 UTC 
So I looked at the coredump, the stacktrace was identical to that described by nvwarr ( https://bugzilla.redhat.com/show_bug.cgi?id=977995#c15 ), even down to being triggered by the same IP from India. So this bug is almost definitely the same as https://bugzilla.redhat.com/show_bug.cgi?id=977995
Comment 13 Craig A Martin 2013-08-16 03:52:18 UTC 
Hi Michael
Thanks for taking an interest.  I agree that the ssh crashes seem to be triggered by external "attacks" over the internet.  Absolutely nothing was running on my system when they occurred and no one I know was trying to log in.  My ssh server is very secure through hosts.deny so no one got in.  My IP address is not visible on the internet so the attacks (a least the first one) are probably random.  I am not sure where attacks that are crashing the ssh server are coming from but one from China keeps trying (178.19.74.218.broad.hz.zj.dynamic.163data.com.cn)
Comment 14 Michael 2013-08-16 04:45:12 UTC 
Hi Craig,
Yes I too am denying ALL:ALL, so no intrusion. Random attempts sounds right, it's just part of the standard scanning for IPv4 services. A segfault in a network service always instils a sense of paranoia as it's hard to know if it's an exploitable problem without some deep digging. It doesn't crash on any request as I can shell in from a whilelisted IP without any issues, so it must be something special about the request being made.
Comment 15 Craig A Martin 2013-08-16 05:05:37 UTC 
Agreed.
Comment 16 Petr Lautrbach 2013-08-16 08:10:31 UTC 
It's the issue of tcp_wrappers library. Please update to the latest https://admin.fedoraproject.org/updates/tcp_wrappers-7.6-75.fc19

*** This bug has been marked as a duplicate of bug 977995 ***