Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 19 Jun 2014 00:21:40 -0400 (EDT)
Subject: Re: CVE Request: Parameter Injection in jCryption 3.0

Hash: SHA1

> jCryption 3.0 suffers from a parameter injection vulnerability due to
> passing an attacker-controlled string to PHP's proc_open function. Though
> the PHP code is not distributed as a library, it is presented as a
> copy-and-paste server side implementation to match the jQuery module, and
> sites that have done so, or have left the jcryption.php file on their
> server, are vulnerable.


> jCryption comes with PHP and perl code demonstrating the decryption
> server-side, and while not packaged as ready-to-use libraries, it is
> likely that most users used the sample code for the server-side
> implementation.


> I've released jCryption 3.0.1 with a critical security bugfix for the
> PHP example. Everyone who uses jCryption and just copy/pasted the
> example provided in the repo should immediately update their code.
> Credits goes to David Tomaschik of the Google Security Team for
> pointing that out.

As in the recent
case, the CVE project typically can't assign CVE IDs for example code
of this type, unless an inherent part of a supported installation
process has the effect of installing/exposing the example code. Here,
as far as we can tell, the documentation at just says "You can find a sample
PHP implementation in the repo" -- we don't feel that this really
implies a recommended installation process of using the sample as-is.

So, yes, actual people most likely have installed jcryption.php, and
the fix and announcement are almost certainly important. We don't want
to discourage security hardening of example code. However, we would
typically consider installing jcryption.php (or copying/pasting parts
of jcryption.php) to be a site-specific action, and this (by itself)
isn't enough for a CVE ID.

If anyone distributes a product based on jCryption in which
jcryption.php (or a derivative work that also uses $key without
escapeshellarg) would obviously be considered an installed web
application, then they could request a CVE ID for their product.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


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.