[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
