[
https://issues.apache.org/jira/browse/SSHD-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194519#comment-16194519
]
Goldstein Lyor commented on SSHD-775:
-------------------------------------
Thanks for the elaborate research - it is a good source of information. Let me
comment on some issues I found interesting
{quote}
Human readable description of the error.
{quote}
So the "leak" you describe falls well within this specification. Furthermore
after reading [SFTP draft 13 - 5.5 Security
considerations|https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#section-13]
I find the following text represents my approach to this issue:
{quote}
It is assumed that both ends of the connection have been authenticated and that
the connection has privacy and integrity features. Such security issues are
left to the underlying transport protocol, except to note that if this is not
the case, an attacker may be able to manipulate files on the server and thus
wholly compromise the server
{quote}
In other words, if you have hacked SSH and are able to access SFTP, then a
little thing such as "leak" of file names is the least of your concerns. In
this context, I have re-read the sections you specified and found no wording
that prohibits or even recommends avoiding a "leak" such as the one you
describe.
{quote}
Inline with OpenSSH.
{quote}
Yes, but not a copy of it - when I mention "inline with OpenSSH" I only mean as
far as protocols and/or features - this (IMO) is neither. I wonder if the
writers of the code did not do what we do in Java because it was too
complicated to provide the file path - had they had this chance perhaps they
would have done so as well. Therefore, it might be that what drove their choice
was not security but rather convenience. Furthermore,
{quote}
it appears that OpenSSH only returns a small set of error messages
{quote}
I am not sure it is a good thing...
{quote}
For example the NoSuchFileException has a reference to the file which could not
be found, but the client already knowns which file because it initiated the
request.
{quote}
I do not see the harm or "leak" if the server echoes a parameter that the
client has already provided and is aware of it.
{quote}
The SFTPException can be a problem. For example see SftpSubSystem::doRemove():
throw new SftpException(SftpConstants.SSH_FX_FILE_IS_A_DIRECTORY, p.toString()
+ " is a folder"); If this is the case the client will receive a "Failure".
However the client also received the substatus SSH_FX_FILE_IS_A_DIRECTORY....
{quote}
Again, I do not see the harm/"leak" here.
{quote}
Does not make the client smarter then needed.
{quote}
I don't see how this "leak" makes the client smarter or how the "leak" can be
used to access locations it shouldn't - remember that {quote}
Obscurity is not security
{quote}
i.e., in this context - the fact that the response "leaks" the fact that there
is a folder called {{/some/path/to/some/folder}} is neither here nor there -
the attacker may have gleaned this information from (many) other sources. The
important thing is that SFTP does not allow the user to step out of the
"sandbox" it was assigned after login. In addition to this (and the previous
issue), perhaps by providing more exact sub-status codes (e.g.,
{{SSH_FX_FILE_IS_A_DIRECTORY}}) the client can take more informed actions to
address the error rather than simply failing.
That being said, I recommend a 3rd option:
Introduce an {{SftpErrorMessageHandler}} that is used by the {{SftpSubsystem}}
code to format error messages it generates. The user may "inject" the handler
as part of the {{SfpSubsystemFactory}} setup when the SSHD server is
initialized and thus control the string(s) to his/her heart's content (note
that this can be already done with the current code, just not as easily as such
a dedicated handler would allow). The default handler will be one that
generates "redacted" forms of messages - much along the lines of {{OpenSSH}}.
However, we will also provide a more "verbose" formatter that "leaks" the
current information - which personally I find very useful and much more in line
with what I see as the spirit of
{quote}
Human readable description of the error.
{quote}
> SftpSubSystem::sendStatus leaks Exception information
> -----------------------------------------------------
>
> Key: SSHD-775
> URL: https://issues.apache.org/jira/browse/SSHD-775
> Project: MINA SSHD
> Issue Type: Improvement
> Affects Versions: 1.6.0
> Reporter: Mark Ebbers
> Priority: Minor
> Labels: security
>
> I'm using SSHD-core 1.6.0 in my own Sftp server implementation and make use
> of the rooted file-system. Now did I notice that a client did try to rename a
> file, which was no longer available, and got a response with the substatus
> SSH_FX_NO_SUCH_FILE and the message ' Internal NoSuchFileException:
> /srv/sftp/chroot/11738/file.txt'.
> As a client I now know the following two things:
> * The full path on the file-system.
> * The server was written in Java. (NoSuchFileException)
> I noticed that the SftpSubsystem.sendStatus(Buffer, int, Throwable) uses the
> SftpHelper.resolveStatusMessage() method to create a message string to be
> send to the client without further checking what information is inside the
> Exception message.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
