Re: CVE Request: Parameter Injection in jCryption 3.0

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
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.

> https://systemoverlord.com/blog/2014/06/18/parameter-injection-in-jcryption/

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

> http://www.jcryption.org/
> https://github.com/HazAT/jCryption/commit/bb6d788f8845223964a1743f9a43a4e92775cad8

> 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 http://openwall.com/lists/oss-security/2014/06/17/5
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
http://www.jcryption.org/#whattodo 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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJTomRpAAoJEKllVAevmvmsODgH/2zGxCODM2iTsi6Hg18zevDs
u4OiXNSb3J2UVw3loDfteg4G9u7cOiYUJ+dukfYy+ekxzGOnqVygs4K1usMBmKeh
Gw9H9kZ4wH/GPZxzein27M6DJ0nQhLoHv0cc3kqci25+g1Jar5jPYHR72Q8AEbTn
1my6maxMAG8F0NEA6clYf5AyFSGqyFJgz09S3LNMhLHDG8DvUO9HTTdlj3+bcjKm
SSGMrj36A1X7x/2TV7piLdp0bHGglL2Saa3rcYXvNCDTbzkXXTFWwfit7dkYJewr
VLR5Gbcttz7Antj2k0vB7HRiUKT6QzMgOH9rmFHojwxOllcm5gU5PxilCohqDzk=
=qaZe
-----END PGP SIGNATURE-----