[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FD] Teradici Management Console 2.2.0 - Privilege Escalation

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

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.


On Sun, Feb 26, 2017 at 11:44 AM Jack Cha <jcha AT teradici.com<mailto:jcha AT 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- in MC 2.4.0 vs tmpdeploy/jetty- 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
Web Archives & RSS: http://seclists.org/fulldisclosure/