[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    Re: [FD] Teradici Management Console 2.2.0 - Privilege Escalation
From:       Jack Cha <jcha () teradici ! com>
Date:       2017-02-28 23:39:44
Message-ID: BY2PR0201MB1765CB44F8E55E5F3D000272B0560 () BY2PR0201MB1765 ! namprd02 ! prod ! outlook ! com
[Download RAW message or body]

Ref: http://seclists.org/fulldisclosure/2017/Feb/62

Hello,
My name is Jack Cha and I am a product security engineer at Teradici. I have reproduced with \
the steps as provided and I am working with the dev team to address it. Please know that \
Teradici has been working to address it promptly. I have exchanged couple of emails with \
Harrison as per below, confirming that it would be much more difficult to exploit the same \
weakness in MC 2.3.0 and MC 2.4.0. However Teradici is working towards a complete fix in MC \
2.5.0 release so that even if the 18 digit random number can be somehow predicted, same problem \
would not exist in the future releases. I was wondering if there is a way to add Teradici's \
response to the post or if it is customary for the post to exist without vendor response. The \
moderation policy seems to encourage discussion and I certainly had a good rapport with the \
reporter in addressing the issue.

Best regards,
Jack Cha,

================== Our email exchange =========================

Hello Jack,

I don't believe it to be reasonably practical to guess or try to influence the random numbers \
that appear in the folder name when using MC 2.3.0 or 2.4.0.

Jetty appears to be using java.io.File.createTempFile() to create that folder, which ultimately \
uses java.security.SecureRandom.nextLong() for getting a long random number.  The OpenJDK 8 \
implementation under Linux appears to use SHA1 to "mix" data from sources like /dev/random and \
/dev/urandom.

While I'm not a professional cryptographer, the weakest link there appears to be the use of \
SHA1.  That said, even if the recent research about a SHA1 collision being computed is \
relevant, that computation took 110 GPU years, and in this case an attacker would have far less \
control over the input to SHA1.

A skilled cryptographer that is familiar with the various moving parts - the /dev/random and \
/dev/urandom implementation in Linux, the OpenJDK 8 SecureRandom implementation, and the \
weaknesses in SHA1 - may have a better answer to this specific scenario.

-HN

On Sun, Feb 26, 2017 at 11:44 AM Jack Cha <jcha@teradici.com<mailto:jcha@teradici.com>> wrote:
Hello Harrison,

My name is Jack and I am a product security engineer at Teradici. Thank you very much for \
inspecting our product and posting at full disclosure. I have reproduced your steps in MC 2.2.0 \
and I am working with the dev team to address it.

It looks like in MC 2.4.0, it is harder to form an exploiting archive file because the jetty \
context folder gets appended with extra 18 digit number that changes every time jetty restarts. \
For example, tmpdeploy/jetty-0.0.0.0-8080-console.war-_console-any-123451234512345678.dir in MC \
2.4.0 vs tmpdeploy/jetty-0.0.0.0-8080-console.war-_console-any- in MC 2.2.0 version. So it \
seems harder to formulate a generic payload for MC 2.4.0. I was wondering if that was the same \
result you found and if you had any thoughts on getting around that as well.

Please know that Teradici takes your report seriously and we are working towards a complete fix \
for MC 2.5.0.

Best regards,
Jack Cha


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/


[prev in list] [next in list] [prev in thread] [next in thread]