Bug 444434 (CVE-2008-1381)
Summary: | CVE-2008-1381 zoneminder: command injection via unescaped php exec() calls | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Tomas Hoger <thoger> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | CC: | fedora, j |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | 1.22.3-14.fc9 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-05-13 15:23:32 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 444435, 444436, 444437 | ||
Bug Blocks: |
Description
Tomas Hoger
2008-04-28 12:40:01 UTC
I have backported the patch to the version currently in rawhide and have commited an update to the devel branch. I have not yet tested it; I just wanted to get something started. One hunk in the upstream patch does not correspond to any existing code in 1.22.3; this portion alters $filter['query'] and $filter['fields'] and filters are not constructed that way in 1.22.3. Honestly I don't quite understand what security issue is being fixed by that portion of the patch; it looks to be an unrelated bugfix. In any case, it would be great is someone could double-check what I've done. That part of the patch really seems like unrelated bug fix. $filter['fields'] change seems uninteresting, as it just moves where quote is added to name= option ("name= --> name="). $filter['query'] change looks like following bug fix mentioned on the Change_History page linked in comment #0: FIX : Fixed an issue where filter queries were sometimes url encoded twice meaning that clicking onto subsequent pages from a filtered view lost the filter and displayed all events instead of ust the filtered set. zoneminder-1.22.3-10.fc8 has been submitted as an update for Fedora 8 zoneminder-1.22.3-8.fc7 has been submitted as an update for Fedora 7 Jason, thanks v much for backporting the patch. I've pushed to testing for all apart from F9 which I'll do later. Actually, if you build for F9 now and ask rel-eng to tag it into the release, you might be able to get the updated version into F9 itself and not have to push an update. This issue got duplicate CVE id - CVE-2008-2033: Multiple unspecified vulnerabilities in ZoneMinder before 1.23.3 allow remote authenticated users to execute arbitrary code via unknown attack vectors. References: http://secunia.com/advisories/29995 http://www.zoneminder.com/wiki/index.php/Change_History#Release_1.23.3 Does this duplicate CVE require any separate action? Does the update notice need to be modified, or does a separate update noting that this CVE is already fixed by the previous update? Also, I noticed that in Mark Cox's blog, he indicated that the issue was discovered some time ago and that vendors were notified then. Does anyone have any idea why Fedora was not notified until the CVE was made public, leaving us to scramble for a fix and most likely forcing this fix to be released as an update for F9 instead of having it in the actual release? (In reply to comment #9) > Does this duplicate CVE require any separate action? Does the update notice > need to be modified, or does a separate update noting that this CVE is already > fixed by the previous update? No action needed. Mitre will reject one as dupe of the other. CVE-2008-2033 will probably be rejected. > Also, I noticed that in Mark Cox's blog, he indicated that the issue was > discovered some time ago and that vendors were notified then. Does anyone > have any idea why Fedora was not notified until the CVE was made public, > leaving us to scramble for a fix and most likely forcing this fix to be > released as an update for F9 instead of having it in the actual release? Mark did not create a patch for the issue and ZoneMinder upstream did not provide us with patch in advance. However, the problem with fixing security issues in Fedora while they are under embargo is more complicated. As both CVS and build system is public, fixes can not be committed and updates built before issue is made public (in this case by upstream releasing fixed version). I pushed the update for F7 and F8 back on 29th April, but it is still pending. Any idea why it is stuck? F9 is building and will be submitted to bodhi soon. zoneminder-1.22.3-14.fc9 has been submitted as an update for Fedora 9 (In reply to comment #11) > I pushed the update for F7 and F8 back on 29th April, but it is still pending. > Any idea why it is stuck? Waiting for release engineering to sign and push them. Currently, there are only 1 or 2 rel-eng team members able to sign new rpms, resulting in a bottleneck in the process. zoneminder-1.22.3-8.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report. zoneminder-1.22.3-10.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report. zoneminder-1.22.3-14.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report. FYI Regarding #9, this flaw is only of moderate consequence, so a little delay for Fedora packages after publication was expected and acceptable. It's moderate because of the nature of the privilege boundary being crossed : you shouldn't allow untrusted users the ability to view and control your ZoneMinder installation, so this flaw is limited to being exploitable by ZoneMinder administrators. |