CVE-2015-2171

[paragonie-scott]

Why are you publishing code that had a public PHP object injection (read: possible remote code execution) vulnerability that was fixed over a year ago?

More importantly: Why are you deploying this vulnerable code to systems used by US government agencies?

[wilpig]

Before you go making bold claims like this please research them.

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

While this is an issue it does not affect us as we aren't using session cookies with slim

[paragonie-scott]

Pay no attention to the man behind the curtain. Everything is fine. this-is-fine.jpg

https://github.com/samilliken/openDCIM/search?utf8=%E2%9C%93&q=unserialize

This just shows a more serious problem: You're not keeping your dependencies up to date. This is more serious problem than it first appears.

But by all means, continue to bury your head in the sand. I only opened an issue here because HN users tried to guilt me into it. I'm not a user of this software, so any security snafus made here aren't really my business.

[wilpig]

Please feel free to open an issue when you find an actual problem. Playing peekaboo for a specific commands with no understanding of the code itself would be like me pointing at Congress and saying "misappropriation". While it might be happening you can't fix it without a specific information set to work from. All you've done is make an accusation and distract me from whatever I was thinking about.

[paragonie-scott]

I just outlined the actual problem:

1. You aren't updating your dependencies in a timely manner.
2. Your dependencies will have vulnerabilities discovered in them.
3. From the linked article: 99.9% of vulnerabilities exploited in 2015 happened over one year after the vulnerability was public.

Your process (or perhaps the lack thereof) will fail your users. That is an actual problem, and the one you may want to actually spend time thinking about.

But I'm not here to help, I'm here to fulfill a moral obligation so no one can say I didn't try. Consider my effort concluded.

(Also, if you can in any way help it, just stop using unserialize(). Too many memory corruption vulnerabilities result from it.)

[wilpig]

You've outlined your perceived problem. You want to help them submit code updates and correct the issues. Otherwise your opinion has been noted and appropriately filed in the bin.

[paragonie-scott]

You want to help them submit code updates and correct the issues.

This is really something that should have been done all along. Most PHP projects have moved to Composer (and https://github.com/Roave/SecurityAdvisories for that matter) to make this easier.

I hope, should OpenDCIM's inability to keep dependencies up to date even when security vulnerabilities are fixed upstream lead to a government agency getting owned up, no one on your team gets held liable in any capacity.

And with that, I'm out.