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

[Jack Cha <jcha@xxxxxxxxxxxx>]

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@xxxxxxxxxxxx<mailto:jcha@xxxxxxxxxxxx>> 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/