Re: Teradici Management Console 2.2.0 - Privilege Escalation

[Jack Cha <jcha () teradici com>]

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/