[jira] [Comment Edited] (SSHD-775) SftpSubSystem::sendStatus leaks Exception information

["Mark Ebbers (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SSHD-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194552#comment-16194552 ] 

Mark Ebbers edited comment on SSHD-775 at 10/6/17 12:57 PM:
------------------------------------------------------------

An attacker can still be someone who has (legit) access to the SFTP server and, for example, tries to break out of its jail.
{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}

IMHO the leak consist of the absolute full path too the file on the servers file-system in the error message instead of the relative path of the users chroot environment. And I think it is also more neat :)
{quote}Again, I do not see the harm/"leak" here.{quote}

I totally agree :)
{quote}Obscurity is not security{quote}

Sounds like a nice solution.
{quote}
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}




was (Author: mark.ebbers):
An attacker can still be someone who has (legit) access to the SFTP server and, for example, tries to break out of its jail.
{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}

IMHO the leak consist of the absolute full path to the file on the servers file-system in the error message instead of the relative path of the users chroot environment. And I think it is also more neat :)
{quote}Again, I do not see the harm/"leak" here.{quote}

I totally agree :)
{quote}Obscurity is not security{quote}

Sounds like a nice solution.
{quote}
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}



> 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)