Message-ID: <CAPKwhwtCRRSTOjEedGSOAK4a59WC827CxOxh6ECQdjUau+Wpbw@mail.gmail.com>
Date: Mon, 2 Mar 2015 00:44:31 -0500
From: Scott Arciszewski <scott@...iszewski.me>
To: fulldisclosure@...lists.org
Subject: [FD] Slim Framework - (CVE-2015-2171, PHP Object Injection),
	Other Vulnerabilities

Product: Slim PHP Framework
Website: http://www.slimframework.com/
Affected versions: 2.5.0 and lower
Fixed in: 2.6.0 (released 2015-03-01)
CVSS Score: I don't care. Does anybody really?

>From their homepage:

"""
Slim has super-secure cryptography using military-grade encryption. Slim
uses your unique key to encrypt session and cookie data before persisting
data to disk.
"""

Wow, sounds great. Let's look under the hood.

https://github.com/slimphp/Slim/issues/1034
https://github.com/slimphp/Slim/issues/1035
https://github.com/slimphp/Slim/issues/1037

So not are they calling unserialize() on user data (hello PHP Object
Injection) in their SessionCookie class, but their "super-secure" crypto
library that uses "military-grade" encryption doesn't authenticate
ciphertexts. Oops.

And even if you were using the develop branch, there were a whole host of
issues with it (h/t Taylor Hornby for his 10 minute audit).

Their readme claims to encrypt cookie data, but this is moot since they're
using AES-CBC without any authentication. You just need 256 (128 on
average) tries per byte to change it to a valid value. Since the client
controls session state, you get unlimited tries.

After a lengthy discussion, I wrote a patch that replaced the serialization
with JSON encoding and closed one hole, but there are undoubtedly plenty
more that remain.

======================================================================
Vulnerable code:

https://github.com/slimphp/Slim/blob/3a2ac723f17b5d81607287ff28575d38b9fbc70e/Slim/Middleware/SessionCookie.php#L127

If you are using the Slim framework, you might not be vulnerable. If you
were using the session cookie feature (which limits the amount of data you
can store in $_SESSION to under 4 KB) on Slim 2.5.0 or older, you are
vulnerable. Upgrade to 2.6.0 immediately.
======================================================================

Speaking from personal experience, PHP developers catch a lot of flak from
the infosec community, and some of us don't really deserve it. It's
actually quite obnoxious.

That said, the owner of the Slim framework is also the author of PHP: The
Right Way. I'm a little disappointed that something so obvious would be
found in one of his projects. (Next thing you know, someone is going to
find a remotely exploitable vulnerability in Symfony, or something!) Silver
lining: he rolled out a new version the same day it was reported.

I only discovered this because someone complained that an Anti-CSRF library
wouldn't work with Slim. I'll leave the thought of "how many people could
have seen this and not reported it so they could silently exploit it for
fun and profit?" to your imagination since I have no data on this.

TL;DR - Slim users should upgrade to 2.6.0 as soon as possible. Developers
should stop using unserialize() on user input, and stop rolling out their
own cryptography libraries. Also, encryption is not authentication. Go play
with the Matasano Crypto Challenges for more on "unauthenticated CBC mode
is not secure".

Thank you and good night.

Scott Arciszewski

P.S. If anyone is interested in learning more about writing secure PHP
code, the http://www.securingphp.com newsletter is great. I highly
recommend it.

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists