Date: Mon, 17 Aug 2015 13:55:48 -0400 (EDT) From: cve-assign@...re.org To: olivier@...tomlesspit.org Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE request - simple-php-captcha - captcha bypass vulnerability -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > https://github.com/claviska/simple-php-captcha/issues/16 Use CVE-2015-6250 for the original issue that the "srand(microtime() * 100)" call is counterproductive because, especially in cases of good time synchronization, the client is able to run the same srand call as the server. >> Date: Mon, 10 Aug 2015 00:14:38 +0300 >> From: Solar Designer <solar@...nwall.com> >> And you think removing the srand(microtime() * 100) fixes this? Well, >> it does appear to fix the most straightforward and easiest attack, and >> captchas are bypassable in general, but does this raise the bar high >> enough for the "fixed" version not to be CVE-worthy? Or are you going >> to be requesting a second CVE ID for it then? >> >> The "fixed" code relies on PHP's automatic seeding for rand() (which is >> typically dependent on system time anyway, adding only a process id to >> the mix), and, what's probably worse, it uses rand() so many times that >> it leaks its tiny internal state via properties of the captcha that are >> easy for a computer to analyze. >> OCR isn't rocket science, but it's the >> intended level of "security" of this captcha, while being able to infer >> the text through even easier analysis of "metadata" is a captcha bypass, As far as we can tell, neither https://github.com/claviska/simple-php-captcha nor http://labs.abeautifulsite.net/simple-php-captcha/ has any statement of what the intended level of security is. The basic situation seems to be that someone has written a few hundred lines of code, produced a CAPTCHA-related product that is described as "simple" and has a set of security-relevant behaviors that are quite different from those of more advanced CAPTCHA code, and needs to be given a reasonable level of latitude in deciding what bug reports will be accepted as vulnerability reports rather than suggestions for enhancements. Our guess is that using the PHP rand function, given that http://php.net/manual/en/function.rand.php says "Caution ... This function does not generate cryptographically secure values, and should not be used for cryptographic purposes" (and given that the properties of rand are otherwise somewhat well known), might be unintended and might be considered an obviously valid vulnerability report. Alternatively, one might consider it a PHP problem that the documentation is phrased in that way, and not phrased as something like "This function does not generate secure values, and there are many, many cases in which it should not be used at all." - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJV0h+dAAoJEKllVAevmvmsLu4H/2tiyghDT0idZ9PclV6dR1NR B4SK1WZFIMVPtYPFmAwWPzmYkpXwycRv3Hi3BmwI2DJTk4Ln8Fdu/EfCYdLOWyRQ 2oSfe/qbJv0d9Hwnh4oP7G1mAWWu7VktAkf2R0YkZjrAK9Lxn9/sXw/T/6n3ds/W nBzGCjC5TQXZfOoGIhm4pgnGTM5/EJBNYmklRunq5o2EGY+XUs8KNECwyI2/u4OJ dkzR3GV7dexS73jdBShap5265QFpP1985ecR5MFXpKsxmqodZjoEjCa4aif/gJBK qYrSOR572CFcpI/qIe58uJfkHtWVO4ZuHIUUNdFSo+2lRhMdj3qjqg8Ccu4qm3c= =s0+G -----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.