|
Message-ID: <CABY-coPLy7tOBNCrmRw9D7svNfTTQkQx7YOqnioHhk8VNTYWFg@mail.gmail.com> Date: Thu, 20 Sep 2012 14:31:19 -0400 From: George Argyros <argyros.george@...il.com> To: Kurt Seifried <kseifried@...hat.com> Cc: oss-security@...ts.openwall.com, Raphael Geissert <geissert@...ian.org>, Aggelos Kiayias <aggelos@...yias.com>, Vladimir Vorontsov <vladimir.vorontsov@...ec.ru>, gifts <gifts.antichat@...il.com>, solar@...nwall.com Subject: Re: Randomness Attacks Against PHP Applications FYI, we have also released some code to exploit such vulnerabilities about a month ago in github (https://github.com/GeorgeArgyros/Snowflake). We hope that this framework will allow the easier development of exploits for such vulnerabilities. The main difference with the code mentioned in the previous posts, is that it may not always be possible to obtain the first output from mt_rand() after seeding. For example, many applications only leak truncated mt_rand() outputs in which case we should really compare bits of different mt_rand outputs to test whether we found the correct seed. For this reason, in our tool the user defines a "hash" function that expresses any mt_rand dependent output and then we search for a preimage for this hash function. We also include a python API for this functionalities as well as a sample exploit for mediawiki 1.18.1. Some POCs might indeed help... We will also release the gaussian solver based tool we developed in order to recover the internal state of mt_rand from its (truncated) outputs in the following days. Regarding the PHP security team my personal opinion is that they are mostly stubborn. The long standing debate between them and the security community probably does not help that (although personally I mostly agree with the security community in these debates). Nevertheless, when some new fundamental problem comes up with PHP they seem to try to find a way in which they can attribute that problem to someone else instead of searching for a way to fix it (the fact that they attribute this problem only to PHP application developers demonstrates that). I agree too that education is important. This is something that we came to an agreement with the PHP team (for example that additional information is needed on the mt_rand manual). However, as pointed out nothing has changed yet (the conversations between us and the PHP team took place in March/April). However I think that the specific issue goes beyond education. First of all, We believe that adding simple exploit mitigations such as secure seeding in these functions is something that should definitely happen. Secure seeding is easy to add using randomness from the operating system and furthermore it will incur a negligible performance overhead since it would happen only once in the process lifetime. This will make the exploitation of these vulnerabilities much more difficult (compare the simple attack of connecting to a fresh process and bruteforcing the seed with connecting repeatedly to the same process and using a complex algorithm to recover the internal state from the outputs). For a more concrete solution I think that the existence of secure PRNGs is not enough. Even if mt_rand() was producing secure random numbers we would still be having a lot of vulnerable applications just from the way this function is used. Just as PHP devs use session_start() to start a new PHP session there is a need for a generate_token() function that will return a random token and take care of providing the necessary level of security for this token. On Mon, Sep 17, 2012 at 9:22 PM, Kurt Seifried <kseifried@...hat.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 09/17/2012 10:58 AM, Raphael Geissert wrote: >> On Monday 17 September 2012 10:36:46 Josh Bressers wrote: >>>> On Wed, Aug 22, 2012 at 02:31:07PM +0400, Solar Designer >>>> wrote: Maybe these PoCs will help convince someone. >> >> Just a note regarding the sessionid case: IIRC since 5.4 >> session.entropy_length is set to, erm, 32 (bytes.) Basically it >> appends N bytes from /dev/urandom to the other input for the digest >> and then it is computed. (why 32 bytes, and why still use md5 by >> default, well...) >> >>> I'm skeptical they will. I've been doing a lot of work for the >>> past year on various proactive security efforts. I keep coming >>> back to two basic things. >> [...] >>> Has anyone tried to talk to them about this further to see if the >>> issue is they don't understand, or are they being stubborn? >> >> I think the main problem is education. For instance, there is no >> word about mt_rand not being suitable for criptographic pourposes >> (much less what that means.) > > Agreed. One example of a similar problem with good images displaying > the issue clearly: > > http://lcamtuf.coredump.cx/newtcp/ > >> Sure, searching for "crypt" in the page shows a few comments saying >> that it isn't suitable, but: a) there are far more "encryption >> functions", "random password generators", and similar stuff in the >> comments than those that do mention its weaknesses. b) the official >> documentation itself doesn't say a word. It should say it loud and >> clear. >> >> Comments should also be moderated. Many examples available as >> comments in the documentation are incorrect. >> >> Now, pointing it out is easy, but somebody has to actually do the >> work. *That* is another issue. >> >> Cheers, >> > > > - -- > Kurt Seifried Red Hat Security Response Team (SRT) > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJQV8y7AAoJEBYNRVNeJnmTMsYP/jMjcOslDu6l8aoxpSqNcFmB > hdRaVRNxBh3A/IK0Vg0syR1vmP8ShFlJCEZ9XUc+8v0E/s75EO6fWNsntKTSZY5s > A646R13ENc46aPhBi2feO7PX/bVTsJVvwVMMrKLlwTWIGoyfbemAjkWRE5VBwr6x > U+R1tp97wpK65LGjwmImgzCJMUqBXGuemm+jpJTMBltcACKvGp7h28wfJL66UR76 > mSV0F7YisjZ3gKHv5DmKxlzVRNx9KcKM3qaMjWVuAIicMz3CBsbJ68WXVRbraV0Q > dXtkh5Uo/dfnfjXC6rPAMwkqOb7tdIB076alxTq16C2hbXrUVgroysJ4C4v16XTk > qkZOH6jcZYWiQai/tDQA/DNAsKbBTNj8N6JRX7y1i0d8l1SGv+fbGtG2qTeZEs5R > XhoVxKpEQUWrEU5yi7ToVasjqXUrE4cvD3n6RUX0s6IODjbm6Zbow/+F4PWIFJWF > wr2GC9nGn3RKicLxi+/mUWgtukZljfneYJu0i+R9DPDjwd0IxgpaWre3c//JurK5 > AVX9clRdEEUZD4chzqDRdzv2xmJLDcevOo29s2XC8DzePWGRO+D7t+RhQkQ4C7JB > AaZyGKCr9tosPKUVWm7UGIAWxvHaIBsvfcH6V+lGSMkeyCIeAYFV+cWjgP/aZnno > Xeicv9GFtZPRw5ThRyFi > =D8kI > -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.