5 ms·

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

https://github.com/samilliken/openDCIM/search?utf8=%E2%9C%93&q=unserialize https://github.com/samilliken/openDCIM/search?utf8=%E2%9C%93... https://github.com/USEPA/E-Enterprise-Portal/search?utf8=%E2%9C%93&q=unserialize https://github.com/USEPA/E-Enterprise-Portal/search?utf8=%E2... Looks like the US Government is oblivious to the risk of PHP Object Injection. https://paragonie.com/blog/2016/04/securely-implementing-de-serialization-in-php https://paragonie.com/blog/2016/04/securely-implementing-de-... It looks like they're publishing code that, in particular, is vulnerable to CVE-2015-2171. https://github.com/samilliken/openDCIM/blob/d3e137294179e392321265567b6ad32ffe738c5f/Slim/Middleware/SessionCookie.php#L127 https://github.com/samilliken/openDCIM/blob/d3e137294179e392...

Alupis 10y ago
You should send in a pull request, or file a bug report in the repo.
- CiPHPerCoder 10y ago
  I'm not on their payroll, and I'd already fixed the CVE upstream over a year ago, so no.
  - Alupis 10y ago
    You took the time to go search through those repos, and then took the time to come here and point out your findings. You could have easily just copy pasted what you wrote here into an Issue on those repos. It would have helped out your government, made these projects a tad bit better, and taught a few developers something they'll remember in the future when they write more software for the government. It's part of the "spirit" if you will. Let's support these efforts - they're long overdue and difficult enough to get done for those few trying.
    - joepie91_ 10y ago
      Reporting issues to a vendor takes a hell of a lot of effort and time compared to idly posting them in a comment thread. This is like those remarks along the lines of "it only takes 5 minutes to submit a patch to the documentation". No, it doesn't - it takes 5 minutes to write it and create a PR, and usually two hours to defend it from the maintainer's criticisms.
      - iamatworknow 10y ago
        >usually two hours to defend it from the maintainer's criticisms Isn't that what we want, though? Discussion and review, particularly with the people who are most familiar with the project (the maintainers) is what makes software better, not worse. If you're not willing to do that then why comment on issues you find in open source projects at all, other than to stroke your own ego?
        joepie91_ 10y ago
        No, it's not. Legitimate discussion and review, sure - but that doesn't take two hours. The problem is with maintainers arguing over small changes, trying to trivialize them, finding reasons to reject them, asking contributors to do more work first... It's pretty much impossible to just leave a contribution and move on. This is something I encounter constantly. It's why I've stopped bothering submitting documentation fixes in most cases, and now resort to writing and publishing my own documentation. It makes one-off contributions to open-source unreasonably costly and non-viable. I know many others who feel the same. If maintainers want more contributions to their open-source projects, they need to start recognizing that the contributor's time and skills are valuable as well - that means not second-guessing contributions unless there's a concrete reason to do so, and making an effort to write a comprehensive response to a contribution (especially if it's a rejection). And most of all, being clear about this policy. It's easy to say "why don't you submit it to the project?" from the sidelines, but the reality is that 'formal' contributions nearly always come with an expectation of dedicating your time and attention towards them on a more-or-less ongoing basis. Many people cannot afford that, and as such publish them elsewhere. Changing that starts with maintainers, not with contributors.
        10y ago
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]
  - voltagex_ 10y ago
    I have no intention of getting into an argument with you but wow, you must be having a bad day. I wonder if you would have gotten a different response to your report if you'd taken a different tone with the people trying to understand the issue itself.
    - deleted 10y ago
      [deleted]
    - mistermann 10y ago
      > if you'd taken a different tone I've been thinking about this a lot lately....I think "why didn't you just use a different tone" is very similar to how people that grew up in environments where everything went right when they say to people struggling "why don't you just do x,y,z". The problem is, they don't know how.
      - 15thandwhatever 10y ago
        I agree, but with a little twist: the problem is not that the latter party doesn't know how and the former party has the answers, maybe it's that the former party doesn't know how either. In this particular instance, the actual problem is notification. OP said he fixed the bug in his original code, and one of his downstreams should fix the bug too. Fair enough. But then things took a turn towards "you should do the work", "civic duty", and what not. To which OP replied he's not going to fix it in a code base he's not compensated for. The actual problem in this scenario here isn't OP's willingness to donate his time, it's that the right person at the downstream needs to be notified (and in turn acknowledge the problem). And in the world of open source, this is a common issue which is impacted by multiple notification avenues, developer continuity, and general infosec policy. But instead of any one of us creating an issue saying "Hey dudes, this was fixed in the upstream -- here's a copy-and-paste pointing to the fixed and respective vulnerable code", it's a pile-on with holier-than-thou mantras regarding why OP should do the free work of reading the source code, testing a fix, and creating a patch.

Alupis 10y ago

You should send in a pull request, or file a bug report in the repo.

CiPHPerCoder 10y ago
I'm not on their payroll, and I'd already fixed the CVE upstream over a year ago, so no.
- Alupis 10y ago
  You took the time to go search through those repos, and then took the time to come here and point out your findings. You could have easily just copy pasted what you wrote here into an Issue on those repos. It would have helped out your government, made these projects a tad bit better, and taught a few developers something they'll remember in the future when they write more software for the government. It's part of the "spirit" if you will. Let's support these efforts - they're long overdue and difficult enough to get done for those few trying.
  - joepie91_ 10y ago
    Reporting issues to a vendor takes a hell of a lot of effort and time compared to idly posting them in a comment thread. This is like those remarks along the lines of "it only takes 5 minutes to submit a patch to the documentation". No, it doesn't - it takes 5 minutes to write it and create a PR, and usually two hours to defend it from the maintainer's criticisms.
    - iamatworknow 10y ago
      >usually two hours to defend it from the maintainer's criticisms Isn't that what we want, though? Discussion and review, particularly with the people who are most familiar with the project (the maintainers) is what makes software better, not worse. If you're not willing to do that then why comment on issues you find in open source projects at all, other than to stroke your own ego?
      - joepie91_ 10y ago
        No, it's not. Legitimate discussion and review, sure - but that doesn't take two hours. The problem is with maintainers arguing over small changes, trying to trivialize them, finding reasons to reject them, asking contributors to do more work first... It's pretty much impossible to just leave a contribution and move on. This is something I encounter constantly. It's why I've stopped bothering submitting documentation fixes in most cases, and now resort to writing and publishing my own documentation. It makes one-off contributions to open-source unreasonably costly and non-viable. I know many others who feel the same. If maintainers want more contributions to their open-source projects, they need to start recognizing that the contributor's time and skills are valuable as well - that means not second-guessing contributions unless there's a concrete reason to do so, and making an effort to write a comprehensive response to a contribution (especially if it's a rejection). And most of all, being clear about this policy. It's easy to say "why don't you submit it to the project?" from the sidelines, but the reality is that 'formal' contributions nearly always come with an expectation of dedicating your time and attention towards them on a more-or-less ongoing basis. Many people cannot afford that, and as such publish them elsewhere. Changing that starts with maintainers, not with contributors.
      - 10y ago
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
- voltagex_ 10y ago
  I have no intention of getting into an argument with you but wow, you must be having a bad day. I wonder if you would have gotten a different response to your report if you'd taken a different tone with the people trying to understand the issue itself.
  - deleted 10y ago
    [deleted]
  - mistermann 10y ago
    > if you'd taken a different tone I've been thinking about this a lot lately....I think "why didn't you just use a different tone" is very similar to how people that grew up in environments where everything went right when they say to people struggling "why don't you just do x,y,z". The problem is, they don't know how.
    - 15thandwhatever 10y ago
      I agree, but with a little twist: the problem is not that the latter party doesn't know how and the former party has the answers, maybe it's that the former party doesn't know how either. In this particular instance, the actual problem is notification. OP said he fixed the bug in his original code, and one of his downstreams should fix the bug too. Fair enough. But then things took a turn towards "you should do the work", "civic duty", and what not. To which OP replied he's not going to fix it in a code base he's not compensated for. The actual problem in this scenario here isn't OP's willingness to donate his time, it's that the right person at the downstream needs to be notified (and in turn acknowledge the problem). And in the world of open source, this is a common issue which is impacted by multiple notification avenues, developer continuity, and general infosec policy. But instead of any one of us creating an issue saying "Hey dudes, this was fixed in the upstream -- here's a copy-and-paste pointing to the fixed and respective vulnerable code", it's a pile-on with holier-than-thou mantras regarding why OP should do the free work of reading the source code, testing a fix, and creating a patch.