Hi,
I've come across some messages from sshd (OpenSSH 6.7) in my auth.log that
I hadn't noticed before:
sshd[32008]: error: Received disconnect from x.x.x.x: 3: \
com.jcraft.jsch.JSchException: Auth fail [preauth]
I was kinda puzzled why sshd would emit some JCraft[0] messages and the
best explanation I found was this Serverfault[1] answer, quoting a snippet
from packet.c:1965 and adding:
> It looks like openssh server passes through the last message from the
> client in its "Received disconnect" error message, so it appears
that
> this is a zombie login attempt from a botnet that is authored in Java.
So, while this explains the log message, I'm wondering if there are some
security implications in "passing messages from the client through the
server and into the auth.log", i.e. could this be exploited somehow or is
the function handling these strings in packet.c "strong" enough not to
pass through or interpret malign strings?
IOW, has this particular function been audited yet?
Thanks,
Christian.
[0] http://www.jcraft.com/jsch/
[1]
https://serverfault.com/questions/650303/auth-log-indicates-error-with-jschexception/661616#661616
--
BOFH excuse #318:
Your EMAIL is now being delivered by the USPS.
On Wed, 14 Sep 2016, Christian Kujau wrote:> Hi, > > I've come across some messages from sshd (OpenSSH 6.7) in my auth.log that > I hadn't noticed before: > > sshd[32008]: error: Received disconnect from x.x.x.x: 3: \ > com.jcraft.jsch.JSchException: Auth fail [preauth] > > I was kinda puzzled why sshd would emit some JCraft[0] messages and the > best explanation I found was this Serverfault[1] answer, quoting a snippet > from packet.c:1965 and adding:It's logging the reason the client gave for disconnecting.> > It looks like openssh server passes through the last message from the > > client in its "Received disconnect" error message, so it appears that > > this is a zombie login attempt from a botnet that is authored in Java. > > So, while this explains the log message, I'm wondering if there are some > security implications in "passing messages from the client through the > server and into the auth.log", i.e. could this be exploited somehow or is > the function handling these strings in packet.c "strong" enough not to > pass through or interpret malign strings?I'm not seeing a problem here. It's logging a string, and we escape any non-ASCII characters in log.c. If anything it's probably too strict (wrt escaping valid UTF-8 from logs on systems that support it). -d
On Thu, 15 Sep 2016, Damien Miller wrote:> I'm not seeing a problem here. It's logging a string, and we escape any > non-ASCII characters in log.c. If anything it's probably too strict > (wrt escaping valid UTF-8 from logs on systems that support it).Great, thanks for confirming. That's the answer I was hoping for! :-) Thanks for the fast response. Christian. -- BOFH excuse #398: Data for intranet got routed through the extranet and landed on the internet.