| Summary: | Privilege Escalation in Redhat's packaging of squid | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Andrew McNaughton <amcnaughton> |
| Component: | squid | Assignee: | Jiri Skala <jskala> |
| Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.6 | CC: | aglotov, amcnaughton, prc |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-15 12:55:34 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Another possible fix would be to set the sticky bit on the /var/log/squid directory, and give the proxy user group access only to that directory. Then, so long as the root-owned squid.out file exists (touch it during the squid install), the squid user cannot remove that file to substitute a symlink. I think I still prefer the sudo approach first suggested. (In reply to comment #0) > Steps to Reproduce: > 1. as squid user, replace /var/log/squid/squid.out with a symlink to > /etc/nologin Are you able to create this symlink as a squid user without root login? I don't think so. As you wrote "secalert doesn't wish to treat it as a security flaw". I don't see as a bug. |
Description of problem: As packaged by redhat (in their init.d file), output from squid prior to squid dropping its privileges is piped to /var/log/squid/squid.out by the root user. The squid user owns /var/log/squid, and can therefore replace /var/log/squid/squid.out with a symlink to an arbitrary location. If an attacker gained control of the squid user, this would allow them to create files in arbitrary locations, and to append to aribtrary files. The content which can be appended is constrained, and probably not controllable by the squid user. In most cases no content is written. If content is written however, it is likely to be predictable by the squid user as to what that content will be. piping output through a squid owned process (which writes to the usual location would fix the problem. The following (minimally tested) patch fixes the init.d script, but when distributed there would also need to be something in the rpm to change the ownership of the existing /var/log/squid/squid.out file, keeping in mind that it should be considered untrusted - it might already be a symlink, so it needs to be done safely, not via a simple chmod. --- /etc/init.d/squid.orig 2010-02-16 21:08:17.000000000 +1100 +++ /etc/init.d/squid 2011-04-08 12:26:56.000000000 +1000 @@ -62,11 +62,11 @@ for adir in $CACHE_SWAP; do if [ ! -d $adir/00 ]; then echo -n "init_cache_dir $adir... " - $SQUID -z -F -D >> /var/log/squid/squid.out 2>&1 + $SQUID -z -F -D 2>&1 | su -m squid -c 'cat >> /var/log/squid/squid.out' fi done echo -n $"Starting $prog: " - $SQUID $SQUID_OPTS >> /var/log/squid/squid.out 2>&1 + $SQUID $SQUID_OPTS 2>&1 | su -m squid -c 'cat >> /var/log/squid/squid.out' RETVAL=$? if [ $RETVAL -eq 0 ]; then timeout=0; Version-Release number of selected component (if applicable): squid-2.6.STABLE21-6.el5 How reproducible: easily Steps to Reproduce: 1. as squid user, replace /var/log/squid/squid.out with a symlink to /etc/nologin 2. restart squid 3. try to log in as a non root user. Actual results: /etc/nologin is created as root user Expected results: file creation fails Additional info: this has already been sent to and considered by secalert. They do not wish to treat it as a security flaw. Nevertheless, it is a bug, and a security risk, and should be tightened up. [engineering.redhat.com #106661] Privilege Escalation in Redhat's packaging of squid