Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 17 Aug 2015 13:55:48 -0400 (EDT)
Subject: Re: CVE request - simple-php-captcha - captcha bypass vulnerability

Hash: SHA256


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 <>

>> 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 nor 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 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 ]
Version: GnuPG v1


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.