Marco Slaviero reported a flaw in the use of python's pickle module as used in system-config-firewall that could allow local users to elevate their privileges to that of the root user. The pickle module is used to format messages between the system-config-firewall GUI and the system-config-firewall-mechanism.py privileged backend (that runs as root). The frontend and backend use D-Bus to communicate with each other, and pickle is known to permit the execution of arbitrary python code, so the untrusted user can send to the backend pickle shellcode that is executed in a privileged context. The flaw depends on a number of non-standard configurable items to be set: 1) SELinux must be disabled (with SELinux enabled, certain actions can be executed as root, but they are extremely limited) 2) The user must be local, and using a GUI Acknowledgements: Red Hat would like to thank Marco Slaviero of SensePost for reporting this issue.
This issue is set to be made public on August 4th at BlackHat USA as part of a talk on vulnerabilities in python pickle.
More information: http://nadiana.com/python-pickle-insecure This includes information on how to make pickle safer, but again suggests that its not 100%. The website also suggests JSON is a good alternative.
More pickle fun: http://blog.nelhage.com/2011/03/exploiting-pickle/
Tried to modify the script to check if this would disable selinux: Running it yields the following in the audit logs: type=USER_AUTH msg=audit(1309793900.311:93): user pid=5032 uid=0 auid=504 ses=1 subj=unconfined_u:unconfined_r:policykit_auth_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="fw" exe="/usr/libexec/polkit-1/polkit-agent-helper-1" hostname=? addr=? terminal=tty1 res=success' type=USER_ACCT msg=audit(1309793900.314:94): user pid=5032 uid=0 auid=504 ses=1 subj=unconfined_u:unconfined_r:policykit_auth_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="fw" exe="/usr/libexec/polkit-1/polkit-agent-helper-1" hostname=? addr=? terminal=tty1 res=success' type=AVC msg=audit(1309793900.354:95): avc: denied { write } for pid=5036 comm="setenforce" name="enforce" dev=selinuxfs ino=4 scontext=system_u:system_r:firewallgui_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=file type=SYSCALL msg=audit(1309793900.354:95): arch=c000003e syscall=2 success=no exit=-13 a0=7fffb56d8350 a1=2 a2=7fffb56d8360 a3=fffffff8 items=0 ppid=1736 pid=5036 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setenforce" exe="/usr/sbin/setenforce" subj=system_u:system_r:firewallgui_t:s0-s0:c0.c1023 key=(null) Code is executed by pickle as root with the context "system_r:firewallgui_t". Selinux restricts programs with this context from running setenforce or from modifying /selinux/enforce. It seems that you cant bypass selinux using this issue.
This has been assigned CVE-2011-2520
Even with selinux enabled, it is possible to write to /etc/sysctl.conf. This could be useful (e.g. disabling module loading) and rebooting. It is also possible to write into /tmp and /etc/sysconfig/system-config-firewall as root.
Additionally, this exploit is only useful where the user can configure the firewall, but does not have access to a 'root' equivalent account. In RHEL6's default configuration, the polkit action 'org.fedoraproject.config.firewall.auth' is only available to members of 'desktop_admin_r' group, which is functionally equivalent to 'root' through`pkexec bash`. However, this polkit action is required to make firewall changes and to share printers. It is possible in certain environments that an administrator may delegate the ability to modify firewall rules (e.g. to enable file sharing, or printer sharing) to individual users or groups. In this non-default scenario, this privilege escalation bug applies.
(In reply to comment #10) > Even with selinux enabled, it is possible to write to /etc/sysctl.conf. This > could be useful (e.g. disabling module loading) and rebooting. It is also > possible to write into /tmp and /etc/sysconfig/system-config-firewall as root. Sure, the following in the selinux policy makes it possible: allow firewallgui_t system_conf_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; allow firewallgui_t system_conf_t : dir { ioctl read write getattr lock add_name remove_name search open } ; Rebooting the machine would get more user attention though :)
(In reply to comment #11) > Additionally, this exploit is only useful where the user can configure the > firewall, but does not have access to a 'root' equivalent account. > Of course > In RHEL6's default configuration, the polkit action > 'org.fedoraproject.config.firewall.auth' is only available to members of > 'desktop_admin_r' group, which is functionally equivalent to 'root' > through`pkexec bash`. > > However, this polkit action is required to make firewall changes and to share > printers. It is possible in certain environments that an administrator may > delegate the ability to modify firewall rules (e.g. to enable file sharing, or > printer sharing) to individual users or groups. In this non-default scenario, > this privilege escalation bug applies. An ideal exploit case would be, a non-privileged user having access to "org.fedoraproject.config.firewall.auth" via polkit
Created attachment 511508 [details] Replace pickle by json Proposed patch to replace pickle by json.
Hi Marco, We have worked out a patch for system-config-firewall and it indeed seems that replacing pickle with json is a good idea. I see that you intend to make this public in BlackHat in August. Would it be ok to share the vuln. details with other vendors via a private (encrypted) mailing list, along with the details of the date on which this should be made public?.
Hi Huzaifa, Sure, that will be fine. Which other vendors make use of system-config-firewall?
(In reply to comment #19) > Hi Huzaifa, > > Sure, that will be fine. Which other vendors make use of > system-config-firewall? Thank you. Afaik i dont think any other distros use that. However letting other vendors know would usually let them look at their codebases to see if they were using a similar setup somewhere else.
Hi Marco, Can i confirm a un-embargo date of 04-August-2011?. Do let us know if you want to post-pone or pre-one this. We usually push our updates during US times. I suppose you would like us to wait till your presentation is over on that day?. Would you inform us via this bug, or if you could let us know the time in advance, we could push the update (After your have presented ofcourse :)) Thanks.
Hi Huzaifa, In truth, I don't think the bug is going to make waves if the update is released ahead of the presentation. I'm don't see any reason not to push the update immediately without waiting for Aug 4, and get your customers patched now.
(In reply to comment #22) > Hi Huzaifa, > > In truth, I don't think the bug is going to make waves if the update is > released ahead of the presentation. I'm don't see any reason not to push the > update immediately without waiting for Aug 4, and get your customers patched > now. Wow, i wanted to ask this question as well, but i thought you would have insisted on the embargo. I am going to get rolling with the updates asap, and will un-embargo this bug once done. Thanks a lot. :)
Marco, Would it be ok, if we credit you in our advisory? If so, are you ok with the following text: "Red Hat would like to thank Marco Slaviero for reporting this issue." or should be mention "Marco Slaviero of SensePost Information Security" ? thanks.
Hi Huzaifa, Please include 'Marco Slaviero of SensePost'. thanks
(In reply to comment #28) > system-config-printer-1.1.16-17.el6_1.1 built. > > Not sure when I should build the RHEL-6.2 package so as to be sure it won't > leak before the embargo. There is a RHEL-6.2 update already scheduled for > system-config-printer. Tim, As mentioned to Huzaifa, the embargo is not a requirement from my side. Feel free to build and release the updates as you see fit.
Thanks.
I am making this public and informing oss-security about this flaw now.
Created system-config-printer tracking bugs for this issue Affects: fedora-all [bug 722992]
Created system-config-firewall tracking bugs for this issue Affects: fedora-all [bug 722991]
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:0953 https://rhn.redhat.com/errata/RHSA-2011-0953.html