| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 28 Feb 2017 23:39:44 +0000 From: Jack Cha <jcha@...adici.com> To: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org> Subject: Re: [FD] Teradici Management Console 2.2.0 - Privilege Escalation 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@...adici.com<mailto:jcha@...adici.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/
Powered by blists - more mailing lists