Tag Archives: encryption

PHP uniqid() – Entropy Analysis and Potentially Vulnerable Apps

Background
This research started with my reporting a zero-day that Front Accounting’s reporting used uniqid() and it’s file names were non-random. Given where the application saves these reports by default they are retrievable by anyone who can guess the proper URL report name. OSVDB asked me to what extent does this issue overlap with a larger, previously reported PHP issue of non-randomness in the generation of PHPSESSIONID. Over the course of my research I discovered that, while both suffered issues of non-randomness, uniqid() and LCG were independent from each other after PHP3. As of PHP4+, uniqid() is not used to generate session cookies. While uniqid()  uses an LCG randomness routine it only does so when the more_entropy flag is set by the developer. LCG is not the cause of the lack of uniqid() entropy. In fact it is just the opposite. It helps it when the flag is set but not significantly. As such it is my humble opinion that CVE and OSVDB descriptions needed to be updated to reflect this information. In our tweets Steve Christey was still worried — and rightly so — that many applications use the uniqid() function and might be vulnerable. So, here we are.

Issue
It’s clear that uniqid() is non-random. This is even reported in the PHP documentation. The question is how non-random is it? Furthermore, what’s the impact? How many apps are using the function?

Testing
I tested the non-randomness by writing some sample PHP code taken almost straight from the documentation. I did this because I felt it best to use the sample code provided by PHP to their users. I assume here that it will be the way most people will use the function (copy and paste). Two apps were written: one to test the function regularly and one to test it with added entropy. Since I’m not a math geek, I used burp‘s Sequencer functionality to test the entropy. I have fairly smallish sample sizess but I believe I do not need a larger ones to change the general nature of the result. (I leave this to the next researcher.) I then used Search Diggity to scan through google’s project code as well as doing a direct search. I attached a gallery with annotations showing the testing procedure and results.

Conclusion

With or without the more_entropy option, uniqid(), as represented in the PHP sample code and documentation, results in poor entropy and should not be used. According to burp, with a sample size of 4016 tokens, uniqid() without more_entropy is “extremely poor” and has a effective entropy of 10 bits. With a sample size of 7515 tokens, uniqid() with more_entropy enabled is “poor” with an effective entropy of 29 bits. According to burp the reliability of the sample sizes were either reasonable or good. It is my opinion that if the tests were conducted over a larger sample size the effective entropy will only decrease: by how much I’m not certain.

The question remains: are there vulnerable applications and to what extent? Search Diggity returns 100 instances of uniqid() being used on google code. Google’s own search engine returns 60K+ strings matching uniqid(). Important:  google’s query is a bit of a false indicator since it returns results that matches the string including languages other than PHP. And, I didn’t scan other repositories such as Sourceforge or Github.

Lesson 1: heed the PHP documentation and do not use uniqid() when the need for a random string arises. Lesson 2: it seems that there is a decent amount of potential vulnerable code.

Below are the pictures to support the research. Many thanks to OSVDB and Steve Christy for an excellent exchange of tweets. Enjoy and happy hunting.


NYT: Push Iranian Revolution via Software

The New York Times has an interesting article on how to help Iran’s Green Movement and push the country toward Democracy. Don’t issue new sanctions, allow them free software! I think it’s particularly brilliant:

The sanctions will feel cathartic, satisfy the have-to-do-something itch in the Congress, and change nothing. I’m just about resigned to that. But there is a smarter approach to Iran: Instead of constraining trade, throw it open.

Verma wrote: “The Department of State is recommending that the Department of Treasury’s Office of Foreign Assets Control (O.F.A.C.) issue a general license that would authorize downloads of free mass-market software by companies such as Microsoft and Google to Iran necessary for the exchange of personal communications and/or sharing of information over the Internet such as instant messaging, chat and e-mail, and social networking.”

Now that’s smart! There’s a way to bolster the remarkable, still unbowed opposition movement in Iran as well as weaken the Revolutionary Guards’ stranglehold on society and the economy. And what has O.F.A.C. done about this request in the past two months?

Nothing.

No license has been issued. It’s still illegal for Microsoft to offer MSN Messenger in Iran. Instead, earlier this month, Treasury sanctioned four Guards companies — a meaningless gesture. Treasury has things upside down.

Now if they would only include encryption modules!

Crash: Toyota’s Closed Data System

Did you know that your car has a blackbox similar to airplanes? Most car companies use an open platform that allows this blackbox data to be downloaded and analyzed in order to aid investigations.  In the February 22nd, 2010 issue of Newsweek, Matthew Philips reported that Toyota uses a closed data system. Unfortunately this article is not online so I cannot link to it, but it is on page 12 of the current issue.

The article gives no indication whether or not the data is encrypted or encoded. It is my guess that it’s an uncrypted proprietary format. To me it seems unlikely that Toyota would go though such efforts to protect/encrypt data that they claim is not designed for accident reconstruction but namely intended to “aid research on safety systems such as airbags.”

Given the Toyota recall, we see the double edged nature of closed systems: on one hand, the data is protected from eyes outside Toyota; on the other hand, the lack of transparency (and non-compliance with industry open standards) leaves it vulnerable to attack by the larger justice system for being potentially negligent about the technical malfunctions that leads to a higher crash rate.