You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Thomas Wolf (Jira)" <ji...@apache.org> on 2022/12/14 21:20:00 UTC
[jira] [Commented] (SSHD-1315) Password in clear in SSHD server's logs
[ https://issues.apache.org/jira/browse/SSHD-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647705#comment-17647705 ]
Thomas Wolf commented on SSHD-1315:
-----------------------------------
In the future please report security issues privately. Also if you're not sure it actually is a security issue. See https://www.apache.org/security/ .
But since the cat is already out of the bag:
I can see that this may be problematic. Especially if there is some log collector that keeps logs for posterity. So don't use trace/finest logging level in production, and exclude trace level logging from log collectors if you can.
Apparently nobody thought of this.
Fixing this will need careful analysis of (trace) logging statements. There is more than the one location your example indicates; I already see at least three more.
Obfuscating or blanking out the user names and passwords would require that the buffer logging knows about the internal structure of certain SSH messages. I'd rather not log these buffers at all, or log only a summary like "packet #7: 32... (contains log-in data)". For debugging purposes, one can still see that it is an SSH message code 50, but not what it contains. Other log lines in the vicinity will make it clear what authentication mechanism is used.
> Password in clear in SSHD server's logs
> ---------------------------------------
>
> Key: SSHD-1315
> URL: https://issues.apache.org/jira/browse/SSHD-1315
> Project: MINA SSHD
> Issue Type: Improvement
> Affects Versions: 2.8.0
> Reporter: Roberto Deandrea
> Priority: Minor
>
> Hi Thomas,
> I noticed that setting SLF4J log level {*}org.apache.sshd.*=finest{*}, the password of an SSH client authenticating to SSHD server is logged on SSHD server in "clear".
> This could result in a privacy/security issues at companies with strict security rules.
>
> Evidence of this behavior is in the following trace :
> {color:#242424}[12/14/22 10:05:04:537 CET] 0000014e id=00000000 org.apache.sshd.common.util.logging.LoggingUtils{color}{color:#242424} {color}{color:#242424}3 logMessage decode({*}ServerSessionImpl{*}[null@/172.18.0.1:34845]) packet #7 [chunk #1](53/53) 32 00 00 00 05 70 61 72 74 31 00 00 00 0e 73 73 68 2d 63 6f 6e 6e 65 63 74 69 6f 6e 00 00 00 08 70 61 73 73 77 6f 72 64 00 00 00 00 08 70 61 72 74 6e 65 72 31{color}{color:#242424} {color}{color:#242424}2....{*}part1{*}....ssh-connection....password.....{*}partner1{*}{color}
>
> Questions.
> 1. What do you think about this issue ?
> 2. Did you ever think about obfuscating in some ways "clear passwords" in logs?
> 3. Other considerations ?
>
> Than you for your collaboration.
> Kind Regards
> Roberto Deandrea
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org