Hide Forgot
Description of problem: The tclx extensions has a chroot command. Inspecting the code shows that it does not do a chdir("/") after calling chroot. This means that '.' is outside the chroot. See, unix/tclXunixCmds.c. Looking at the test scripts & documentation makes it unclear if the responsibility of doing the chdir is that of this command or if the programmer is expected to issue a chdir. If the library does it then there is no harm since a second chdir to / would have no effect. However, if the library does not do it and programmers assumed the library took care of it, then there could be apps that are not inside the chroot. Additional info: http://cwe.mitre.org/data/definitions/243.html
Created attachment 513502 [details] Patch attempting to fix the bug
Steve thanks. I think this behaviour is according to supplied TclX.n man: > chroot dirname > Change root directory to dirname, by invoking the POSIX > chroot(2) system call. This command only succeeds if running > as root. I understand it that it is only wrapper to POSIX chroot. And the behaviour (and jail escape problem) is described in chroot(2) man page. I will consult this with upstream, they could at least note this explicitly in their doc. Could we make it public? I would like to link this report to upstream tracker.
Yes, I saw the same documentation and did not see a warning to the programmer about whether or not they need to issue a chdir or if this was already handled for them. I then looked at the unit tests supplied and noticed that none of them did a chdir, so I thought this must be the correct and intended use since there was unit tests. Based on that, I suspected that the library should do the chdir. Of course, there could be corrections to the unit test + docs so that the programmer knows the right actions after the chroot.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate, in the next release of Red Hat Enterprise Linux.
Was there any outcome of the discussion with the upstream? What is the situation in the latest upstream version?
(In reply to Tomáš Hozza from comment #9) > Was there any outcome of the discussion with the upstream? What is the > situation in the latest upstream version? I didn't bring it upstream because it wasn't rated by SRT and I don't have private secure channel to upstream (to be honest the upstream seems to be dead, i.e. no release since 2012). Personally I don't think it's security related, but I can't it just put on public mailing list.
This can be a security issue. See this: https://cwe.mitre.org/data/definitions/243.html
(In reply to Steve Grubb from comment #11) > This can be a security issue. See this: > > https://cwe.mitre.org/data/definitions/243.html Thanks for info, I think I am not authorized to judge it. I sent mail to secalert to sort it out.
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available. The official life cycle policy can be reviewed here: http://redhat.com/rhel/lifecycle This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL: https://access.redhat.com/